On 23/01/2008, Konjkov Vladimir <[EMAIL PROTECTED]> 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. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
