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. I think that needs to be spelled out more clearly.
> 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.
> 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.
> If BatchOnlySelect is set and the batch only contains non-select
> statements then the initial execute() would return false and not "0E0".
Why should it return false? Because although we are "ignoring" the
non-select results, the operation on the server was still successful,
no?
I can see the logic, but it seems counter-intuitive to me (actually I
feel that the BatchOnlySelect attribute isn't really necessary - if I
execute a batch I *want* to process all the results and check all the
possible error conditions - I don't want the driver to hide anything
from me...)
Michael
--
Michael Peppler Data Migrations, Inc.
[EMAIL PROTECTED] http://www.peppler.org/
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short
or long term contract positions - http://www.peppler.org/resume.html
