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
--
http://mail.python.org/mailman/listinfo/python-list
