Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113801
Message-ID: <ecfba56802e3390bf6dabc1ef785a06896ca13a9.camel@cmpct.info>
To: internals@lists.php.net
Date: Fri, 26 Mar 2021 11:51:11 -0300
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.1 (3.38.1-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Improvements to PDO_ODBC
From: calvin@cmpct.info (Calvin Buckley)

Hello internals@,

I've been looking into improving PDO_ODBC; specifically, bringing it up
to parity with other drivers, as well as dealing with its quirks. The
company I work for supports PHP on IBM i, and while we maintain the
native database drivers for the platform, we (and IBM) have been
recommending new applications migrate to ODBC.

However, the procedural ODBC driver does have some limitations like no
in/out parameters (which is a very common thing with stored procedures
here, unfortunately). PDO_ODBC does support this, but we've noticed
some issues:

 * Persistent connections aren't checked, even though the procedural
   ODBC driver does. This has bitten some of our clients, so we have a
   patch for them that does impement this; this is PR GH-6805.
 * Many of the connection attributes don't seem to be implemented; some
   of these seem trivial to implement, others less so.
 * In/out parameters require users to remember to specify size and add
   one for the null terminator. I'm not familar with other ODBC drivers
   to call this a driver/platform quirk, PDO_ODBC limitation, or
   something else, but figuring out a good solution for this would make
   life easier for users.
 * As always, ODBC being a generic abstraction later itself bites us
   (i.e no standard way to get last ID).

I'm curious if anyone has suggestions for what to be done or how to get
these done.

Regards,
Calvin
 *