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