[egenix-users] Re: mxODBC Cursor Unicode issuewith method executedirect().

Harri Pesonen harri.pesonen at wicom.com
Fri Aug 17 15:34:29 CEST 2007


We first used .execute() but then changed to .executedirect() when we
noticed that .execute() does two calls to SQL Server, SQLPrepare and
SQLExecute. .executedirect() does only 1 call, SQLExecDirect. So
.execute() may be two times slower if the SQL statement is always
different.

-- Harri

-----Original Message-----
From: Charlie Clark [mailto:charlie at egenix.com] 
Sent: 17. elokuuta 2007 14:25
To: Harri Pesonen
Cc: egenix-users at lists.egenix.com
Subject: Re: [egenix-users] Re: mxODBC Cursor Unicode issuewith method
executedirect().

Am 17.08.2007, 12:35 Uhr, schrieb Harri Pesonen
<harri.pesonen at wicom.com>:

> Good to know, I was not aware of .execute() doing automatic caching of
> the prepared statement. So it may be faster than .executedirect(),
> depending on how the application is written. We have a multi-threaded
> application and it is not clear, in which order the executes are made,
> it may change from day to day, so it is hard to tell which one is
> better. Obviously we could have different cursors for the different
> cases, but it would be harder to implement. Hmm we already have a
> different database connection (and cursor) for some cases... So it
could
> benefit of using execute instead of executedirect...

In general you should use .execute() and .executedirect() only if you
have  
a use case where it is demonstrably better, which will usually be if the

database's ODBC driver is sloppy (and there are lots of them). As this  
recent issue has illustrated: .executedirect() is harder to use and  
support if there are problems and is provided to be used only when  
necessary. I think this is the more Pythonic approach.

.executemany() is extremely elegant when passed an iterator (useful when

copying from one database to another) but packing things in a Python
list  
is hardly clumsy. My experience with PostgreSQL is that .executemany()
is  
faster for batch inserts but the limiting factor for high volume is  
usually the management overhead with the database checking constraints.

Charlie

-- 
Charlie Clark
eGenix.com

Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::

     eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611



More information about the egenix-users mailing list