PFMaBiSmAd

Sadly, a lot of development systems using the xAMP all in one packages are NOT setup properly as development systems where the code you get working on them will work on the majority of actual servers. Your development system has output_buffering turned on in the master php.ini. I recommend that you turn it off (it is off on your live server) so that code you develop on your localhost has a chance of working on your live server.

How about, lock the table(s) as necessary, bulk insert the new rows into table A. Use a single INSERT ... SELECT query to insert the new rows into table B that correspond to what was just inserted into table A. Execute UPDATE queries on table B to fill in the unique information for each row.

It sounds like the domain name record at your domain registrar is still pointing to the name server for the old server as well. With the DNS zone records still present, the IP address was resolving to an actual web server, the old server, and it actually received the http request, but the requested content was not present, giving the 404 response. When you removed the DNS zone records, the IP address is no longer resolving to any web server.

You might want to check the web server access log and error log on the remote system to see what kind of entries there are that correspond to the http requests being made to it. Are you doing any URL rewriting or checking of thing like HTTP_REFERER on the remote system that would cause the remote server to return a http 404 response code for what you are requesting? Have you recently changed any of your web hosting or moved your domain registration to a new registrar? This almost sounds like a DNS issue where the request is actually going to the wrong server because an old cached DNS entry is being used some of the time or every time.

Are you on a shared web server? If so, have you set your session.save_path setting to point to a private folder within your account's folder tree so that your session data files will only be affected by your session settings? It's likely that some other account has set session.gc_maxlifetime to a short value in a misguided attempt to use it to log people out, but when session garbage collection runs it deletes your session data files using the shorter session.gc_maxlifetime setting in affect at the time.

Your <form ...> tag needs the following in order for an upload to work - enctype="multipart/form-data"

Here is a mod_rewrite solution that will work (tested) - # rewrite /inline/file.ext to /inline.php?file=file.ext RewriteEngine On RewriteRule ^inline/(.*) /inline.php?file=$1 [QSA,L] The URL would be http://yourdomain.com/inline/file.ext I used 'inline' in this example because you are trying to get the inline disposition to work, but you could use a different name in the path in the URL and in the actual .php file that gets called. Because the filename is on the end of the URL, the pdf reader uses it when you save the file in the reader. This should work for all your files.

You would need to determine under what repeatable conditions the problem occurs. If it is after a specific amount of time (say 24 minutes) with the browser displaying one page, it is likely due to the session ending due to session garbage collection running and deleting old (based on the last access time) session data files. Is it only on one page? On any page, but after sitting there for an amount of time? When switching between specific pages?

There is a missing ; on the line before the line where the error is reported because php cannot determine what the programmer intended when he left off the ;

if (strtolower($match_fetch->username) == strtolower($username)){ echo "You cannot play yourself sado."; }elseif (strtolower($match_fetch) != strtolower($username)){ $match_fetch is an object. In the relevant code above (does anyone read their code after they write it, especially when it produces an error?) you are referencing $match_fetch->username in the == comparison. I would bet the intent is to reference $match_fetch->username in the != comparison.

In playing with this and in searching for solutions, you will find that using inline for the content disposition will cause the file to be displayed inline but that the browser/pdf reader won't use the filename.

Setting the Content-Disposition to inline instead of attachment should work -

And is your browser configured to open pdf's? Does the browser you are using for testing open .pdf documents on other sites?

There is no reason to use eval() unless you are dynamically writing php code in a string someplace. All you are doing is evaluating array index names - $e = '3'; $h = '4'; $values = $_POST['value' . $e][$h]; Edit: And if you lose the word 'value' from the form field, you can do what salathe posted above.

That's because $_POST['submit'] does not match what your form sends, so that was a waste of your time. If the two lines of code that I posted and you added did not result in any error messages from the mail() function, then your mail server has likely been configured to operate 'silently' and not return error messages. This is generally being done to prevent hackers from feeding invalid information to a mail server in order to triggers errors that then gives them information about the mail server. You are using a Name: field in the headers. To the best of my knowalge, there is no such SMTP field and you are not using a From: field. It is likely one or both of these things is causing the mail() function to fail. You should be using a From: field with an email address in it that is hosted at the sending mail server. The Reply-to: address should be the email that the visitor entered, which is what you have now. There should be no Name: field.

Was the file with the phpinfo() in the same folder where your upload script is at? You may want to check with your web host because if they have not configured the server to allow you to change the php settings, they might not actually get changed to the values you set, despite what the phpinfo() shows.

Are those the local values or the master values? Also, You would not be getting that value for the ['error'] element unless the size of the file is larger than the upload_max_filesize setting that php is using. Either the size of the file is not what you think it is or the actual setting that php is using is not what you think it is.

Only the relevant part - http://en.wikipedia.org/wiki/Relevance_%28disambiguation%29

Yes, but what are the actual settings that a phpinfo() statement shows and where exactly did you change the settings at? If there is a syntax error in the setting or the method that you used to set it is not the one that php is using, the setting is not actually change to what you think it is.

So, did you try - LOAD DATA LOCAL INFILE

How do you know you are logged in at that point in the code? The posted code is dependent on what the $context['user']['is_logged'] variable has in it. Does it have the value in it that you expect? Have you checked by echoing it? Taken out of context, that few lines of code has no meaning to anyone else but you. How could we possible know what code is setting the $context variable or what value it has in it when you execute the code on your server? It is up to you to troubleshoot what your code is doing on your server.

In programming there are several different ways of accomplishing any task. The actual sql posted is valid. You do not need to provide a list of column names if you are supplying a value for every column and the values are in the same order as the columns in the table.

There is nothing out of date in the posted php code. If you are having a problem with that php code you would need to state what it is doing or not doing and what errors or other symptoms you are getting for any one to be able to help you with it.

Worked for me. I'll guess file is not a .php file and/or it is still being opened directly in the browser and not through a URL.

Look in your programming editor's file save choices.