PFMaBiSmAd

Like the error states, turn off one or both of the settings that are mentioned in the message.

Based on what the code is doing, that format is made up of YYYY, MM, DD, HH, MM, SS, milliseconds, and microseconds. The mysql data/time functions understand that, but I threw in a LEFT() function in the following to be safe for any future changes mysql might make to how it handles warnings. This single query will delete rows for users who have a last_session_start date more than 120 days ago - $result = mysql_query("DELETE FROM gamezer_users_1 WHERE userstatus=1 AND last_session_start !=0 AND DATEDIFF(CURDATE(),DATE(LEFT(last_session_start,14))) > 120"); This only addresses the DELETE operation. If you still want to send the email(s), you would need to convert that to a SELECT query, then loop through the rows that are returned to send the email, then execute it as a DELETE query.

You would only get that if your code already included lpanel.php and now you are trying to make a http request to it. You would need to provide a lot more detail about what your code is doing, but best guess is that you need to create a separate file with the code you need in it with a session_start() statement.

Your code is making a HTTP request for lpanel.php. That has nothing to do with any other content on the page and you must put a session_start() statement in lpanel.php if you want to use session variables in it.

If you output the query statement in $query and output mysql_error() as part of your error reporting, it will help by letting you see what the query actual is and by indicating what mysql found wrong with the query.

More importantly, the second parameter in a mysql_query() statement is the connection.

As already stated, the session.cookie_lifetime setting would only have an affect on a session if all the instances of the browser have been closed. Since you have not stated under what conditions the problem occurs (browsing to a specific page; sitting idle on a page for a time (and approximately how much time for when it works and when it does not), then refreshing a page or browsing to a different page...) it is not really possible to pin down which of the dozen or so possible things could be causing the problem. Based on the information provided so far, I'll guess you have a log in script that has intentionally set the session.gc_maxlifetime setting to a small value, either in the script or using a .htaccess file that is causing this symptom.

A) Which php.ini are you changing (the master one requires that you stop and start the web server to get any change to take effect.) B) Have you confirmed that the settings are actually being changed by using a phpinfo() statement (in case the php.ini that you are changing is not the one that php is using.)

The session.cookie_lifetime setting only affects the time the cookie will be valid when all instances of the browser window/tabs are closed. If you are on a shared web host and are using the default session.save_path setting (you have not deliberately changed it), and you are getting short session 'time outs' (shorter than the default 24 minutes), someone else has probably set a short session.gc_maxlifetime setting in a misguided attempt to get the basic operation of the session garbage collection to do something it is not intended for. To get your session settings to affect only your session data files, you will need to set the session.save_path to be to a 'private' folder within your account's folder tree.

Your current problem is that the variable that is receiving the 'Running' value is not what you think it is. Echo $the_query so that you can see what exactly it is.

Just randomly trying different syntax is not how you program. Your current problem is that string data in the SQL query statement must be enclosed in single quotes, in the query statement.

If you use a phpinfo(); statement in a .php file, the Loaded Configuration File value that is output will be the php.ini that was loaded. In programming, you cannot assume anything. Computers only do exactly what their code tells them to do. If you don't know something for certain, you must check and confirm that it is what you think it is. Edit: What method did you use to install php, because if you used the .msi installer, you are expected to enable extensions through the Windows control panel add/remove item for php. You can alter the php.ini all you want in this case and you probably won't get it to work.

Is the php.ini that you are changing the one that php is using?

http://dev.mysql.com/doc/refman/5.0/en/insert-select.html

You would need to create a desktop short-cut or a favorite/bookmark in your browser that contains the URL that you would type into the browser, repeat for each different URL.

Playing the devil's advocate, what if the dynamically produced SQL that was being validated for syntax errors was for a DELETE query and the resulting bad syntax either did not get built with the LIMIT 0 term or it was treated as a comment or got enclosed in quotes so that it was not seen (perhaps as an argument NOT in a WHERE condition) and all the rows just got deleted? If you are talking about needing to do this as the result of putting data into an existing syntactically correct query, as long as you properly validate and escape the data, you cannot produce a syntax error. There are some database errors that are not due to syntax, such as the 'database has gone away' type that are out of your control and you still need error checking, error reporting, and error recovery logic in your code to address them. It does not really make sense to add the extra overhead of trying to detect a syntax error in a query before you run it in order to prevent the syntax error that you would get when you actually do run it.

Anything that is not in between php tags is in-line (static, not dynamic) content in that file and will be output to the browser.

You php.ini must have the output_buffering setting turned ON or set to a specific value, thereby hiding the problem. I would recommend turning output_buffing OFF because that will result in a development system that will help you produce code that will work on all server configurations.

The actual form method is get

You pass the value pass into the function as a parameter when you call the function - <?php function test($a) { $a = NULL; return $a; } $a = 1; $a = test($a); var_dump($a); ?> The above code passes the value in as a parameter and returns the result (you cannot actually use unset in this example like the original code was doing because $a would no longer exist and could not be returned.) If you actually want to unset a main program variable, I recommend just using unset() in your main code rather than making a function with it in it. Replacing a call to a built in function with a call to a user function that only contains a call to that built in function just adds unnecessary overhead to your program.

You probably have some white-space on that line after the ?> tag.

A) Ask your web host to publish information in their FAQ section exactly what php.ini configuration changes they just changed so that the customers would have a chance at finding all the things they need to update in their scripts. I am amazed at the number of web hosts that make changes to the server configuration and don't bother to notify their customers what they changed (of course some web hosts don't even know that they made such a change.) B) It appears that one of the things they changed was to finally turn off register_globals. Register_globals were actually turned off by default almost 8 years ago, but a lot of web hosts did a great disservice to their customers by leaving it on. Had they turned it off, you would not be having a problem today because all the existing scripts that relied on register_globals would have either been updated or would have disappeared long ago and new scripts would have not have relied on them. Short answer - register_globals magically populated program variables from the actual $_POST, $_GET, $_COOKIE, $_SESSION, $_FILES, $_SERVER, and $_ENV variables where the data comes from. Because this overwrites same named variables and it also back-populates $_SESSION variables it allows hackers to magically set $_SESSION variables and a lot of sites have been taken over (this allows hackers to become logged in as administrators to scripts and it also allows hackers to change configuration variables in code that then gets the hackers php code to be included into a file instead of the intended code.) So things like $PHP_SELF (which actually comes from $_SERVER['PHP_SELF']) and your form data, like $name (which actually comes from $_GET['name']) are no longer being set and you need to use the correct $_POST, $_GET, $_COOKIE, $_SESSION, $_FILES, $_SERVER, and $_ENV variables in your code. You should also change any <? tags to <?php and any <?= tags to <?php echo to avoid problems that short_open tags either are or will cause in your code.

If the query is a SELECT, you can use EXPLAIN to do what you want. None of the other types of queries could be checked without actually executing them.

Nope, but since you should only be putting data into a preexisting tested query where the syntax of the query is known to be correct, that should not be a problem if you have validated and escaped the data. What sort of problem are you having that you are trying to solve?

global and $GLOBALS should not be used in functions anyway because that breaks the general purpose nature and encapsulation that functions are designed to provide.