Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: BLOBs and error ORA-01465

by panix (Monk)
on Jul 26, 2002 at 00:31 UTC ( #185390=note: print w/replies, xml ) Need Help??


in reply to BLOBs and error ORA-01465

Replace the ora_types in bind_param() with ora_type.

DBD::Oracle is probably being a little harsh silently discarding bad arguments (it's an easy enough mistake to make as well, ora_type/ora_types are both valid in other places).

Replies are listed 'Best First'.
Re: Re: BLOBs and error ORA-01465
by djantzen (Priest) on Jul 26, 2002 at 15:23 UTC

    Aargh. Well you're right panix. The irritating bit is that I tried doing this before, and that I've used ora_types to bind to CLOB fields without any problem.

    What I've found then is that the "same" error arises under two circumstances: 1) if I use ora_types instead of ora_type with BLOB fields; and 2) if I use our in-house DBI wrapper module with BLOBs. The persistence of the error when testing under the latter is the reason why I wrote off the ora_type business as a non-factor here. All of which makes for a gut-wrenching lesson in the importance of a rigorous breakdown of possible causal relations over the span of multiple tests and even theories.

    Anyway, thank you for your work panix++

    Update:I believe I've narrowed the problem down to the method DBD::_::do defined in DBI.pm, which our DBI wrapper module relies upon in most cases:

    sub do { my($dbh, $statement, $attr, @params) = @_; my $sth = $dbh->prepare($statement, $attr) or return undef; $sth->execute(@params) or return undef; my $rows = $sth->rows; ($rows == 0) ? "0E0" : $rows; }
    And this is line 3383 DBI.pm
    If any arguments are given, then C<execute> will effectively call L</bind_param> for each value before executing the statement. Values bound in this way are usually treated as C<SQL_VARCHAR> types unless the driver can determine the correct type (which is rare), or unless C<bind_param> (or C<bind_param_inout>) has already been used to specify the type.
    Between the code and this comment, and the fact that I can insert, update, etc., values in CLOB fields using do but must call bind_param explicitly when working with BLOB fields leads me to believe that execute is ignoring the attributes bound in prepare and is successfully able to ascertain on its own the type of the CLOB data but not BLOB data. But now I'm wondering why that method takes attributes at all if they aren't going to be used.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://185390]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (9)
As of 2019-12-09 19:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?