mxODBC (was "split problem if the delimiter is inside the text limiter")
python.list at tim.thechases.com
Thu Mar 19 13:40:09 CET 2009
> 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
SELECT a, b, c
WHERE providerid = ?
AND a IN (
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 :)
More information about the Python-list