On Wednesday, August 31, 2011 01:00:22 am Roger Gammans wrote: > 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.
Thanks Roger. I will be starting today - and most likely will use your cursor class. Thanks, Johnf _______________________________________________ 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]
