PFMaBiSmAd

What does the following show (put before the str_replace() line of code) - var_dump($row->name);

You will need to be way more specific about what you are trying that does not work, because the following DOES work with the single-quote at the end of the string - <?php $_SESSION['L_NAME0'] = "OMalleys'"; $_SESSION['L_NAME0'] = str_replace("'", "", $_SESSION['L_NAME0']); echo $_SESSION['L_NAME0']; ?>

The str_replace() you posted does what you are asking, provided you use it like I stated (edit: and CV just re-quoted for your convenience since you apparently did not see or read the post) - <?php $_SESSION['L_NAME0'] = "O'Malley"; $_SESSION['L_NAME0'] = str_replace("'", "", $_SESSION['L_NAME0']); echo $_SESSION['L_NAME0']; ?> Are you sure you want to remove the single-quotes or do you actually need to escape them? What overall problem are you having that you are trying to solve?

str_replace() returns the result. Are you assigning that value to something?

I would interested in knowing if casting that value as an INT solves the problem, because php has had a significant number of basic and reoccurring bugs (the php change log reads like the clown act in a circus.) The last suggested logic is equivalent to the original logic and it should work without error IF the data is what is being reported. I suspect that this is either something to do with register_globals (they are apparently on) or due to the page being requested more than once and when it is requested a second time $pro_id contains something (or nothing) that returns a result set that contains a value for $i['expires_date'] (which is not empty and is not a Unix Timestamp) that does produce the error message being reported. Edit: and in fact, since the code at the start of the page is setting setcookie("pro_id", "", 0, "/"); there is a high likelihood that the page is being requested a second time with pro_id being an empty string and the inconsistent results being reported are due to a mix of information from two sequential requests for the same page.

That may be what is in your table, but that is not what you are retrieving from the query.

Cannot really help you with your code when you do things like that and you don't mention that the code has been altered for the post. It just wastes everyone's time.

smtp.gmail.com uses port: 465

That's unlikely, because MD5 is a one way hash(checksum.) Once a value has been hashed, the only thing you can do with it is to perform comparisons with another MD5 hash value to see of the two original values are equal (with a high probability, because two different original values can produce the same MD5 hash value.)

Try - var_dump($_expires); I'm going to guess it is not empty but that it is not an expected value either. For debugging, add the following two lines of code immediate after the first opening <?php tag to cause all php errors to be displayed - ini_set("display_errors", "1"); error_reporting(E_ALL);

You cannot just put a submit button/form element on a page unless it is inside of a valid form, though some forgiving browsers might ignore that error and allow it to function and submit back to the same page. Your code is also using session_register(), which was depreciated long ago (7 years ago in fact) and cannot actually be used at the same time that you use $_SESSION variables. Since you are using the correct $_SESSION variables, remove all the code using session_register().

You can, but that would require that the code on your page is correctly setting $data['Valeu'] to what you expect. Have you echoed $data['Valeu'] so that you know what it contains? Should 'Valeu' be 'Value'?

I recommend posting your current code for both the form page and the login_success page.

That would be the code immediately prior to the code you posted in reply #2. Post the code from the point where the database connection was made up to the line $_expires = ($i['expires_date']);

The global keyword only has meaning when used inside of a function definition. Those cases where you have seen it used outside of a function definition were just wasted typing.

mysql_affected_rows does not take the result resource (it optionally takes the link identifier.)

Just because the server has 8gb of memory, does not mean that much memory has been configured for php to use. Add the following two lines of code immediately after the first opening <?php tag to find out why the script is stopping - ini_set("display_errors", "1"); error_reporting(E_ALL);

Temporarily change your code to - require 'C:\Inetpub\wwwroot\themes\default\layouts\layout001.php'; This will help determine if the / vs \ is the problem (php internally is supposed to convert / to \ under Windows, but perhaps not under IIS web servers.)

We could, but it will require that we know everything that you know about the problem, such as what the code is that is producing the symptom, what exactly "it will not work at all!" means (it is doing something when you try it, even if it is a blank page, and telling us that helps), and the URL of the live site would help as well. Did that mean this worked on your local development system?

And what was the php error message when you tried the last suggestion - require($_SERVER['DOCUMENT_ROOT'].'themes/default/layouts/'.$layout.'.php');

Your query failed to execute and returned an error instead of a result resource. For debugging purposes echo mysql_error(); on the line immediately after the line with the mysql_query() statement.

Since you are apparently using a URL for the include (it would help is you showed what $url actually is), none of the variables from the main code are availabe in the included file(s). Using a URL (i.e. http://somedomain.com/somefile.php) causes your web server to make a HTTP request back to itself, the same as if you browsed to the file. The file being included is processed in a completely separate process on the server and it is in its' own SCOPE. You must use a file system path to include files in order to maintain variable scope.

On service/interrupt driven multitasking operating systems, you cannot guarantee the order in which concurrent queries will be executed due multiple visitors on your site. Nothing that attempts to get the current highest row number/id can guarantee that it will be the value that was just inserted or that adding one to it will result in an unused value by the time a query is executed, which is why the mysql_insert_id() function that I posted in the first reply exists, because it WILL return the ID of the row that was just inserted by the current invocation of your script.

In case you come back and read your thread. Php and mysql are executed on the server, not in the browser. If you have a case where something in a form does not submit in one browser, it is likely that the HTML of the form is not valid. You are most likely using an image as a submit button. If so, check out this link to see how you would get it to work the same in all browsers - http://us.php.net/manual/en/faq.html.php#faq.html.form-image

If you are doing this on a live web server, the username and password would most assuredly NOT be 'root' and with no password. The hostname may or may not be 'localhost'. The hostname you use will be specified by your web host for your account. The hostname can usually be found within your control panel somewhere on the same page where you created your database and then created the username, and password to access that database. Your web host may in fact have already created a database (i.e. he only gives you one) and you would just create and assign a username and password to access that database.