Re: Clarification sought on execute_array

On 20/01/11 09:55, Tim Bunce wrote:

> I wonder if we could run an older DBD::Oracle against an Oracle 9 (say)
> database to recreate the (presumably) original behaviour.

I kept my Oracle 11.1.0.6.0 database and tried various combinations of DBD::Oracle (back to 1.19) and instant clients - non work as documented.

I then tried instant client 10.2.0.5.0 to an oracle database 10.2.0.5.0 (with DBD::Oracle 1.19) and it works:

DB Version: 10.2.0.1.0
********** do_it **********
AutoCommit = 1
execute_array = undef
total affected rows = undef
Error from execute_array - errstr=ORA-24381: error(s) in array DML (DBD SUCCESS_WITH_INFO: OCIStmtExecute), err=0, state=''
$tuple_status = [
                  -1,
                  [
                    1,
                    'ORA-00001: unique constraint (SYSTEM.SYS_C005544) violated (DBD SUCCESS_WITH_INFO)'
                  ],
                  -1,
                  -1
                ];

Error captured in handler: undef
Warning captured in SIGWARN handler: undef
$select * from mytest = [
                          [
                            '1',
                            'onetwothree         '
                          ],
                          [
                            '51',
                            'fiftyone            '
                          ],
                          [
                            '52',
                            'fiftythree          '
                          ],
                          [
                            '53',
                            'one                 '
                          ]
                        ];

Notice, the successful rows are committed and the unsuccessful row is not.

After trying various other combinations it seems any version of instant client or DBD::Oracle works so long as Oracle database is less than 11. I cannot say as yet if it is a bug in Oracle or some change DBD::Oracle didn't follow.

So it would appear DBD::Oracle/Oracle has always issued a warning and not an error when a tuple fails. I think this is really dangerous if someone is relying on RaiseError so I've changed the DBD::Oracle we use internally to raise an error.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com