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.
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.
I have a Joomla Website and within it I created a custom Module, that should connect to this Access Database I have. However when trying to connect to it it can't find this database. As far as I found out this is because the connection string I registered as a odbc-datasource is 32bit, but the PHP is a 64bit version and therefor also looks for a 64bit odbc-datasource. So is there a possibility to enforce it to take the 32bit datasource?
different bit size programs can't talk to each other. There is no difference between Access x32 and x64 format files. So there is no such thing as a x32 bit Access database.
What IS differnt howver is the database driver you choose. There is a x32 bit driver, and a x64 bit driver. If your web site is running as x64 bits, then the Access database driver must also be x64 bits.
Windows for about 20 years ships with a Access x32 bit driver. this driver thus does not need to be installed, but it only x32 bits, and it ONLY works with mdb files. If you are using the newer accDB file format, then you need to install a later version of the Access database engine (the old one is called JET, the newer one is called ACE). You need the ACE data engine to read accDB files. You also need ACE if you going to read mdb files and ALSO use x64 bit software. So only a x32 bit version of JET exists (reads mdb files only).
If you want to use x64 bits and read mdb files, or accDB files, then you have to install the 64 bit version.
Since the dawn of computers? you can no more use x32 bit software to talk to say a 8 bit Atari computer. You have to match up the bit size of all code and libraries you are using - including driver software to connect to the database. Mix and match of different bit size software is not allowed, and it been that way since the first computer shipped to a home.
I have created a PHP extension using C++. I want to ship my extension to my clients in its binary form. That means I need to build a separate version of it for each PHP version (5.2, 5.3, 5.4, 5.5) and each processor architecture.
My questions are:
why do they keep updating the API timestamp while the API itself seemingly does not change? Wouldn't it remove a lot of headache while upgrading your system to use the next version of PHP? Just for comparison, I also have a version of my extension for MS Excel using the XLL API and that API has remained backwards compatible since 2003 which allows me to have just two binaries (32 and 64 bit) for all of my clients.
Is there any way around this problem? I.e. is there a way to build a PHP extension that can be run in multiple PHP versions?
Maybe you can try a hybrid approach. Compile your C++ library separately and then create an open source PHP extension wrapper for that. The PHP extension has nearly no logic of its own. It converts data types from PHP to C/C++ back and forth and passes the arguments to functions/methods implemented in your C++ library.
You then just maintain a binary version of your library per platform and the adoption to a particular PHP version is done by the open source PHP extension.
This of course requires that the systems of your customers do have the PHP development packages installed, as well as a compiler.
If I replace a MySQL 5.1 server with a MariaDB Server (Maria & XtraDB storages) instead of MySQL (MyISAM & InnoDB), will most of MySQL client software (incl. applications made with PHP 5.2 and Java SE 1.6) ...
just remain working without any changes (with minor regressions maybe)?
Or will I have to replace/reconfigure client drivers (like use another JDBC driver class and connection string)?
Or will I have even to change application code?
http://kb.askmonty.org/v/mariadb-versus-mysql
All MySQL connectors (PHP, Perl, Python, Java, MyODBC, Ruby, MySQL C connector etc) works unchanged with MariaDB.
I have used Mariadb as replacement for Oracle's MySQL for years. It is faster and very reliable. Needs just little attention in apt, but nothing severe. Also, there is one small detail with Mariadb; it is seeing [error] "PHP Warning: mysql_connect(): Headers and client library minor version mismatch" in the logs. I haven't found any other solution to that other than to start manually compiling: askMonty.
$php -i | grep 'Client API'
Client API version => 5.3.7-MariaDB
Client API library version => 5.3.7-MariaDB
Client API header version => 5.1.61
Client API version => 5.3.7-MariaDB
just remain working without any changes (with minor regressions
maybe)?
You shouldn't have any issues as long as you replace with the same version. If you're currently are using MySQL 5.1, you can replace with MariaDB 5.1. If you are using 5.5, use the corresponding one. MariaDB v5.2 and v5.3 and enhanced versions of 5.1.
Or will I have to replace/reconfigure client drivers (like use another
JDBC driver class and connection string)?
You shouldn't. MySQL and MariaDB both use the same protocol and overall syntax, but there could be a few exceptions in some cases. The URL quoted in another answer is a great resource: http://kb.askmonty.org/v/mariadb-versus-mysql
Regarding the drivers' licenses, there are differences if you plan to distribute your project commercially. In that case I recommend you to double check the license terms and if you have any concerns, use the MariaDB/SkySQL versions of the connectors as suggested in another answer. Check http://www.skysql.com/downloads/java-cc-connectors-mariadb for details.
Or will I have even to change application code?
The application code should be unchanged.
Just a little feedback requarding the compatibility with mysql driver/CodeIgniter. I ran into the problems on BIT attributes types few minutes ago.
Value was not retrived from the server. It was always empty.
I was using standard CI database configuration which is using "mysql" driver.
After changing driver in the database.php to "mysqli" problem was solved.
Just the heads up that there can be some differences if you are using old mysql driver.
$db['default']['dbdriver'] = 'mysqli';
MariaDB client API version 5.5.40
MariaDB is MySQL evolved.
It is also the same developer who is behind MySQL and MariaDB. It is almost the same (if it is not, i can only say MariaDB is MySQL improved, dot).
You don't have to change nothing in your PHP.
Contrary to popular belief, the default Connector/J JDBC driver for connecting to and interacting with MySQL in Java does not play nicely with MariaDB. To work with MariaDB, you need to have your application use the Drizzle or SkySQL driver.
http://kb.askmonty.org/en/mariadb-faq-is-there-any-java-connector-for-mariadb-than-the-one-from-mysql
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".