Christopher Petrilli wrote:

...

BTW, I didn't mean to imply that what you've done isn't useful, it's simply incompatible with the direction we're taking. This is somewhat discussed in my roadmap. If you'd like to maintain the interface that you're talking about, then that'd be excellent.

In what way is it incompatible ? mxODBC is DB API compliant in most parts and has lots of useful extensions such as the ODBC catalog functions. The interface itself is thread safe and thread friendly. Of course, whether a certain ODBC driver is depends on the driver.

We are abandoning the use of DB-API interfaces for our own use simply because they have proven to be of little value in getting things running. In addition, their behavioral assumptions are sometimes quite incompatible with Zope requirements. Jim Fulton can better speak to this. We're now doing a more "thin shim" approach, and not going anywhere near the DB-API or SWIG.

FYI, mxODBC currently works with these database drivers/managers: Adabas - Informix - MySQL - PostgreSQL - Oracle - Solid - Sybase - Windows ODBC Manager - Unix iODBC Driver Manager - Linux unixODBC Driver Manager - EasySoft ODBC Bridge - OpenLink ODBC drivers - Intersolv ODBC drivers + virtually any database supported by one of the listed ODBC managers.

The issue is more that in many cases (Oracle for example) ODBC is enormously slower than the native drivers. we've had people comment that it's something around an order of magnitude. Also, Oracle's ODBC drivers leak like the proverbial sieve. Therefore we plan to target native interfaces, rather than glued on top constructs. Only on Windows is ODBC any form of gain. Now, if X/Open CLI is the native interface (as with DB2), then this will be fine... we just plan to talk to native interfaces. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com