PFMaBiSmAd

Where in your code are you setting $user to a value? And have you echoed it so that you know it contains the value you expect?

If the data is being escaped only one time, the \ characters should NOT be in the database. I'm going to guess that php is escaping the form data, due to magic_quotes_gpc and you are escaping it a second time with mysql_real_escape_string. If you can, you need to turn off magic_quotes_gpc. If you cannot turn it off, you can use the get_magic_quotes_gpc function to detect when it is on, and remove the escaping it does before you use mysql_real_escape_string on the data.

I'm pretty sure that phpmyadmin accurately shows data, even if it contains quotes/escape characters (I use a different database tool and it shows the correct results in the database table when I tried this.) Where is this $height coming from and have you confirmed that the $height variable contains what you expect? This problem isn't being caused by mysql_real_escape_string(). The following code works as expected and inserts and displays the value correctly - <?php // db connection here... $height = <<<EOD 5'8" EOD; $query = "INSERT INTO model (height) value ('" . mysql_real_escape_string($height) . "')"; mysql_query($query); $query = "SELECT height FROM model"; $result = mysql_query($query); while($row = mysql_fetch_assoc($result)){ echo htmlentities($row['height'],ENT_QUOTES) . '<br />'; } ?> Is your height column a character data type that could hold a string like 5'8"?

Exactly what are you doing to look at the data in the database?

What is the data type of your team_treasure and members_count columns?

The people who actively suggest storing unix timestamps in a database are those that have never attempted to efficiently and quickly do things like the following in a query - SELECT player, pitcher, YEAR(date_recorded), MONTHNAME(date_recorded) as month, SUM(at_bats) as bats FROM your_table WHERE YEAR(date_recorded) BETWEEN 2009 AND 2011 AND player = 'somename' AND pitcher = 'somename' GROUP BY YEAR(date_recorded), MONTH(date_recorded) ^^^ Gets the number of times (and any other statistics) a particular player has faced a particular pitcher in each month between 2009 and 2011. To do the above using unix timestamps would require multiple slow conversions from unix timestamps in the query (and no indexes on the data) or multiple queries with the specific unix timestamps for the start/end of each month worth of data. Replace the above query with any other real-life example, such as an inventory report, poll, accounts receivable, event calendar... where you need to operate on information based on more one a single range of date values (a unix timestamp is fine to get data between one unix timestamp and another unix timestamp because you can calculate the unix timestamps that correspond to the start/end of the date range you want.)

Your would use the mysql MONTH() function in your query (and data is generally specific to a month in a specific year, so you generally would want to test the month and year of the data.) WHERE MONTH(datetime_value) = some_number Unix timestamps have some problems - 1) They must be converted (which is a relatively slow function) to be usable for anything that involves humans and calendars. 2) You must take into account the timezone setting when you convert them to a human readable format and the timezone database (php's and mysql's) must be kept up to date (a lot of locations have changed their DST start/end dates lately) if you want correct results. 3) They have a 1970/2038 or 1901/2038 range limit, depending on php version and operating system, that makes them unsuitable for things like birthdays and future payment calculations... 4) They cannot directly be used in queries involving more than a single calendar item at one time (those checking the year, month, or day of the value) without going through a slow conversion of all the data into a yyyy-mm-dd format, which also means that you cannot set an index on the data to speed up your queries. If you want to do efficient queries that find human calendar items, such as all the records with a specific month or all the records between two dates that do any grouping or aggregate functions based on dates, a unix timestamp is the worst way to store the values. If you store a yyyy-mm-dd value in a database, it will always be that value. The same is not true of a unix timestamp. From the mysql documentation - You can retrieve a DATETIME or DATE value in any format you want by using the mysql DATE_FORMAT() function in your query. This is at least 8 times faster than using php code with date/strtotime functions to change the format. You can also directly change any formated date/date-time into a DATE or DATETIME value using the mysql STR_TO_DATE() function in a query.

The syntax you are using in the line to build your query statement is that for a sprintf statement, but you don't have a sprintf() in your code.

I'm sure you provided your friend with a lot more information about the code and variables that was causing the problem than what you supplied here. When the post that starts a thread doesn't contain all the relevant code and information needed to solve them, a lot of threads just go unanswered and fall off the front page of the forum. Don't complain if someone didn't feel like taking the time to ask you to post relevant code and information about the problem that you didn't take the time to include in the first post in the thread.

You didn't tell us what problem you are having. Is the value actually inserted into your table when you look directly using your favorite database management tool? If the problem is that you cannot display the value, it is because you need to use htmlentities with the second parameter set to ENT_QUOTES when you output it to the browser so that the quotes in the value don't break the HTML of your web page.

Once you use some error checking to find out at what point the query contains an error, you will find that using read as a column name is the problem. See this information - http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html

If you search for that error message, you will find that it generally means that your query failed due to an error of some kind and you would use mysql_error() to find out why.

Every HTTP request that the browser makes includes the HTTP_USER_AGENT as part of that request. External css and external javascript files are requested by the browser using a HTTP request.

The error is because your for(){} loop consists entirely of the following two lines of code - for ($c=1; $c < $number_of_fields; $c++) echo "<tr>"; Then you execute the $data_array[$c] = $data[$c]; statement after that for loop ends, but $c is equal to $number_of_fields at that point in time, which doesn't exist. You need to move that echo statement, either before the start of the for() loop or you need to move it inside the {} that you intended to be part of that for(){} loop.

Since you are going to be formatting the information using HTML, it is best to just retrieve the data you want in the order that you want it.

You would use ORDER BY session to get the rows in the order that you want, then in your php code, you would output the new heading any time the session value changes. See this link for some pseudo code - http://www.phpfreaks.com/forums/index.php?topic=331304.msg1559057#msg1559057

LOL, and if you want help with why you code is producing that error, you would need to post your code starting with the sql statement through to the end of any loop that is retrieving the result from the query.

If you search for that error message, it generally means that your query failed due to an error of some kind and you would generally use mysql_error() to find out why. It can also mean that you used the wrong variable name in the mysql_fetch_assoc() statement or that you overwrote the variable that was holding the result resource from the query.

What does a 'view source' in your browser show for the page with the second piece of code in it?

It's just IE, possibly just following the w3.org specification to the letter (the submit field is only successful if it was clicked.)

Use a hidden field with name='submit'

Your form's not the problem. In fact, bot scripts that send spam submit the data directly to your form processing code. Your form processing code is where you must validate the data.

The problem is the quotes around the column names. And don't put numbers inside of quotes. That just uses extra processing time converting them from strings to numbers and in the case of a number like 180.00, it results in first a conversion to a floating point number, then to a decimal number, which can result in a floating point conversion error.

Related to the concurrent UPDATE problem mentioned above, the multiple update queries will leave the balance as an incorrect amount because you are selecting the starting value in one query, subtracting an amount in the php code, and then updating the balance with that result. The last update query that gets executed will 'win' and leave the balance set to the value it would have resulted in and that will replace any previous update. You can solve this one problem by doing the subtraction in the UPDATE query and not in the php code. This will mean that the balance will be accurate (each concurrent update will subtract from the actual current balance in the table row), but could result in a negative value as previously mentioned.

Also, any chance you have existing data using any particular sale_id in the sale_details table and you have at some point cleared and reset the sales table and are reusing the auto-increment id values?