The project used a SQLite database, as the data stored is minimal (some hostnames and logins). On the testing servers, we had no problems using and working with these, and all needed parts happily talked to the datafiles. Alas, when running it on my Macbook Pro running Leopard, I got some errors from symfony, complaining the datafile was encrypted or no real sqlite datafile.

A quick check gave no real indication of the problem; the datafile appeared to be correct and worked using the CLI tools:

bernard:tmp bernard$ sqlite3 project.sqlite
SQLite version 3.4.0
Enter ".help" for instructions
sqlite> .tables
ftp_hosts_and_logins       sf_guard_remember_key
ftp_path                   sf_guard_user
sf_guard_group             sf_guard_user_group
sf_guard_group_permission  sf_guard_user_permission
sf_guard_permission
sqlite>

I even dumped the data to a text-file, and re-imported it using the cli-tools. Nothing helped, symfony (well, php) could not read the file. After a while, the problem was found. On Leopard, all the SQLite version 3 tools are included on the system, but in the PHP which is shipped with Leopard, the linked in library is version 2.

This would be no problem, but it seems Leopard ships without the SQLite version 2 cli tools, so there was no obvious way to convert this datafile to version 2 (or I should use the tools on the testing server, but then I had no way of using it from within my shell, which was no option).

This is just plain stupid. All libraries and tools are version 3, but the the linked library for PHP is version 2. Talk about forgetting something. As propel can’t work with PDO (another db layer in php), I either had to replace my PHP on Leopard with a custom-made one, or try to install the sqlite 2 tools. Neither seemed a good idea, I hate to replace my defaults with custom stuff.

It resulted in converting the SQLite database to MySQL and changing my symfony project to use the MySQL.