On 01/02/2011 10:48 AM, Tim Bunce wrote:
On Mon, Jan 31, 2011 at 08:39:40PM +0000, Martin J. Evans wrote:
I imagine most DBDs [if not all] that implement execute_array
[Just a reminder that drivers can opt to implement just
execute_for_fetch() and use the DBI's default execute_array() method,
which then calls execute_for_fetch().]
themselves) the rows affected will be -1 per execute (as the driver
does not know affected rows) and so I'd expect $rows to be -1 and
not 18. DBI gets away with this as it does an execute for each row
The thing is OCI will know the end result of rows effected I just does
not know the #rows for each statement.
So on an update with say 4 tuples and 6 rows updates the tupels would
look like this
-1
-1
-1
-1
wile the list context one would get
Tuples=4
rows =6
My only concern is when it does error (no matter what the setting of
AutoCommit) you always get unef;
but I can live with that.
Cheers
John
and hence knows the rows affected as the return from each execute.
The statement saying sum of affected rows should not sum a load of
-1s affected to be -N.
Yes. The spec ought to say that if any tuple gets a -1 then -1 gets
returned as the 'sum', even if other tuples return other values.
Tim.
