On Wed, Dec 30, 2009 at 3:10 AM, Robin Becker <ro...@reportlab.com> wrote:
> On 29/12/2009 14:34, Vernon Cole wrote:
>
>> Robin:
>> A quick reminder -- odbc (in pywin32) is db api version 1.0 compliant.
>> adodbapi is db api version 2.0 compliant, and uses odbc DSN connections
>> by
>> default if you use a simple connection string.
>> Select your db module by deciding what level of api compliance you need.
>>
>> If you use adodbapi, the module will return datetime.datetime by default.
>> You can request time.datetime (let the programmer beware) or mxdatetime if
>> you wish.
>>
>>
> I didn't even know about adodbapi, but it's on my machine anyway. The layer
> above the database is pretty simple and we are attempting to use
> mxodbc/odbc/mysql/csv so the api at level 1.0 is probably sufficient (at
> least it has been up to now). I think the problem is to decide whether odbc
> will return datetime.datetime or PyTime. If the worst comes to the worst I
> can just turn off the warning during the import.
>
> Robin:
adodbapi has been included with the last few releases of pywin32, so you
have your chioce:
adodbapi - api v 2.0 - pure Python - Microsoft ADO - open source
odbc - api v 1.0 - implemented in C - Microsoft ODBC - open source
mxodbc - api v 2.0 - implemented in C - Microsoft ODBC - proprietary
license
Both adodbapi and mxodbc are tested against MySQL.
According to eGenix documentation, mxodbc returns date and time values
in mxDateTime format. In past years, before python's datetime module was
invented, the only tool in the shed was the old unix style PyTime format.
It dreadfully needed replacement, and I do not recommend it for production
work. It gets lost when time zones and/or daylight saving time gets involved
sometimes giving an error of a whole day.
eGenix invented mxDateTime to overcome the limitations of PyTime, and it
does a fine job. The original db api version 2.0 spec requests that
mxDataTime format be used if possible. (This is not strange given that the
author of the specification, Marc-André Lemburg, works for eGenix, and also
it was clearly the best choice at the time.) The current edition of the 2.0
spec says:
> Date/time objects can be implemented as Python datetime module
> objects (available since Python 2.3, with a C API since 2.4) or
> using the mxDateTime package (available for all Python versions
> since 1.5.2). They both provide all necessary constructors and
>
> methods at Python and C level.
>
> Which causes a surprise in the current version of adodbapi in that if you
install mxtools on a workstation, your next database access will suddenly
return mxDateTime values. The version I am now working on will change its
default to datetime.datetime whether or not mxtools is installed. (Note to
self: write a pending depreciation warning.) Current versions of mxtools
will correctly compare mxDateTime objects with datetime.datetime objects.
If you are licensed to use mxodbc, you should import the eGenix module (not
the odbc module from pywin32) like:
>>> import mx.ODBC.Windows
>>> db = mx.ODBC.Windows.DriverConnect('DSN=database;UID=user;PWD=passwd'
The equivalent in adodbapi is probably:
>>> import adodbapi
>>> db = adodbapi.connect'(DSN=database, UID=user, PWD=passwd')
# if you want mxDateTime
>>>adodbapi.adodbapi.dateconverter = adodbapi.adodbapi.mxDateTimeConverter()
# to force datetime.datetime
>>>adodbapi.adodbapi.dateconverter =
adodbapi.adodbapi.pythonDateTimeConverter()
Also, I note you spicified csv as one of your storage types. You may find
that the csv.py module works better than the ODBC csv driver if the csv
format is at all unusual.
Yes, you can ignore the warning, but remember that the reason it is there is
to encourage you to switch to a more modern api.
--
Vernon
>
> I cannot give an authoritative answer for odbc (sorry).
>> --
>> Vernon
>>
>> On Tue, Dec 29, 2009 at 6:44 AM, Robin Becker<ro...@reportlab.com>
>> wrote:
>>
>> I'm trying to use the odbc extension in a cross-python version. The
>>> problem
>>> is that recent pythons/win32 versions have changed the odbc dbi
>>> interface.
>>>
>>> Is there a way to check whether I should be importing dbi to find the
>>> type
>>> of date to be used or just assuming datetime is used?
>>>
>>> In the modern context just importing dbi causes a warning so I would
>>> prefer
>>> to avoid testing the result of dbi.dbiDate(..) etc etc
>>> --
>>> Robin Becker
>>> _______________________________________________
>>> python-win32 mailing list
>>> python-win32@python.org
>>> http://mail.python.org/mailman/listinfo/python-win32
>>>
>>>
>>
>
> --
> Robin Becker
>
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
