[DB-SIG] ANN: mxODBC Version 0.3

Jim Fulton jim@digicool.com
Sun, 30 Nov 1997 13:23:59 -0500

Bill Tutt wrote:
> Lets see if I can list the differences between your ODBC code,
> and the Win32
> version..
> Win32 version has exceptions, where you have essentially ODBC errors..
> Exceptions: The dbi code includes exceptions your ODBC module
> is supposed to
> throw..
>   Specfically: noError, opError, progError, integrityError,
>   dataError, and internalError
> Where they apply to the following cases:


This should be part of the DBI spec. It currently isn't.

> Autocommit: You default to off, when ODBC defaults to on.

These semantics are not documented in the DBI spec, but should be.
All database interfaces should provide the same semantics wrt

IMO, autocommit should default to off.

> Connection String:
> You have ('host:DBNAME', 'uid', 'pwd')
> Win32 has: 'DSN/uid/pwd'


I favor a single connection string, as it increases the similarity
between different DB interfaces.
> Ditching DBI:
> That was a particulary silly thing to do, the exceptions listed
> above exist

But are not documented.

> in DBI, and DBI is a useful abstraction mechanism, and is database
> independant..
> Why does it need to be tossed?

I think people may want to toss it because the existing 
module is not well documented and a bit painful to use.  This
can be fixed, of course.

As has been pointed out, there are several dbi modules around.
I had to modify the version that I distributed with oracledb
to make it non-windows non-C++ specific.  

More importantly, the current versions of the dbi module
are dynamic-linking unfriendly, especially on non-windows
platforms.  The dbi module should be modified to use the
CObject machinery to export it's C interface to other modules.
And of course, as you point out, date-time support is pretty 

> Dates:
> Well there isn't any difference between what you do, and what
> the DBI/Win32 ODBC code does.
> (Well except for handling TIME types but thats just a function of
   ignoring the date part, or indeed just one line in odbc.cpp)
> They're both limited to dates after Jan 1, 1970 00:00:00 GMT.
> What we should do is come up with a sane date type for Python
> that isn't
> based on time_t.

Absolutely. I made some noise about this about a year and a half ago.
The discussion was going in a direction that I could not contribute to
at the time. Since then, I've come around to a position that
is closer to many of the positions advocated at the time.  I think
there is a more-or-less-standard Date/Time model for many databases.

The Spec I'm familiar with is the ODMG-93 spec that includes Date, 
Time, and TimeStamp.  I suspect that these are based on some
wider standards, and there are similar looking structs in the 
ODBC interface (sql.h).  

I hope to make a proposal based on the ODMG spec in the not too
distant future.  Unfortunately, I cannot make any promises. :-(


Jim Fulton           mailto:jim@digicool.com
Technical Director   (540) 371-6909              Python Powered!
Digital Creattions   http://www.digicool.com     http://www.python.org

DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org