Repository navigation
Look into supported driver managers for ODBC extension and how we handle them #15630
Description
Currently, we have a different set of supported driver managers on Unix platforms between the two ODBC extensions. On Windows, they just use the system driver manager.
PDO_ODBC supports:
- unixODBC
- iODBC
- using a generic ODBC driver directly
- and the Db2 driver using that generic driver infra w/ a special case in build system
- (Zend seems to use this on IBM i to link with libdb400 since it's SQL/CLI and not ODBC, but this seems outmoded; ibm_db2 exists as an extension, and you can also use the Client Access ODBC driver on i nowadays)
Procedural supports (those flags are out of date, birdstep and openlink are gone at least, should file doc-en bug):
- unixODBC
- iODBC
- Db2 directly (this is just an ODBC or SQL/CLI library)
- Empress directly (seems to be some embedded DB?)
- Solid directly (same deal as Empress)
- DBMaker directly (some Chinese RDBMS?)
- Adabas D directly (some German RDBMS?)
- SAP DB directly (does this still exist/rebranded? results for HANA massively overshadow this)
- Easysoft OOB (looks to be a way to use an ODBC driver remotely?) directly
- generic
They also handle driver (manager) variance differently; procedural has a lot more ifdef for using things directly.
A common pattern I noticed is procedural has grown many special case build and ifdef options for using an ODBC driver directly. I'm not sure if this is something we want to encourage, since a driver manager has a lot of benefits (tracing, runtime switching of drivers, etc), though linking directly to a driver might be useful with those embedded databases. We could limit support for linking with a driver directly to only the generic case; this would put PDO and procedural at parity and simplify documentation and build system. I'm also unsure of how many of these are still in popular use to justify special casing them.
tl;dr: For 8.5/9.0, we should consider probably paring down the supported libraries to use ODBC on Unix with down to unixODBC, iODBC, and specifying an ODBC driver manually. I'd like to hear from users of drivers too.
Activity
cmb69 commentedon Sep 3, 2024
I don't really know, but I guess we have a similar issue to #15176 here; apparently, it has just been forgotten to remove some out-dated stuff. Especially that ext/odbc supports way more options that ext/pdo_odbc may hint at what may be no longer needed nowadays.
See https://en.wikipedia.org/wiki/Adabas_D (not to be confused with Adabas, though).
I think this is now https://en.wikipedia.org/wiki/MaxDB, which once was Adabas D, but apparently they're now different products.
NattyNarwhal commentedon Sep 3, 2024
I'm going through the ifdefs in
php_odbc.c, and there's a surprising amount of workarounds for i.e. Solid et al., but also possibly standard functionality (i.e. timestamp type?) under specific drivers. You wouldn't be getting those though, if you were using a generic driver manager.I'll come up with a draft PR for next release at least.
NattyNarwhal commentedon Sep 9, 2025
GH-15727 merged.
phpGH-15630 follow-up: Remove redundant undefs
GH-15630 follow-up: Remove redundant undefs (#19783)