PFMaBiSmAd

Both from and to are mysql reserved keywords - http://dev.mysql.com/doc/refman/5.0/en/reserved-words.html If you were using mysql_error() to troubleshoot why your query is failing, you would be getting sql syntax errors at those keywords where they are being used as column names. You should rename your columns to something else.

I'll second that. You are not defining javascript before the php because php simply outputs content to the browser. That content can be HTML, CSS, Javascript, media... If the content that you happen to be outputting contains some javascript, than that is what the browser receives at that point on the page. You are also not calling javascript in php, for the same reason. The HTML, CSS, and Javascript that appears in a .php file are just a bunch of inert characters. They don't have any meaning until they are received by the browser and the browser renders them. Ummm. The novice programmers that are looking for information care.

There are very few incompatible differences going from php4 to php5. Most php4 code will work as is under php5, given identical php.ini configurations. Most problems are due to code using outdated features, some of which were turned off by default over 7 years ago. The php.net documentation contains migration sections that list the specific differences going up from one php version to the next. Aside from using short open tags, that script should not have any problems running under php5. What exact symptoms do you get?

Php is a server side scripting language. The web server/php outputs a web page to the browser. Once a web page has been sent, the web server/php has no direct connection with what occurs on that web page. If you want to dynamically do something on a web page after it has been output by the web server/php, you need to use javascript. Do you have an example of what your web page looks like and what information you want to scroll on it and where and how often you want to get and change that information?

See this link - strftime

If the magic_quotes settings are off, all you need to do is mysql_real_escape_string() on string data. There would be no addslashes/stripslashes...

If you have successfully inserted data that did contain special characters, like a single-quote, and you are not specifically escaping the data in your code, then it is likely that the magic_quotes_gpc setting is ON and php has been escaping your data for you. However, magic_quotes_gpc does not escape all the special characters that can break a query, so if it is on, you actually need to strip the slashes and then use mysql_real_escape_string() on the data. magic_quotes_gpc has been completely removed in php6, so it will be necessary for your code to use mysql_real_escape_string() on string data in order to prevent special characters from breaking the query syntax and to help prevent sql injection.

The actual \ characters are NOT inserted into the database. They are only present in the query string so that the special characters don't break the syntax of the query. When the query string is parsed, the character they were escaping is treated as the literal character and the \'s are eliminated. If you see the \ characters in the actual database, it means that your data was escaped twice.

And you have confirmed the actual runtime values of the error_reporting and log_errors settings using a phpinfo() statement? Beyond that, you would need to post actual code that produces the symptom.

You are likely getting a fatal parse error. Putting the two lines - ini_set("display_errors", "1");/ error_reporting(E_ALL); in your script won't help display fatal parse errors. Those lines are only used/suggested for in a script file when it appears that the code is actually being executed (parse errors prevent the code from even being executed.) Set the display_errors/error_reporting settings in your php.ini in order to see all the php detected errors. Stop and start your web server to get any change made to php.ini to take effect.

http://www.dyndns.com/

And what exactly happens? What do you see in front of you that leads you to ask "why can't i view my scripts"

You can only do greater-than/less-than date comparisons when the format of the date is from left to right, YYYY-MM-DD, which is one of the reasons why a DATETIME data type is formated like it is. You need to get the values you are comparing with your DATETIME column into the YYYY-MM-DD format, not the other way around. To just use the DATE part of a DATETIME value, use the mysql DATE() function in your query.

Back to the basics. How did you obtain and install php, as that affects how you enable extensions. Specifically, did you use one of the WAMP package or the php .msi installer, or the php .zip package? Is the php.ini that you are changing the same one in the Loaded Configuration File line in the phpinfo() output?

When you open the saved file using a programing editor, what exactly is in it? How are you browsing to this file or what does the link look like in your html? What you are doing works, so it must be something specific to what or how you are doing it.

Couldn't save it where and how, exactly?

Actually it shows that you got caught by using lazy-way short open tags in your code. Short open tags are NOT always enabled on any particular server and you won't always be on a server where you will have the ability to turn them on. Short open tags should not be used at all. Why, when you have full opening php tags in the rest of the posted code did you then put in some code using short open tags? Be consistent. Then find and correct what ever is causing output on your page that is occurring before a header() statement or rearrange your code to put the header() before the output.

That's because session garbage collection is only intended to be used to delete old session data files, not to end sessions or to log someone out. Garbage collection runs randomly, so session data files could randomly exist for a long time on a server with few session_start() statements being executed. The session settings like session.gc_maxlifetime are global among all your scripts and if you are on a shared web server using the default tmp session save path, they are global among all the scripts of all the accounts running on the server. To have different values on different pages would require you to also set the session save path to different folders for those pages, but this would also mean that the session data used on one page would not be present on another page. If you logged in one one page and then went to a page using a different session save path, you would need to log in again. Folks, a session is just a 'container' that allows variables to exist between page requests. Don't rely on the underlying operation of a session to accomplish anything in your application, like log someone out. If you want to do something specific in your application, like have a shorter automatic log out on a page, you will need to store a value in your session that indicates the last access time on that page and then check on the next page request if that last access time is farther in the past than a limit you pick and take appropriate action in your code.

How about posting the actual line of code with the mysql_connect(). Is the php.ini that you are changing the one that php is using and did you stop and start your web server after making any change to the php.ini to get it to take effect?

You need to set both the session.gc_maxlifetime and the session.cookie_lifetime to the longer value, because you need both the session data file on the server and the matching cookie from the browser in order to resume a session. If you are on a shared web server and you are using the default tmp folder for the session save path, you must also set the session save path to a private folder within your account's disk tree. When you use the default tmp folder on a shared web server the SHORTEST session.gc_maxlifetime setting of all the scripts of all the accounts running on the web server will WIN and cause you session data files to be deleted when garbage collection runs. When you set the session save path to be to a private folder, you session data files will only be affect by your session settings. You must also set your session settings before EVERY session_start() statement or the master values in the php.ini will be used. It is best to globally set them in a .htaccess file (when php is running as an Apache Module) or in a local php.ini (when php is running as a CGI application.) Session variables are intended to be used for one single browser session. For a "remember me" type of login, you should actually use cookies to save a unique identifier, not a session.

If you put those two functions at the start and end of your main index.php file (or at least before and after where a file being included generates a header() error) and it did not help with a header() error, then you are probably including the content using a URL instead of a file system path and this will make your site take longer to load because of the extra http requests. It is always best to find and fix the cause of a problem. In this case, you got something to work but it appears that you are just masking a bigger problem within your code. What does your include statements look like?

The above setting disables NOTICE messages. You should not disable NOTICE messages when you are developing and debugging php code as there will be a number of typeo's you will make and other novice errors that the NOTICE message will help you find and fix.

The Loaded Configuration File line in the phpinfo() output is the php.ini that php is using.

Exactly at what point does it not work? For all we know the path in the require() statement is incorrect and you are getting a fatal runtime error. What is it doing? What are the symptoms?

If only a specific maximum number of form fields is passed, it is likely that the web server has the Suhosin Hardened-PHP patch applied. You need to talk to your web host about the limit and/or break up the data into separate pages.