Recently I developed a web application for a client using PHP and SQLite. As you might expect, I did the development on a Linux system, and all seemed well. When the time came to move to the client's production system, which runs IIS 6 on Windows Server 2003, I naïvely assumed that it would be a simple transition - after all, PHP has been supported on Windows for quite some time. Unfortunately, this turned out not to be the case.
Installing PHP on the Windows server was straightforward, as Microsoft offer an official installation tool for platforms such as PHP, which goes by the name of Web Platform Installer. There's a link to install PHP using this tool at the top of Microsoft's PHP site. I installed PHP successfully and tested it with a simple page calling phpinfo(). All seemed to be well.
The problems began when I copied the web application onto the Windows server. Some of the pages worked correctly, but those that modified the SQLite database gave a 500 Internal server error. After some investigation, there turned out to be two causes of the problem. The underlying problem was that the SQLite database, and the directory it's located in, need to be writable by the user that's running the IIS site. In the case of publicly accessible websites, that means the Internet Anonymous User. For protected websites, it'll need to be the users who have login access.
Normally this wouldn't result in an internal server error. On the Linux testing system, errors of this kind resulted in a "readonly database" or "unable to access database" error message. The key turned out to be the difference between the PHP configurations on Windows and Linux. The Linux setup had error messages in the browser enabled (display_errors = On), and error logging disabled (log_errors = Off) in php.ini. This isn't recommended for production systems, as any errors will be revealed to the end users, so on the Windows system browser error messages were disabled but error logging was enabled. By default, PHP errors are written to the IIS site error log, but it turns out that by default the PHP runtime doesn't have write access to the error log. Thus PHP was trying to output error information about not being able to access the SQLite database, failing to write to the error log, and generating the error 500.
The solution was to create a log file, writable by the IIS site user, and modify php.ini to log errors to this file by setting error_log = <filename>. Once that was done, PHP errors no longer generated internal server errors, I was able to diagnose and fix the underlying SQLite problem, and the application worked the same as it did on Linux.
Thank you very much for the post, enabling the error log as you described saved me from pulling my hair out.
you save my project. last minute sqlite error just... before presentation. thanks for post.