From: Barton <barton@BCDesignsWell.com> - 2009-02-19 05:48:00
|
Let me first say that I am having great fun and success with comtypes! A recent project required a connection to an MS Jet database, so I downloaded adodbapi. Those guy have their reasons (I suppose) for choosing pywin32 - and providing IronPython (yuck) support. Here's what I've been up to: Just for fun I replaced adodbapi's pythoncom dispatch with CreateObject("ADODB.Connection") - custom. Things went along just fine until I tried to fetch many columns from the db: The custom interface returned the expected length list fo rows, but the rows (tuples) were of lenght = 1 containing the corect data for the first column. After some time poking around in comtypes and reading the mail list, I tried CreateObject("ADODB.Connection", dynamic=True) . Success!! All rows are fetched properly! I then decided to re-organize and rename the module - maybe someday breath new life into one of the earlier, sleeping projects - adodbapi turns out to be very cumbersome to type and I trying to find a way to work "comtypes" into the name - but I digress... Once I could see the mechanics of the module, I began to look at the inner workings: It seems that comtyps is doing all the type conversion of individual fields of the query result (something that the original module worked very hard at) before the data (list of tuples) arrives. So, I'm trying to understand if a "custom" interface should have behaved differently, if this "dynamic" behavior can be explained in a few word, if there are any pitfalls that I may be headed for, and if pythoncom lacks this kind type conversion. I appreciate any thoughts on this. Thank you, Barton |