On 27.03.2014 11:28, M.-A. Lemburg wrote: > I don't think the use case is important enough to make .prepare() > a requirement in the DB-API, but it would be great if we could > come up with a standard extension definition.
Here's a start: """ .prepare(operation) Prepare a database operation (query or command) without executing it, e.g. to check for syntax errors, determine the parameter count or initialize the cursor for subsequent calls to the .execute*() methods. The prepared operation string is retained by the cursor to allow executing the operation without having to prepare the operation again. In order to benefit from this caching, the .execute*() methods must be run with the same operation string that was passed to the .prepare() method. The call to .prepare() closes any pending result sets on the cursor. The prepared operation is only available until the next call to one of the .execute*() methods or another call to the .prepare() method. Return values are not defined. """ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 27 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2014-03-29: PythonCamp 2014, Cologne, Germany ... 2 days to go 2014-04-09: PyCon 2014, Montreal, Canada ... 13 days to go 2014-04-29: Python Meeting Duesseldorf ... 33 days to go 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 http://www.egenix.com/company/contact/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
