Re: more on execute_array not complying with the specification

  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.