[DB-SIG] PEP 249

[James Henstridge]

On 23/01/2008, Konjkov Vladimir <konjkov.vv at gmail.com> wrote:
> When I'm implementin on C my Python module that are used to access
>  ODBC 2.0 database, I can't found description in PEP-0249 about the
>  case when one .executeXXX follows another on the same cursor object.
>
>  I think that after .executeXXX cursor can only be
>  fetchedXXX or closed. Reexecution permited and raised exception.
>  That's because .executeXXX method calling SQLPrepare and
>  and next SQLPrepare posible only when SQLCloseCursor() or
>  SQLFreeStmt() with the SQL_CLOSE option called.

The idea is that on .execute(), the database adapter could prepare the
statement and execute it.  The cursor would keep the prepared
statement around afterwards.

On a subsequent .execute() call, if the statement is identical it can
use the previously prepared statement.  If not, then it discards the
prepared statement and creates a new one.


>  But on C-level reexecution is posible.
>
>  "Once the application has processed the results from the SQLExecute() call,
>  it can execute the statement again with new (or the same) parameter
> values."
>
>  Problem is that no .Prepare(Statement) method is not present in Cursor
> oblect.

Use of prepared statements is implicit, if the database adapter uses
them at all.


>  I think it will be better if connection method of cursor have to do the
>  SQLPrepare and only prepare the statemnet when creatin new python cursor
> object
>  C = cnxn.cursor(STATEMENT),
>  and C.execute([parameters]) will only execute or reexecute the statemnet
>  with optional parameters list.

What benefits do you see from this design over the existing one?

James.