We've been using PDO for 2 years in new scripts to connect to our MySQL, PostgreSQL and SQLite databases.
We're now starting a project in which we'll need to read (and maybe a few simple UPDATE's) a Firebird 2.5 database file. I'd like to use PDO since we already use that and it will be less of a transition. However the PDO_FIREBIRD PECL package seems to be last updated in 2006.
So my question is: is it better to use the PDO Firebird driver or the php_interbase API for a new project? I.e. is the PDO Firebird driver production worthy?
The PDO Firebird is stable if you use it from main repository of PHP
You should use the the extension that comes with Php not the PECL one
Here is the PDO health status from last Year http://www.firebirdnews.org/?p=6619
Many bugs are fixed from then so you can just try it and abuse it.
The version from PECL is not updated for many years but i will take care of it soon https://bugs.php.net/bug.php?id=58824
Of course the php_ibase api is much older and well tested in production systems for years (from the old times of php3 ~ 1998)
Related
I'm dealing with a legacy firebird database and can't seem to get it to work with PHP7.4.
The interbase extension isn't available anymore in PHP7.4, I can only install PDO_FIREBIRD.
There are also no releases on PECL.
https://pecl.php.net/package/interbase
Any hints how to make it work with 7.4?
Recent versions of PHP indeed no longer ship with the interbase package. Instead you can use the Firebird PHP driver, which is a fork and continued development of the interbase package.
Well, I faced some caveats while dealing with legacy Firebird data structures.
To put it simply, I had to address two broad issues:
1 - Match client libraries with dataset On-disk Structure (ODS)
Each Firebird version supports a limited range of On-Disk Structures (ODSs). The following link has a pretty nice reference on this topic:
https://ib-aid.com/en/articles/all-firebird-and-interbase-on-disk-structure-ods-versions
ADODB and PHP PDO are abstraction layers to client libraries in the host system. And PHP 7.4 supports only FB 3.0 and later clients. So, it is necessary to match the abstraction layer with the client library available.
For datasets up to FB 2.5:
disk structure should be up to ODS 11;
client version should be up to FB 2.5.9 (recommended);
PHP engine should be up to 7.3 (7.1 already has issues);
legacy functions ibase_ and fbird_ should work fine;
ADODB, PHP PDO, etc. should not work.
For datasets starting from FB 3.0:
disk structure should be ODS 12 or higher;
client version should be FB 3.0 or higher;
PHP engine should be 7.4 or higher;
legacy functions ibase_ and fbird_ should not work;
ADODB, PDO etc. should work fine.
2 - Match client and server platforms and params
For any client and server combination:
the client and the server should share the same platform, 32 or 64 bits;
the connection should use SQL dialect 1 or 3, depending on legacy dataset usage;
the character encoding should be WIN-1251 (legacy) or UTF-8 (new default).
Opinion
In my experience, it is difficult to "force" legacy FB connections into an up-to-date PHP engine. I suppose it is more challenging with Linux systems because libgcc has different entry points from versions 5 to 6 (I guess...), and musl just ain't supported.
Things are more flexible in Windows since fbclient.dll is the only client library needed for the connection, and it depends on Win32 libraries that have maintained the same entry points over the years.
I'd recommend upgrading the dataset to Firebird 4 and using updated extensions and clients. However, if this is not an option, downgrading should be streamlined from the host OS, through the PHP engine, until the FB client.
Unfortunately, I believe "this is the way."
All the best.
Recently I have problems connecting firebird with php. I went through many questions until I discovered that there has to be 3 dll's inside the apache bin folder. gds32.dll
msvcr71.dll
fbclient.dll.
Without these dll's it doesn't work, for some unknown reason the new version of xampp came missing.
We have developed a web-application that runs on various server environments (> PHP 5.3), which currently uses the "deprecated" mysql extension to connect to mysql. Since PHP 7 however, it seems mysql is not installed by default, only the newer mysqli extension.
So we would like to convert our scripts to use mysqli, but we are concerned if the mysqli extension is not installed on "older" servers. So the question basically goes: Is mysqli generally ubiquitous since PHP version 5.3? Does anyone know from what version of PHP mysqli comes installed as default?
If some of our users are on hosts without mysqli, we would need to create a wrapper script, that detects if mysqli is available, and fall back to mysql if not.
Anyone with knowledge care to shine some light on this? Thanks
MySQLi was added with PHP 5.0
You can check if mysqli is installed by doing this:
if ( function_exists('mysqli_connect') )
// mysqli is installed
We have a CakePHP 1.3 application that we're in the process of upgrading to 2.2.3. One of the requirements of our app is to be able to query into an MSSQL database of a separate application to do some authentication and to pull user data out.
After two wasted days of researching and harassing our webhost to install the PHP / PDO / MSSQL lib (we already have PDO for MySQL, sqlite and sqlite 2) it's staring to seem pretty grim.
TL;DR: We need to find a way to do PDO MSSQL queries under Linux.
Begin Rant:
The thing that's driving me crazy is this: The CakePHP devs BROKE MSSQL compatibility for the sake of making all their DB wrappers with PDO. If you had a 1.3 app on a Linux server that was happily connecting to MSSQL databases and want to upgrade it to 2.2, you will no longer be able to connect to that database because apparently using PDO is more important than ensuring that you don't destroy existing functionality for your users.
CakePHP 2.x Docs do NOT warn users of this pitfall, all they say is that you need PDO.
There should be a notice that PDO/MSSQL does not work under Linux, or there should be an alterantive to the Sqlserver.php datasource that's provided with stock CakePHP so that people upgrading their apps have a chance of getting their applications functional again under 2.2x
I am really steamed about this right now because I wasted a week of time porting things over from 1.3 to 2.2 and now it looks like I either have to manually write the queries and ignore CakePHP's great database abstraction, or I need to convert all my work BACK to 1.3 and give up all the new improvements in the latest version of CakePHP.
The trick is :
sudo apt-get install php5-sybase
For some reason extension is not called mssql
sybase worked fine for me
What you need to do is install the ODBC drivers from Microsoft and set up the odbc connection strings. The process can be a bit tricky but it does work, and the driver is stable.
You can then use $dbh = new PDO("odbc:CONNECTIONNAME", $user, $password); to connect through PDO.
Once that is sorted, I think you can still use the MSSQL data source but modifying the connection string.
My company uses the sqlserv extension to connect to a MSSQL database. This extension was chosen over the mssql extension because it is actively being maintained by Microsoft and the mssql driver is no longer maintained at all. My colleague has always worked in a windows enviroment so he could just download the proper DLL file and voila, sqlserv is available. Since i am running on Mac OSX 10.8.1 i don't share this luxery.
So basically the question is: does anyone know of a sqlserv php extension in the form of a .so file?
You cannot run the SQLSRV extension on anything other than Windows as stated here:
http://php.net/manual/en/sqlsrv.installation.php
However, even if you could, I would strongly urge you to stay away from the SQLSRV extension as it is extremely buggy and underdeveloped. You would be much better off using PDO!
I spent days trying to work out which extension to use, and after much research and questions on stackoverflow, it was clear that PDO was the only realistic solution for connecting to an MSSQL database. Not to mention the additional functionality that you have!
Try and execute stored procedures, return multiple recordsets along with output parameters using the SQLSERV extension!! Just one of the many features that can be done in a few lines with PDO but cannot be done with SQLSERV.
Furthermore, PDO is faster!
I'm running MicroApache (http://microapache.amadis.sytes.net) on Windows XP and would like to use SQLite 3 databases.
The PHP version is 5.2.9-2.
My MicroApache version has SQLite 2 support through 2 lines in the php.ini:
extension=php_pdo.dll
extension=php_sqlite.dll
I test whether the extension works in 3 ways:
1. phpinfo()
2. extension_loaded() and get_loaded_extensions()
3. using sample code that var_dump()s the constant SQLITE3_NUM (should be the integer 2)
and tries to create a database (error: class 'SQLite3' does not exist)
Things I have tried (if I can remember them all):
1. copied php_sqlite3.dll from a full installation of PHP and added "extension=php_sqlite3.dll" to php.ini
-> error "Procedure entry point gc_remove_zval_from_buffer was not found in php5ts.dll"
2. compressed the DLL with UPX (like the other DLLs of MicroApache seem to be)
-> does not display an error on start, nor in the log file, but does not work
3. tried various things with php.ini
- created a section "[sqlite3]"
- prefixed "sqlite3." to "extension_dir=." and "extension=php_sqlite3.dll"
- ...
4. tried to use PDO, it says it 'could not find driver'
Who can help me get SQLite 3 to work?
The problem of connecting to SQLite 3 DBs and similar problems are covered and discussed on a forum post entitled, "Connecting to SQLite3 database from PHP 5.25" This may answer some of your queries.
The latest build of SQLite is compiled-in to PHP5 and is enabled via PDO.
It shows in PHPINFO.PHP as
2.0-dev "$Id: sqlite.c,v 1.166.2.13.2.12 2008/12/31 11:17:44 sebastian Exp $"
Sounds more like a problem with the test code. Have you cross-checked by running on an SQLite system with standard Apache and the same version of PHP? What are the result from phpinfo(), etc?
The recent MicroApache distros come with a PHP/SQLite guestbook as a demo/test. Does this not work?
Come to think of it you may not have spotted that there's an SQLite distro. Why not revisit the site and check the other versions out (just unzip and run).
MicroApache 2.0.63+PHP 4.4.9+SQLite:
As always I point out that MicroApache isn't intended to be used on a public-facing webserver without paying specific attention to the security config. It was developed merely as a way of sharing information locally via floppy or USB stick. It's easy enough to harden though.
I'm sure you are aware that the SQLite developer renamed a number of the functions with the advent of SQLite3 including the open function - (See here: An Introduction To The SQLite C/C++ Interface ) - I'm not sure how this has been handled by the PHP developers including this codebase into PHP. The suggestion from the page linked above is that you can open PHp3 DBs "as is" with the right PHP code.
Mixing DLLs from different distros of PHP isn't recommended. I don't recommend any other use of the MicroApache distro other than "as is". Adding or mixing DLLs from differing versions of PHP etc. to MicroApache may introduce serious bugs or security problems.
There has been little or no interest in SQLite with MicroApache to date so I've really not dug too deeply into it other than to check the functionality works.
I don't rely too heavily on what's reported by phpinfo().
Perhaps you can update with your info to confirm if the version being reported is accurate.
Update
I've had time to research a little more and a discussion on php5-sqlite3 at the Mac OS Forge mailing list answers your problem.
The PHP implementation is partial and not well documented. Some SQLite3 procedural function calls are only exposed by an object based hierarchy. The procedural API only offers the ability to open SQLite 2 DBs so you're stuck with using objects by the looks of it.
There is also a PECL extension, php-sqlite3, which was
developed during 2008, currently at
version 0.6. This is what the
php5-sqlite3 port installs. But it
does not provide the sqlite3_open
function you are seeking. Rather, it
gives you an object-oriented interface
based around three classes: SQLite3,
SQLite3Stmt and SQLite3Result. It is
described here, rather incompletely,
notably the installation
instructions are totally missing:
MicroApache 2.0.63+PHP 5.2.9+SQLite
MicroApache 1.3.41+PHP 4.4.9+SQLite
MicroApache 1.3.41+PHP 4.4.9+SQLite
MicroApache 1.3.41+PHP 4.4.9+SQLite+GD2
Hopefully you can play with these distros and solve your problems.
There is an SQLite3.DLL included with the distro as a courtesy which can be accessed directly from VB5/6 or any compatible language which can call the DLL.
Using SQLITE 3 from Visual BASIC 5
This was a separate project I had a look at some while ago. This was produced in MSVC by editing the original source. This DLL isn't compatible with PHP/PDO but could be used via a CGI interface. Alternately the original SQLite 3 DLL could be obtained and used via Delphi etc.
Please be aware that I do have the distro with SQLite support. However it only has support for version 2, not 3.
My MicroApache version has SQLite 2 support [...]
I would like to use SQLite 3 because it is faster, I could interact with the databases I created for a project in Delphi and I could access the newly created databases with the Firefox extension SQLite Manager.
I've tinkered with this problem some more, but could still not create/access a SQLite 3 database.
Interestingly, the link you provided in Part 1 mentions a class "SQLiteDatabase" which is not found in the PHP documentation and is not part of the SQLite3 extension (which is object oriented - as mentioned in your last post, Mad Max).
"SQLiteDatabase" creates a database, but when you open it, you can see that it is in version 2.1.
Thanks for the help.
EDIT:
PDO works only when I use the DSN prefix "sqlite2" which is not very surprising, since phpinfo() only lists the driver "sqlite2" under the section "PDO".