On Mon, May 03, 2004 at 10:25:50AM +0200, Michael Peppler wrote:
> On Sat, 2004-05-01 at 19:53, Tim Bunce wrote:
> > Here's an updated version of what I'm thinking of with respect
> > to $sth->more_results (many thanks for the valuable feedback).
>
> > finish: $sth->finish will discard all pending result sets.
> > ($sth->more_results automatically discards any unfetched
> > rows from the current sub-statement.)
>
> Hmmm - so you could write
>
> do {
> $row = $sth->fetch;
> } while($sth->more_results);
>
> That is definitely different behavior from what DBD::Sybase does at the moment.
(Though DBD::Sybase doesn't have a more_results() method at the moment :-)
> I think that needs to be spelled out more clearly.
Er, you've not spelled out what you think that loop would do.
I think it would fetch the first row from each sub-statement.
> > row errors: row fetch errors (where a row has an error, like a
> > truncation, but more rows can still be fetched) could be distinguished
> > previously by the fetch*() method returning false but Active still
> > being true. That will still be true.
> >
> > err: Obviously some errors will be detected and reported by the
> > original prepare() and execute() but others will not be detected
> > till later. As far as possible more_results() is the place to
> > report any errors that would have been detected and reported by a
> > corresponding prepare() and execute() of the individual sub-statement.
> > (Even if the driver has to call it's own databases' more_results()
> > function at the end of the previous result set, any error should
> > be stored internally and not reported till the $sth->more_results()
> > method is called.)
> >
> > BatchOnlySelect: How to behave if $sth->{BatchOnlySelect}
> > is true and a non-select statement generates an error?
> > We could:
> > a) ignore the error.
> > b) report the error as if BatchOnlySelect wasn't set.
> > c) report the error unless $sth->{BatchOnlySelect} >= 2 (my preference)
>
> I disagree - I would prefer to have the error reported in all cases.
It's an attribute so people can change it to suit their needs.
By "my preference" I only meant that the concept of a non-boolean
BatchOnlySelect attribute was my preference, but I forgot to
discuss what the default should be: either 0 or 1 (but not 2).
> > BatchOnlySelect must work even if a non-select is the first
> > sub-statement, i.e., the initial execute() must also ignore an
> > initial non-select.
> >
> > So BatchOnlySelect must only apply to batches (hence prepare() or
> > execute() must be aware that they're working with a batch, either
> > and explicit one or a stored procedure).
>
> DBD::Sybase has no way of knowing before-hand that a particular SQL
> batch is single or multi-statement. In my opinion there shouldn't have
> to be any difference in behavior.
I fought with this issue for a while but now I think I may have a
better approach that addresses my original concerns.
I'll try to post a "Mark 3" version today which addresses this an
the other issues raised.
Thanks.
Tim.
