On 03/02/2011 10:01, Tim Bunce wrote:
On Wed, Feb 02, 2011 at 03:52:00PM +0000, Martin J. Evans wrote:
[...]
So, I think DBI works fine right now (given slight pod change) and
don't want to complicate it or worse, break peoples existing code.
Great! :)
DBD:: Oracle on the other hand does not but I believe John has already
demonstrated it can be made to work.
Apologies for length but I could not work out how the simple
clarification I was seeking so we could fix DBD::Oracle ended up in
changing DBI. I might be at fault for that - sorry.
No, it's good.
Thanks for taking the time to work though the issues in depth.
Tim.
I've inserted my execute_array/execute_for_fetch test code (previously
posted) to DBD::ODBC tests. I amended it as per you comment to run the
execute_for_fetch tests regardless of whether the driver supports
multiple active statements but if they fail it simply outputs
diagnostics and does not fail the tests (suggesting you rerun with
TEST_VERBOSE or prove and send the results to dbi-users if the error is
anything other than connection busy). I also changed it to expect 3
fields in ArrayTupleStatus on error as per the clarified spec.
DBD::Oracle does not pass them as it stands but it is very close -
thanks John for that.
The Easysoft SQL Server driver fails one test but someone is looking
into the problem. It also passes the execute_for_fetch test when
MARS_Connection=yes.
The MS SQL Server driver passes except it shows the connection busy
problem when running without MARS_Connection=yes.
I cannot test MS Access and other ODBC drivers right now but I will and
don't expect anything unusual since this is mostly testing DBI's
execute_array/execute_for_fetch and not DBD::ODBC.
Martin
