On Wed, 2004-07-14 at 00:24, Tim Bunce wrote: > On Tue, Jul 13, 2004 at 09:19:12PM +0200, Michael Peppler wrote: > > On Tue, 2004-07-13 at 20:42, Tim Bunce wrote: > > > On Tue, Jul 13, 2004 at 05:04:17PM +0200, Michael Peppler wrote: > > > > > > But for the "real" version the finish() call is optional, and is just > > > > there to be complete and to behave in a way that would be (to me) > > > > consistent with other situations. > > > > > > Does finish() for INSERT statements do anything in DBD::Sybase? > > > > No, other than making sure that the statement handle is cleared properly > > (i.e. explicitly rather than implicitly with the DESTROY call) > > But does > $sth->finish; > $sth->execute(...); > work? i.e. finish shouldn't "clear" the sth so much that it can't be > executed again.
For an INSERT, yes, you can call execute() after a finish(). > > But as Sybase BLK operations require an explicit cleanup I felt that > > this would be a reasonable match (kind of like explicitly calling > > $dbh->disconnect). > > And you can't use commit() for that because you want to be able to > commit mid-way through the load? Correct. If you're loading a very large set of rows you'd run out of log space if don't commit fairly often, and you'd fail the entire operation if a single row failed (dup key error, for example.) > > It might not map perfectly with the DBI spec though. > > Seems reasonable I guess. (Might be less so when finish() gets renamed > (aliased) to discard_pending_rows() :-) But in DBI v2 they'll probably > be a $sth->reset or something similar that'll do the job. OK - personally I *like* "finish()" - it makes sense to my way of thinking. 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
