--- whoisquilty <[EMAIL PROTECTED]> wrote: > James is right .... $prodvar is not set. I set it in a URL on the page > before. Which is how it > needs to happen, as it is set when the user clicks the link in a list of > choices. That link sets > the variable for the next page which brings up the results of the query I'm > having the > problems with. > > In the code on the previous page, I said: > > <a href="productions.php?prodvar='.$shows["showid"].'"> > > This has worked beautifully in the past on my previous two hosts. Is there a > better way? > > Regarding the version of PHP: > > New host has: 4.3.11 > Old host has: 4.4.1 > > The old host has more listed under configure command than the new one. > > The new host has CGI/FastCGI listed for Server API with the old host listing > Apache. > > Jeremy
The problem is not how you set the variable in the URL but how you pick it up in the second script which performs the database query. Based on the evidence provided thus far, it seems to be a case of a register_globals on/off issue. Your old server likely had it on and the new one has it off -- as recommended for security. In your second script with the database query you can pull the value from the URL like this: $prodvar = floor($_GET['prodvar']); The floor function rounds down to the next lowest integer. It also takes any non-numeric value and turns it into a 0. It is a simple bit of validation and you may want something more. The validation of data from the outside user cannot be emphasized enough. Any time you are using untrusted user input in a query, Linux command, or file reference, you must validate it to ensure that it is in the range of expected values and does not contain any tricks. For details and examples look up "SQL Injection". In the php_info() script that two others have urged you to write and test, you can find out the value of register_globals on this server. I predict it will be off since that is the default, the recommendation, and a good thing to do. James Keeline
