Hi Martin.
I have been following it closely but I have no cycles this week to work on
it.
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.
This was not a bug it was designed like this for some reason.
I did not do the orginal design just got it working from code generated
about two years ago.
I think there was a limit with the older versions of OCI on what the Oracle
OCI would return and an disagreement on how to handle this exact subject.
I implemented the code we had as I needed it for a project I was working on
and other wanted it as well.
It is great you are taking an interest in it.
I will have time next week to look at it we can work together on it then if
you want.
cheers John Scoles
----- Original Message -----
From: "Martin J. Evans" <[EMAIL PROTECTED]>
To: <dbi-dev@perl.org>
Sent: Wednesday, September 06, 2006 1:02 PM
Subject: execute_array enhancement to DBI and request for help for someone
who knows DBD::Oracle or XS
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
