PFMaBiSmAd

Perhaps because that is not in the MySql forum section.

Or you could use the glob function as that returns an array in alphabetical order by default.

An integer may be the fastest choice for a data type, but the extra manipulation you must use to get a Unix Timestamp into and out of a usable format makes it the worst choice to use to store date/time information in a database.

Use a DATE data type. To get your existing format into a DATE type, use the mysql STR_TO_DATE() function in your query.

SELECT * FROM `schedule` WHERE DATE(date) ='2010-01-01'

Setting error_reporting to E_ALL and display_errors to ON will probably help by exposing all the php errors that might be occurring. Check that these two settings actually get changed by checking the phpinfo() output. The phpinfo() output is actually more valuable than the actual php.ini because it shows the actual settings, which can be modified by http.conf, .htaccess, and local php.ini files and the possibility that the php.ini that you are looking at is not the one that php is using.

Data is always 'produced' somewhere. If you examine your form field names, you will find there is not one by the name 'date0' I'm also going to guess that your form validation code is causing the query to be skipped, but it (your validation logic) is also not displaying a user error message telling you that the field did not validate (due to the mismatch between the name of the form field and the name of the POST index.)

Unfortunately, as has been written many times, what trigger_error() reports and displays is dependent on the error_reporting/display_errors settings. For debugging, please add the following two lines of code immediately after your first opening <?php tag on the page - ini_set("display_errors", "1"); error_reporting(E_ALL);

Neither can we because you have not posted any specific information about your code or data. I'm going to guess that your form (or whatever the source is of your data) is invalid HTML and the data is submitted in one browser but not another. It would take seeing the relevant information and code showing where the data comes from and what the data actually is that is not turning up in a session variable.

Just an FYI, session_register() does actually do something when register_globals are OFF (php.net really really screwed up when they did not correct and then permanently disable all the behind the scenes code when register_globals are off.) It causes the normal variable that is being registered to take priority over any $_SESSION variable by the same name and the value from the normal variable is written to the session data file when the script ends, but it does not update the $_SESSION variable by the same name within the script.

String data in a query must be enclosed in single-quotes. You are using back-ticks. Back-ticks causes mysql to treat whatever they surround as column or table names, not data. Change the back-ticks to single-quotes. Back-ticks are only used around column and table names and only when they require special handling and should be avoided as using them are mysql specific.

Back-ticks ` ` are used around identifiers (i.e. table and column names) when they require special handling. Single-quotes ' ' are used around string data values.

If you want a session to persist for a time after the browser is completely closed, you would need to set the session.cookie_lifetime to a non-zero value (default is zero, which means - until the browser is closed.) If you need to make the session data files last longer (i.e, the session is ending while someone is on your site for an extened period of time, but is not doing page requests which would keep the session data file 'last accessed time' updated) you need to extend the session.gc_maxlifetime setting. However, if you are on shared web hosting and are using the default/common session.save_path setting, the shortest session.gc_maxlifetime of all the scripts running on the server will 'win' and you must set the session.save_path to point to a 'private' folder within your account's folder tree so that your session settings apply only to your session data files. All of the session settings that have been mentioned must be set before every session_start() statement, so it is best to globally set them in the master php.ini (when you have access to it), in a .htaccess file (when php is running as an Apache Module), in a local php.ini (when php is running as a CGI application), or in your script.

Did you even bother doing this -

The symptom seems like you are changing either the hostname (subdomain) or the path when you redirect and the session cookie is not set up to match a hostname or path that is different than where the session cookie was set. What does a phpinfo() statement show for the session.cookie_domain and session.cookie_path on both the system where this works and on the system where it does not work? P.S. You need to put exit; statements after each of your javascript redirects. Without the exit, the remainder of the code on the 'protected' pages is still being executed. All a hacker needs to do is ignore the redirect (or simply have javascript turned off) and he can access the 'protected' content on your pages.

What are the actual settings shown in a phpinfo(); output? Most of the xAMP packages cause a different php.ini to be used than the one you think.

The php parse error is because you cannot directly put single-quotes inside of a single-quoted string. It is generally best to use double-quotes to start and end a query string.

The problem is not the time() function, the problem is the date() function. It takes into account the current time zone setting. See this link - http://us3.php.net/gmdate

No one said to do that, it has no meaning. Because who ever configured that system did not follow recommend php.ini settings. register_globals were turned off by default in April of the year 2002.

Both settings that have been mentioned can be changed in PHP_INI_ALL. This means any of - A) The master php.ini (when you have access to it), B) a .htaccess file (when php is running as an Apache Module), C) a local php.ini (when php is running as a CGI application), D) in your script using an ini_set() statement, E) in a http.conf or even the Windows registry if you have access to them... I'm going to guess you can use B), C), or D).

They are null characters \0. You can use the trim function to remove them.

While it is true that $_POST is an array that could be exploded or iterated over, what you really need to do is use HTML arrays for your form fields - http://us.php.net/manual/en/faq.html.php#faq.html.arrays You can than iterate (using a foreach()) over the specific fields.

Add output_buffering, register_long_arrays, and session_register... to cags' list. This can be a problem with the the code if the code is using old out of date methods (in some cases things that were depreciated 7 years ago.) To troubleshoot, pick ONE problem at a time and find out why the code is exhibiting the symptom. It is always best to fix code rather than to turn on the offending setting. Many of the settings that cags and I posted have been completely removed in upcoming php6, so getting the code up to current standards now, will prevent you or someone else from wasting even more time in the future fixing it - short_open_tags - should never be used because they can be turned off magic_quotes_gpc - all the magic quote settings have been removed in php6 register_globals - removed in php6 output_buffering - should not be relied on to fix code (should only be used if you want to buffer output) register_long_arrays - the long array names have been removed in php6 session_register/session_is_registered/session_unregister - removed in php6

If you were to put the following two lines of code into the main file being requested, immediately after the first opening <?php tag - ini_set("display_errors", "1"); error_reporting(E_ALL); you would probably find out which include statement is failing due to the path being incorrect or perhaps due to a conditional statement being FALSE (with the include inside of the conditional.) You need to get your include statements under control. You should not have them 4-5 levels deep. You should have a main application file that includes things it needs, period, i.e. one level of include files. You should also only put any error_reporting/display_errors settings into your main file, so that you can take them out later and so that they are in effect for all the remainder of the code on the page. You should in fact set those two settings globally in your master php.ini (or a .htaccess file or a local php.ini.) When you see a suggestion in a forum like this to add those two settings in a script, it is for the case where "my code does not work and it is not telling me why" and we need to get some unconditional help from php's error_reporting/display_errors. In your case, where the error_reporting setting is in wide-variables.php, it is probably not doing any good because that code is never being included.

Is your SELECT query inside some conditional logic so that is it not executed on the same page request that is due to the form submission? I would recommend the following headers to prevent caching of dynamically produced content (and make sure you sure you are not attempting to output headers after you have output content) - header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1 header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past