using the PHP command sqlite_open() is producing the error Fatal error: Call to undefined function sqlite_open() in H:\Program Files\Abyss Web Server\htdocs\install.php on line 46
Before anyone jumps in and says that the install path should be C:\ note that when windows was installing it chose H:\ as the install path. So far I have had no problems with using PHP on this install, this error is a first.
07-28-2013, 04:36 PM
You don't have the PHP sql-lite extension installed? look at <?php phpinfo(); ?> and it will say nothing about sql-lite if i'm correct. This is odd, because iirc this is compiled in by default so something must have turned it off assuming you're using 5.3+
Edit: I'll be honest. Using windows doesn't help the situation much. I'm not even sure if you did compile it, or if you downloaded it already compiled... Perhaps you can find a better PHP binary instead of whichever one came with XAMP. If I were you (and I did use Microsoft once upon a time) I would get Virtual Box and make the real freaking web-server, and not a junky hack. Something like nginix or apache httpd. Then use ssh+ftp to work on your site and NAT/PAT to tunnel your visitors to your site. While you're at it you may as well put the SVN/GIT repository on that server. Pick an OS that's easy to use, like ubuntu-server. This assumes you have the memory and processor to handle VM instructions.
I'm not trying to pick on Abyss httpd, but having a fly-by-night web server doesn't do anything except delay development. Pick the server which has gone through the most strenuous testing: apache.
Alternatively if you were already using linux, you could symbolically link against the PHP binary that the administrator has already installed using your httpd.conf (apache) and i'd bet he has the sqlite extension working by default.
If you want to continue using windows. I guess you should check out pecl.php.net and look for the sql-lite extension. Pay some attention to which version of sqlite you have installed on your machine and which version the extension supports (because the extension is making PHP recognize sqlite... the extension needs to work with both the PHP version and the sqlite version you have).
07-29-2013, 06:40 PM
Well I do have the SQLite support, the problem is a simpler problem...
SQLite2 has been dropped altogether which is not very helpful to the millions of people already using it and they have no backwards comparability with the new SQLite3
So anyone running a SQLite2 database needs to create and update all their scripting to SQLite3.
07-30-2013, 02:55 AM
Some frameworks make you write your sql queries using their php library, and allegedly it makes switching the database version/flavor a really simple thing. I haven't used it myself, but iirc it is from ZFW. Something like:
new Query(?)->select("foo, bar, bar").from("tableName").where("1");
I don't do this, because it gets in the way.
grow a pair, upgrade to sqlite3 and "ack -rni sqlite * ", and read each query to make sure it makes sense, finally, enjoy the new features which will also be backwards incompatible in future version: you will like it Sam ;)
You could also just install the sqlite2 extension from pecl or pear? Perhaps it's not supported anymore or "non-standard" (oh my gosh), but if its you're jam then do it.
07-30-2013, 03:57 PM
Its not a question of growing any, its simply that SQLite 2 is not compatible with SQLite 3 nor supported by SQLite3 libraries and has no conversion option built in which is myopic as development goes.
From looking at the problem, versions of PHP 5.4 upwards do not have SQLite2 bundled so anyone who is on a web host and the web host upgrades to PHP 5.4 will find any SQLite 2 databases useless and no way of converting them.
As for using SQLite 3, it is a very convoluted way of doing the job and the developers have broken that age old golden rule of "if it aint broke, don't fix it" and I can only add to that statement that if you have to break it, give people a lifeboat to jump on.
07-30-2013, 05:36 PM
Well I thank the noodly appendage that I've never used SQLite2 or 3.
Out of curiosity though, why can't you just use serialize() and unserialize() yourself. SQLite is a SINGLE USER database isn't it?
If it is a single user database, you could simply write the data ($variable) to some persistent storage, "hard drive", and recall it in an identical data structure you started with at the start of your sqlite2 DML dance? It would save you a bunch of trouble and remedy your SQL errors.
note: use file write locks when you write it.
note again: if using linux, consider leveraging the tree structure of the file system (files/directories) and symbolic links to mimic the FKs in a relational database.