[I've looked back through several months' worth of the list archives to
see if this is a topic which has already been visited, but I wasn't able
to find a search interface, and I wasn't really up to doing the
month-at-a-time thing through several years' worth of messages. Is
there such an interface?]
The DB API 2.0 spec has this to say about nextset():
This method will make the cursor skip to the next available set,
discarding any remaining rows from the current set.
If there are no more sets, the method returns None. Otherwise, it
returns a true value and subsequent calls to the fetch methods will
return rows from the next result set.
However, it seems that reality is more subtle than this description. In
the case of a multi-query stored procedure, for example, some of the
queries may return rows and some might not. If the spec forces the
implementers to try and detect which is which, and skip over the queries
which do not return rows, then even if it's possible to make the
distinction reliably for all possible back ends, the programmer will be
deprived of access to the rowcount information which would otherwise be
available for the queries which modify data but do not return any rows.
How about substitute language something like the following:
This method will make the cursor skip to the next available set,
discarding any remaining rows from the current set.
If there are no more sets, the method returns None. Otherwise, it
returns a true value. It is the responsibility of the programmer to
know whether the current result set represents a (possibly empty)
set of rows available for retrieval with subsequent calls to the
fetch methods. In some cases the query generating the result (for
example, an INSERT statement in a stored procedure) will not provide
such a set of rows, but may instead set the rowcount attribute to
reflect the number of rows affected by the query. In such a case an
exception will be raised if an attempt is made to fetch rows from
the non-existent set of rows.
The wording could probably be improved, and it's unfortunate that use of
the words "set" and "sets" here covers such vague territory, but that's
how things work in at least some of the underlying layers (ODBC, ADODB,
SQL Server, etc.): they're apparently using "results set" to cover both
a set of results which consists of a sequence of rows, as well as the
results of a query for which you get information about the effects of
the query instead of a retrievable set of rows.
Has this been discussed before?
--
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
