Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

execute_array returns nonzero and no error tuples when INSERT failed #80

Open
PetrN1974 opened this issue Mar 19, 2019 · 4 comments
Open

Comments

@PetrN1974
Copy link

I am using execute_array on an array of 10000 elements. Even if that INSERT fails because of a lack of space in Oracle, execute_array and array tuples all indicate success; only the statement handle $sth->err() method shows the error. That violates the documented use of execute_array (checking the returned status and checking the tuples).

Set up for the code below: Create a table EXPERIMENTAL in a tablespace constrained to 10MB. The table has a single column, COL VARCHAR(2000).

use strict;
use DBD::Oracle;

my $dbh = DBI->connect("dbi:Oracle:", 'connect code', '', {RaiseError => 1,PrintError => 0,AutoCommit => 0,RowCacheSize => 1000}
) or die "Database connection could not be established: $DBI::errstr";

my $sth = $dbh->prepare( "insert into experimental values (?)" );
$sth->{RaiseError} = 0;

my $bigValue = ("x") x 1500;
my @BigArray = ($bigValue) x 10000;

my $ret = $sth->execute_array( {ArrayTupleStatus=>\my @tuple_status},@BigArray );
print "Inserted big array, got '$ret'\n";
if ( not $ ret ) {
foreach my $status (@tuple_status) {
$status = [0, "Skipped"] unless defined $status;
next unless ref $status;
print( "Failed to insert a row: $status->[1]\n" );
}
die "Failed on DB handling, going down";
}

use Data::Dumper; print Dumper @tuple_status;
print "Statement has ",$sth->err()," and ",$sth->errstr(),"\n";

I expect that this code will show a $ret of zero (false, undef, whatever). I expect that at least one of @tuple_status'es if a reference to an error message.

What I actually get is $ret=10000 and @tuple_status being all -1's; according to DBI docs and samples, I interpret it as "all successful", and that is not the case. Only the last print gives me
"Statement has 1653 and ORA-01653: unable to extend table ***.EXPERIMENTAL by 128 in tablespace EXPERIMENTAL (DBD ERROR: OCIStmtExecute)"

DBD::Oracle version is 1.74. Oracle version is 12 (both server and client).

@djzort
Copy link
Collaborator

djzort commented Mar 26, 2019

1.74 is out of date, please see if you can replicate with 1.76

@PetrN1974
Copy link
Author

PetrN1974 commented Mar 29, 2019 via email

@mjegh
Copy link
Member

mjegh commented Mar 29, 2019

My recollection is that Oracle does not provide a per row status and the -1 states the status is unknown. I'd have to check the code to confirm but I'm fairly sure that is the case. I don't believe there is a "violation" of the DBI docs here so please point me at the section you quote.

@PetrN1974
Copy link
Author

PetrN1974 commented Mar 29, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants