Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBD-Oracle CPAN distribution.

Report information
The Basics
Id: 38267
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: Nobody in particular
Requestors: steve.baldwin [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.22
Fixed in: 1.23



Subject: Inserts/Updates to BLOB's via synonyms fails
The problem that existed for CLOB's and BLOB's in 1.21 has been partially fixed. The good news is that CLOB's appear to be OK. BLOB's however appear to still be broken. Here is an extract from a level 3 trace ... DBI::db=HASH(0x61b8350) trace level set to 0x0/3 (DBI @ 0x0/47120086204416) in DBI 1.52-ithread (pid 27618) -> prepare for DBD::Oracle::db (DBI::db=HASH(0x61a64d0)~0x61b8350 ' INSERT INTO sb_demo(data_b) VALUES (:blob) ') thr#4e9b010 dbih_setup_handle(DBI::st=HASH(0x632baa0)=>DBI::st=HASH(0x632bb90), DBD::Oracle::st, 632bba0, Null!) dbih_make_com(DBI::db=HASH(0x61b8350), 61c0570, DBD::Oracle::st, 448, 0) thr#4e9b010 dbd_preparse scanned 1 distinct placeholders dbd_st_prepare'd sql INSERT (pl1, auto_lob1, check_sql1) dbd_describe skipped for INSERT <- prepare= DBI::st=HASH(0x632baa0) at tst-utf8.plx line 191 via at tst-utf8.plx line 239 -> bind_param for DBD::Oracle::st (DBI::st=HASH(0x632baa0)~0x632bb90 ':blob' '..........�W....' (type 0 (DEFAULT (varchar)), attribs: HASH(0x6311c40)) bind :blob as ftype 113 (SQLT_BLOB / long) dbd_rebind_ph(): bind :blob <== '........' (in, not-utf8, csid 0->0->0, ftype 113 (SQLT_BLOB / long), csform 0->0, maxlen 8, maxdata_size 0) <- bind_param= 1 at tst-utf8.plx line 197 via at tst-utf8.plx line 239 -> execute for DBD::Oracle::st (DBI::st=HASH(0x632baa0)~0x632bb90) thr#4e9b010 dbd_st_execute INSERT (out0, lob1)... Statement Execute Mode is 0 (DEFAULT) dbd_st_execute INSERT returned (SUCCESS, rpc1, fn3, out0) lob refetching a synonym named=SB_DEMO for FRAMEWORK.SB_DEMO lob refetch from table FRAMEWORK.SB_DEMO, 3 columns: lob refetch table col 1: 'LINE_NUMBER' otype 2 lob refetch table col 2: 'TEXT' otype 1 lob refetch table col 3: 'DATA_B' otype 113 lob refetch :blob param: otype 113, matched field 'DATA_B' by type (DATA_B "blob") lob refetch sql: select DATA_B "blob" from DATA_B "blob" where rowid = :rid for update lob refetch 1 for ':blob' param: ftype 113 setup !! ERROR: '942' 'ORA-00942: table or view does not exist (DBD ERROR: OCIStmtExecute/LOB refetch)' (err#1) <- execute= undef at tst-utf8.plx line 198 via at tst-utf8.plx line 239 -> HandleError on DBI::st=HASH(0x632bb90) via CODE(0x6311080) (undef) It appears it is attempting to use the BLOB column name for the table name in the refetch SQL statement. I've attached a test script that highlights the problem. Thanks for your help. Steve
Subject: blob.plx
Download blob.plx
application/octet-stream 1.1k

Message body not shown because it is not plain text.

From: steve.baldwin [...] gmail.com
I should have added that the synonym problem exists both in the case where the synonym name is different to the underlying table name (as in attached example), and in the case where the synonym is in a different schema and has the same name as the underlying table (as in the trace output). Thanks
Finally got this one fixed you will find the new code in trunk http://svn.perl.org/modules/dbd-oracle/trunk The main reason it took so long was trying to recreate the error seens this will only happen when the DBD user has only limited grant permissions for syn and had noting to do with clobs or blobs. The triger the actual bug in DBD::Oracle the permissions had to be limited CREATE SYNONYM and not CREATE PUBLIC SYNONYM Anyway it is fixed cheers