On Tue, Aug 30, 2011 at 04:44:29PM -0700, John Fabiani wrote: > On Tuesday, August 30, 2011 03:07:13 pm Roger Gammans wrote: > > good enough for what I needed so I haven't mantained it. But it would > > probably help you in the right direction. > > > > The important patches are :- > > http://hg.backslashat.org/repos/dabo-odbc/rev/af94151ed49a > > http://hg.backslashat.org/repos/dabo-odbc/graph/aeb4a75ba49f > > > > and > > http://hg.backslashat.org/repos/dabo-odbc/rev/eb192fd4cd54 > > > > But you could just the db/dbOdbc.py from the last one and hack from > > there. > > > Roger, > > thanks for the code - I'm sure I'll use it in the near future (I've actually > haven't started yet). > > After reading some of the code I do have a few questions! > Why did you find it necessary to create the "Cursor" class? It appears the > pyodbc has pyodbc.Cursor class. Did you find it did not match the Dabo > requirements - I ran into this with the old pymssql and was unable to get it > to work - Ed finished the job.
Yeah, I'm pretty sure that was the case, I can remember the details but if you look at changeset eb192fd4cd54 you can see it was originally trying to use the pyodbc cursor class and then I changed it. > You did not use "INFORMATION_SCHEMA" to access table, field information. I > was planned on using the INFORMATION_SCHEMA as a universal way of accessing > the system info. Of course I'm under the impression that all the major > database engines have it available. INFOMATION_SCHEMA is part of SQL 2003, my patch uses pyodbc tables/colums functions which IIRC use ODBC 1.0's SQLTables and SQLColumns API calls which easily predate 2003. I'm not sure if support was common in DB engines before that but I don't recall seeing it in that timeframe. Given that SQLTables/SQLColoums are part of the base ODBC spec I figure they are more reliable on a ODBC source. Of course I haven't tried every combination. > Last the code implies that you were ONLY connecting to MSSQL - is that > correct? Did you try connecting to other database engines? Um. No. It implies I had a specific connection in mind. It wasn't MSSQL it was something rather common here in the UK and seriously proprietary[1]. I may have tested on some other connections but I doubt MSSQL was one of them - I don't have a dummy MSSQL server setup . My experience with ODBC drivers is that they are all slightly different and often propagate the idiosyncrasies of the database engine straight through the ODBC layer. So for example quoting rules need to match the target engine , and you may find variations on Type mappings - although I suspect that will be less of a problem here. [1] A well knwon ERP Vendor's only data access API. -- Roger. Home| http://www.sandman.uklinux.net/ Master of Peng Shui. (Ancient oriental art of Penguin Arranging) Work|Independent Sys Consultant | http://www.computer-surgery.co.uk/ New key Fpr: 0F2F E1DF 4CD2 5E7B EF9F B173 4CFA F143 ADBE 6B00 --- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature --- _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[email protected]
