mxODBC (was "split problem if the delimiter is inside the text limiter")

[Tim Chase]

> DB-API 2.0 has cursor.executemany() to make this differentiation
> at the API level. mxODBC will lift this requirement in the next
> version, promised :-)

glad to hear...will executemany() take an arbitrary iterable?  My 
  (albeit somewhat-antiquated) version balked at anything that 
wasn't a list/tuple (don't remember off the top of my head which 
it was).  For a lot of my ETL work, it would be nice to pass a 
generator so I don't have to keep huge datasets in memory.

>> (and don't get me started on mxODBC's failure to
>> determine the data-type for parameters in subqueries, raising exceptions
>> on perfectly valid queries</rant>)
> 
> I'm not sure what you are referring to here. mxODBC can only provide
> an interface to the underlying ODBC driver.

Okay...feel free to deflect the minced oaths at MS's SQL Server 
ODBC driver then. :)  The main problem came with queries like

   cursor.execute("""
     SELECT a, b, c
     FROM table_x
     WHERE providerid = ?
       AND a IN (
        SELECT z
        FROM table_y
        WHERE accountid = ?
        )""", (providerid, accountid)
     )

The "accountid = ?" in the sub-query triggers some inability in 
some layer to determine what datatype it should be converted to, 
so it raises a FrustrateTim exception :)

-tkc