For anyone in dbi-user list you may have been following my discussion on execute_array in DBI. Usually what I do in my code is:
$affected = $sth->execute(for an insert statement); die "did not insert expected number of rows" if ($affected != $the_expected_number_of_inserts); which works because execute returns the rows affected. execute_array returns the tuples executed and the only way to get the rows affected is to pass an ArrayTupleStatus then cycle through the array adding up the rows affected for each row - this is pretty inconvenient. Tim suggested a change to allow execute_array to understand being called in array context so you could do: ($executed, $affected) = execute_array(); This works great and I have a patch to DBI which will do this which I'll commit this evening (subject to access to svn). However, I'm using DBD::Oracle so this does not solve my problem because: 1. DBD::Oracle has its own execute_for_fetch which does not understand array context. 2. Oracle OCI cannot return the individual rows affected per tuple so when execute_for_fetch was implemented the ArrayTupleStatus was filled with -1's for unknown rows affected. This rendered execute_array with DBD::Oracle useless to me. However, looking at DBD::Oracle and OCI I've discovered OCI can return the total rows affected (which I want) and in fact due to a bug in DBD::Oracle execute_for_fetch currently returns the total rows affected instead of the number of rows affected. What I need assistance with is to change DBD::Oracle's execute_for_fetch to understand array context so it can return the tuples executed and the rows affected (which it already has). At the same time we could fix the bug I reported in DBD::Oracle so in scalar context it returns the tuples executed instead of rows affected. If someone can help or point me in the right direction I'd be most grateful since I'm not that familiar with XS. Thanks. Martin -- Martin J. Evans Easysoft Ltd, UK http://www.easysoft.com
