[DB-SIG] Cursor.executemany() and Cursor.nextset()

Dittmar, Daniel daniel.dittmar@sap.com
Mon, 6 Aug 2001 14:20:00 +0200

> I can even imagine the justification for providing 
> executemany() in the
> case of data manipulation queries (INSERT, UPDATE, DELETE), 
> though it's
> not entirely clear to me that such batching isn't more appropriately
> handled by client code.

Some drivers can implement this more efficient than a simple loop could.

> So, if I were implementing the API, what should my code do if
> executemany() is invoked with multiple parameter sets on a stored
> procedure which returns multiple result sets?  The choices I 

There was a discussion about this topic a few weeks/months ago, with the
result being something like this:
- the semantics of executemany () with regard to SELECT/CALL are very
database specific. Writers of drivers are reluctant to hide specific
features of the underlying database.
- one possible solution was to allow multiple result sets, but not to
require them. Thus databases which allow batch SELECTs could create a single
result set, other databases would create one for each parameter set.
Portable client code would have to check for multiple result sets.

> It seems to me that the API is either overly ambitious or 
> insufficiently
> specified (or both) in this area.

It is insufficiently specified, but for a reason. This should probably be
stated more clearly in the specification.

> I strongly recommend that the use of executemany for commands 
> producing
> result sets be deprecated, and eventually forbidden (assuming 
> the method
> is retained at all).

Depending on the database, there may be no possibility to check whether a
statement returns a result set short of executing it.


Daniel Dittmar
SAP DB, SAP Labs Berlin