[DB-SIG] ANN: mxODBC Version 0.3

Bill Tutt billtut@microsoft.com
Fri, 28 Nov 1997 15:42:33 -0800

Ugh.. why do we need N different ODBC modules?
I'd really love to know.. 

>From your webpage:
	This interface module was created in need of an Python interface to
the German ADABAS D relational database from Software AG. This database can
be accessed through the Oracle CLI and or ODBC. After having tried both the
OracleDB module from Digital Creations and the SolidDB Module (ODBC) from
g.a.m.s. I decided to code my own version, because both didn't meet my
requirement for high stability for various reasons. 

What are those reasons?
Please, we'd like to know, really.. :)

Also, whats wrong with just porting the ODBC code from Win32?
I'm certainly more than willing to answer specific questions about it.
Unfortunately I don't have the time to test fixes to it, but I'm more than
happy to answer questions about it.

Lets see if I can list the differences between your ODBC code, and the Win32
Win32 version has exceptions, where you have essentially ODBC errors..
Exceptions: The dbi code includes exceptions your ODBC module is supposed to
                   Specfically: noError, opError, progError, integrityError,
dataError, and internalError
Where they apply to the following cases:
	noError is generally ment to be thrown when you have a warning i.e.
Data truncated that you should know about.
	opError is an operational error i.e. being disconnected,  data
source name not found, etc....
	progError is a programming error i.e. table already exists, table
not found, etc...
	integrityError is an integirity error in the database's relational
integerity i.e. a foreign key check fails
	dataError is a data error, i.e. Numeric value out of range, division
by zero, etc...
	internalError is an interntal Database error, i.e. Invalid cursor
state, invalid transaction state, etc...

You have: (sqlstate, sqltype, errortext, lineno) tuples.
You can find the sqlstate->DBI exceptions in odbc.cpp in the Win32 code.

Autocommit: You default to off, when ODBC defaults to on.. 
This is highly conterintuitive, and violates the principle of least
The Win32 code has a similar function: setautocommit(0 | 1) to turn
autocommit on or off.
Whether or not ODBC should default to autocommit or not isn't really the
question.. if it does, so should we.

Connection String:
You have ('host:DBNAME', 'uid', 'pwd')
Win32 has: 'DSN/uid/pwd'
What really should be done here is to adopt an ODBC like connection
string... aka:
'property=value;property=value' Where "uid" is always the userid, and "pwd"
is always the password.

fetchxxx() return values:
The return values are the same as the Win32 ODBC code

Ditching DBI:
That was a particulary silly thing to do, the exceptions listed above exist
in DBI, and DBI is a useful abstraction mechanism, and is database
independant.. Why does it need to be tossed?

Large Binary/Text data:
This is one place where your code does the right thing, and the Win32 ODBC
code falls down.
Currently the Win32 ODBC code has a 64k limit on binary data, which can be
easily fixed.

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.

Looping over lists of tuples for non-resultset producing queries:
Your code does do this, and modifying Win32 ODBC to do this is trivial as
well. (I have the necessary details btw...)

ODBC Catalog functions:
Well your code is ahead of the Win32 code here obviously since the Win32
code doens't have anything like this.
Submission of code for this kind of thing is greatly appreciated.

Wanting only to have one ODBC module,
Bill Tutt
Not speaking for Microsoft, etc...

DB-SIG  - SIG on Tabular Databases in Python

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