Re: more on execute_array not complying with the specification

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