PFMaBiSmAd

The point in the query that the error message is calling your attention to is where mysql found something in your query that is out of place or means something else to mysql. Hmmm. I wonder what about the word references could cause this (see this link for a list of mysql reserved keywords - http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html ) Edit: Posted anyway...

Someone told you - Did you read the error message? Also, you could always just look at your code or the query that you echoed out.

^^^ That's testing if the query executed without any ERRORS (i.e. a connection problem, a syntax error, a miss typed table/column name.) That doesn't test if the query matched any rows or not. See - mysql_num_rows

Actually, that's an alternative way of forming an INSERT query. You have a missing comma in the list of field/values, right at the point that the error message is calling your attention to.

Already did -

Setting the error_reporting and display_errors settings as suggested would have directly pointed out a variable that was not set at the time you referenced it.

Could you at least identify the variable name that should contain the correct value and the place where it is being echoed out in the code you posted? You have posted several hundred lines of code that we have no way of running (we don't have your database tables and aren't likely to create them and put test data into them) and want someone to figure out why you are getting a zero at some unidentified point in it.

If your query is not producing an error, then the problem is something else that your code is doing. If you want help with what your code is doing or not doing, you need to post enough of it that duplicates the problem.

You would need to post your complete and actual code that does not work. I can tell, based on experience, from the symptom, that you either have some lines of code between where you are setting the variable and where you are using it that is clearing it or your mysql_query statement is in a different program scope from where you set the variable. You also don't have php's error reporting set to E_ALL and display_errors set to ON to get php to report and display all the errors it detects and you don't have any error checking logic on the mysql_query statement to get it to tell you why it is failing. Edit: Which is pretty much exactly what jcbones posted above.

And what is the current problem with just doing this? Pika already told you - Doing that (stripping out the other things) to one representative example from the code he posted, produces this logic - <?php if( !empty($_POST['name']) ) { // validate the name field // code for the other things was here... } else { $errors['name'][] = 'Name is a required field.'; // if name is empty, store error } Rearranging and simplifying the logic - <?php if( empty($_POST['name']) ) { // validate the name field $errors['name'][] = 'Name is a required field.'; // if name is empty, store error } Done.

You are missing the closing ) that goes with the opening one on the - CONCATE( Alternatively, you have an extra ( before the (IF that could be removed.

The datetime class is fairly new and immature code. I suspect in your case that you are up against a bug in the serialization or un-serialization of it that is occurring when the session data file is saved or retrieved. I just found this in the php5 change log for 5.3.0 - Added new date/time functionality: support for serialization and unserialization of DateTime objects.

Dates with the format YYYY-MM-DD can be compared directly as strings, because the same position in each date has the same magnitude and the fields making up the date are ordered from left to right, most significant part (year) to least significant part (day.)

Session data files (assuming you are using php's built in session save handler) are stored in the folder indicated by the session.save_path setting.

^^^ That's not what your logic is doing. Your logic says if $_POST[errors] is set AND $_POST[noIdentity] is set, i.e. both of them must be set to produce a TRUE value. In the last code you posted, you have $POST['noIdentity']. It should be $_POST['noIdentity']

As already stated, the 800M byte file is being uploaded but at some point you are doing something that needs to allocate more memory than what is available. Someone suggested that you post your code so that they/we/I/someone could see if your code is doing something that would consume memory and not make it available when needed. For all we know, the line number where the error is occurring at is after you have successfully read the file into a php variable, but you are doing something to it, like making a copy into another variable. If you have changed the code from the last time you posted the error message with the line number, repost the current error message, with the line number, that matches the code you post.

@MasterACE14, all of the following are valid uses of a session variable - <?php $_SESSION['id'] = "abc"; $_SESSION['id'] = array(1,2,3); $d = new DateTime('2011-08-01'); // could also be a user written class (class definition must exist before the session_start statement) $_SESSION['d'] = $d; $_SESSION['d'] = new DateTime('2011-08-01'); // could also be a user written class (class definition must exist before the session_start statement)

The code works as expected for me on a Win xp, php5.3.8 system. Either there is a bug in your php version or there is a problem with the session. You could open the session data file in your programming editor to see what is being stored. FYI - the serialize/unserialize issue applies to resources, not objects, provided you have not stored a resource in an object. Note: You don't need to keep copying to/from the session variable, just use $_SESSION['d'] = new DateTime('2011-08-01');

Too bad this was a duplicate/cross-posted thread. This was solved in the other thread (the data is serialized and simply needs to be unserialized to get the original array back.)

update your_table set type = 2 where id = 2 or id = 4 or update your_table set type = 2 where id in(2,4)

Warning: unlink(upload/movies/ ) $data['movie_name'] is empty ^^^^ (there's no file name in the error message showing what unlink was trying to do), because you have already deleted the row from your table in the first DELETE query and the last SELECT query returns zero rows.

if(!isset($_POST["post_desc"]) || $_POST["post_desc"] = ""){ <--- one = sign is an assignment operator. That if() statement, when it is executed, is assigning an empty string to $_POST["post_desc"].

http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_week

The preg match patterns need delimiters around them.