FinnViking

The PDF files are OK, they do open correctly in Adobe Reader. I read from somewhere that IE is somewhat picky about things, therefore I downloaded and installed Firefox, and voilá, the xml stuff started to work as it was supposed to. And changed the script from having been header("Content-Type: application/octet-stream"); header("Content-Disposition: inline; filename=\"".$file_name."\""); header("Content-Length:".filesize($full_path)); sleep(1); readfile($full_path); to: $path_to_image="c:\\temp"; $file_name=$_GET['file_name']; $full_path=$path_to_image."\\".$file_name; $fop=fopen($full_path, 'r'); header("Cache-Control: no-cache, must-revalidate"); header("Content-Disposition: attachment; filename=".basename($file_name)); header("Content-Type: application/pdf"); header("Content-Length:".(filesize($full_path))); sleep(1); //readfile($full_path); fpassthru($fop); Although I also added, as You can see, some "header("Cache-Control: no-cache, must-revalidate");", which might have had some effect on the outcome. But anyway, now I can "import" a xml - file, and then another, and then another, etc. About the PDF files not opening...I found that if I place the files (and make the script look for them) in a folder where the path to this folder does NOT include any spaces the images were directly viewable. I also tried to get the thing working by saving the PDF files on a remote (network) drive (NAS), which was mapped as drive Y: to the workstation. This had the same effect as a path with spaces: Only now the error message was not the one in the beginning, but rather one which mentioned the file having been encoded somewhat incorreclty. But anyway, it works now, from a local folder, with the path not containing spaces. The work continues, though, since I would like it to work using the NAS also. But so far, I consider this case closed. Thank You for Your efforts.

The php.ini files are identical, and the only thing I did change (in both of them) was to un-comment the lines extension=php_pdo.dll extension=php_pdo_sqlite.dll the rest of the php.ini - files are copies of the "php.ini-recommended" as it was when I unzipped the package. As for the error messages. in the "PDF not showing on 64-bit" it is an Adobe Reader error saying "File does not begin with '%PDF-'. And yes, the file to be shown is outside of the web root, but as I said, this has no effect on the 32-bit machine. In the other case, not being able to process "uploaded" (from within the web root), the error message is of my own production, but is the result from $dbh=new PDO('sqlite:/path/to/sqlite/database.db'); //Get the file to be processed from POST $file_to_process=$_POST['csv']; //Add the static path in front of file name, as POST only gives us the file name, but not //the path, therefore if the file is outside the dir where this script is, it cannot be //processed $path_to_file_to_process="././xml_test_files/"; //Add the path to the filename $file_to_process=$path_to_file_to_process.$file_to_process; //Put the xml file contents into a variable $xml, show a message if not successful and die if(simplexml_load_file($file_to_process)){$xml=simplexml_load_file($file_to_process);} else { include ("html_headers.txt"); include ("bhr_page_header.txt") echo "<table align=\"center\"><tr><td align=\"center\">"; echo "<div class=\"head\">Unable to process file $file_to_process</div>"; ;...... That is, the error is from the "if(simplexml_load_file(..." that goes wrong somehow, on the 64-bit machine.

I have Win 7 home premium, Apache 2.2 (installed using the .msi) and PHP 5.2.14 (downloaded as "php-5.2.14-Win32-VC6-x86.zip", installed manually, it works) on both machines. The other is 32-bit and the other is 64-bit, both Windows 7 Home Premium. When I run the exactly same script on one machine, it does what it is supposed to (32-bit), but on the 64-bit it does not. Basically this appears in two situations (so far): I have a script that reads a (xml) file into a simplexml object, and if this is not successful, it prints an error message. On the 32-bit machine I can import (read) another xml file at once once the first one is processed (into a sqlite database), but on the 64-bit machine it gives me an error originating from the fact that the script did not manage to create the simplexml object. The other situation is when I want to open a specific PDF - file in a browser window (Firefox, the newest one, on the 32-bit machine, IE something newish on the 64-bit). The file exists, the path to the folder is in the Path environment variable, I can open it normally etc on the 64-bit machine, but when I click on a link that is supposed to open the file in a browser window I only get an error message saying that the file does not start with "%PDF.... Needless to say, the precisely same script works just fine on the 32 bit machine. $path_to_image="D:\\path_to_folder\\"; $file_name=$_GET['file_name']; header("Content-disposition: inline; filename=".$path_to_image.$file_name); header("Content-type: application/pdf"); readfile($path_to_image.$file_name); The above code is from the part that receives the file name from a form (other file). Anyone noticed anything like this? Any suggestions? Have been trying to figure this out for days, now... Oh, forgot: In both cases the thing is accessed as/from "localhost".

Thank You, craygo, so far. I´ll have a closer look at Your reply tomorrow, it is quite late over here now. And method=POST is the one in use, is there a difference in what You write in that case?

I have tried search here, but no luck so far, therefore I ask: Is there a way to jump back to the previous page the user visited, using php? I am validating user input from a html form, and want to display an error message if something is wrong, and with this error message I would like to show a link or something that not only takes the user back to that form [u]but keeps the stuff the user did write in the form fields.[/u] Provided that this is possible? If not, I guess I will have to live with a empty form, in which case I think I can manage by myself...