[DB-SIG] API Enhancements
Wed, 3 Mar 1999 01:09:55 -0800
> From: M.-A. Lemburg [mailto:email@example.com]
> Greg Stein wrote:
> > Oh... a question about the nextresult() method. Why is that exposed?
> > Shouldn't the module just automatically move to the next result set
> > inside the fetch* methods? I don't see the benefit of
> exposing that to
> > the user. It seems an artifact of the underlying database interface,
> > rather than a useful user-level concept.
> As Tod already pointed out, the nextset() method does have its
> use for stored procedures: result sets are needed to group data.
> If the interface would just silently move to the next set, there
> would be no way to identify the set boundary.
There's nothing preventing the spec from specifying something along the
If there are multiple result sets:
At the end of the first result set, fetch*() returns None.
The next call to fetch*() will return the first row of the next
resultset. (if any).
The user definately needs to see a demarkation between the result sets as
the different result sets typically have different row layouts.
The prototypical example for doing things like this is returning 1:1
information in the first result set, with the second result set containing
N:N information sorted on the reference mode (PK or AK)of the first result