On Wed, 2006-09-06 at 13:16 -0400, John Scoles wrote: > 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. > >
Sorry, I meant, returns the total rows affected instead of the total number of tuples executed. > This was not a bug it was designed like this for some reason. I say it is a bug on the basis of the DBI spec which says execute_array returns the number of tuples executed so either DBD::Oracle is wrong or DBI is wrong. I was working on the basis DBI was correct because of Tim's clarification. > 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. I've already had the discussion of whether it is more sensible to return the rows affected from execute_array or the tuples executed with Tim and he confirmed there was discussion about it at the time, that the DBI docs were correct but he could not remember why the decision was taken. I don't particularly mind which way it is now that you can get rows affected back directly. > 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. Fine - this would be a great help. In the meantime if I can squeeze the time I'll try and get better acquainted with DBD::Oracle. > cheers John Scoles Thanks for the response - I look forward to sorting this out with you. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com > ----- Original Message ----- > From: "Martin J. Evans" <[EMAIL PROTECTED]> > To: <[email protected]> > 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 > > > > > >
