PHP Fatal error: Class 'SQLiteDatabase' not found

[httpwebwitch]

I've installed PHP 5.1.6. on CentOS.

php.net says:

As of PHP 5 this extension is enabled by default, so simply do not disable it and it'll be available.

my php.ini has this in it:

extension=pdo.so
extension=pdo_sqlite.so
extension=sqlite.so

restarted httpd, but still no love. The error log says:

PHP Fatal error: Class 'SQLiteDatabase' not found

What am I missing?

[httpwebwitch]

phpinfo says:





PDO
PDO support
enabled
PDO drivers
sqlite, mysql


pdo_sqlite
PDO Driver for SQLite 3.x
enabled
PECL Module version 1.0.1 $Id: pdo_sqlite.c,v 1.10.2.6 2006/01/01 12:50:12 sniper Exp $
SQLite Library 3.3.6

[httpwebwitch]

sadly, switching to the procedural version (rather than the OOP version) doesn't help.

PHP Fatal error: Call to undefined function sqlite_open()

[coopster]

Are you running it as a shared extension?

On Linux or Unix operating systems, if you build PDO as a shared extension, you must build SQLite as a shared extension using the --with-sqlite=shared configure option.

[php.net...]

[httpwebwitch]

I've learned that CentOS, for no intelligible reason, horked SQLITE out of their standard distro.

I've pretty much committed to CentOS on this new server, but my app depends on SQLite for superfast optimized data stuff. So this means I have to download and phpize and make PHP from scratch? I'm happier when I can just "yum" it in.

[Little_G]

Hi,

Have you tried using PDO [php.net]? Your phpinfo says PDO has support for sqlite.

The dsn for sqlite is

sqlite:/path/to/db

.

Andrew

[httpwebwitch]

I haven't tried PDO...

I'm migrating my site from a server that supports sqlite_open() to this new CentOS server that doesn't; I'd prefer to change the server rather than rewrite the code, because in the short term the site needs to work on both servers.

[httpwebwitch]

Since my new server has PDO support "out of the box", I've attempted to rejig the code to use PDO instead of the built-in sqlite_*() or OOP functions. I don't like that I had to branch the code to do this, but hey we do what we must do, right.

Now, the error I get is:

file is encrypted or is not a database

I'm accessing the same database that I copied from the live server. Permissions are the same.

I think this means that the PDO expects a database in Sqlite3 format, but since I've been using the PHP functions, my database is Sqlite2.

This makes me unhappy. An important step in migrating the site to the new server is copying these Sqlite databases over, hopefully with minimal downtime.

[coopster]

maybe this will help:
[sqlite.org...]

conversion example at bottom of page. Here is the CLI syntax docs:
[sqlite.org...]

[JAB Creations]

PHP is now well in to version 5.3.x; you may have reasons to be running an older version though I would highly recommend using 5.3.x if you can.

- John

[httpwebwitch]

@JAB, I agree.
I discovered the process for converting the databases from sqlite2 to sqlite3, and thankfully it's a fairly simple one-liner in Linux CLI.

On CentOS 5, the "yum install php" command loads PHP5.1.6. Why would that be? I'm beginning to tire of these CentOS deficiencies. I've been fussing with this server for over 2 months now (not full time... just in my spare hours here and there)

Last night I discovered another thing that's unsupported in 5.1.6 - "mysql_set_charset()". So now I'm looking into a PHP upgrade to 5.3.x, not using yum, but using ./configure and make etc

[coopster]

Can you throw down that one-liner for future readers? Or at least an exemplified version?

On CentOS 5, the "yum install php" command loads PHP5.1.6. Why would that be?

yum [fedoraproject.org] is a software package manager that installs, updates, and removes packages on RPM-based systems. It automatically computes dependencies and figures out what things should occur to install packages. yum makes it easier to maintain groups of machines without having to manually update each one using rpm.
See also: rpm [fedoraproject.org]

[httpwebwitch]

np.

the conversion takes one line, but the prep requires a little extra work because you need the sqlite2 and sqlite3 binaries handy

== install sqlite3 ==

cd /usr/src/
wget [sqlite.org...]
gunzip sqlite3-3.6.1.bin.gz
chmod 777 sqlite3-3.6.1.bin

== install sqlite2 ==

wget [sqlite.org...]
gunzip sqlite-2.8.17.bin.gz
chmod 777 sqlite-2.8.17.bin

then for each db you're converting, do this:

/usr/src/sqlite-2.8.17.bin myfile.db .dump | /usr/src/sqlite3-3.6.1.bin myfile.db3


You'll end up with converted databases with a "db3" extension. then you can rename those and overwrite the originals if you want to

[coopster]

Thanks for the update! The bottom of the man page at sqlite that I linked earlier said it was just that easy, but having a "real world" example will make it that much easier for future readers.