Re: DBI error expected but didn't get any

2001-06-01 Thread Tim Bunce

On Fri, Jun 01, 2001 at 12:18:55PM +0200, [EMAIL PROTECTED] wrote:
> Tim,
> 
> Is my assumption correct that either:
> 
> OCIStmtPrepare  or OCIStmtExecute 
> 
> should return an error of some sort ?? 

I'd expect OCIStmtExecute to return OCI_ERROR or OCI_SUCCESS_WITH_INFO.

But since the update says it updated 0 rows perhaps the problem lies
there.  I.e., the where clause didn't match (for whatever obscure
reason, maybe charset issues) so Oracle never got to the point of
discovering it would need to truncate the field.

> I did rebuild DBD on the same machine against Oracle 8.1.7. yesterday. 
> 
> We have pretty much all versions of Oracle over here, so I tried it on
> Oracle 7.3.4. (hpux10.20, same perl).. got the same result.
> Would that mean that there's a never-found bug in OCI ?? (kinda hard to
> believe it has persisted for so long)

Indeed.

> Output is below, note that that server is a production/HA-server so I can't
> install DBI 1.16 without testing it extensivly.

That's would be relevant.

Tim.



RE: DBI error expected but didn't get any

2001-06-01 Thread f . n . postma
 @1 g0 a0) at
unknown location!
<> DESTROY ignored for outer handle DBI::db=HASH(0x40248170) (inner
DBI::db=HASH(0x40035e24))
>> DESTROY DISPATCH (DBI::db=HASH(0x40035e24) rc1/1 @1 g0 a0) at
unknown location!
-> DESTROY for DBD::Oracle::db (DBI::db=HASH(0x40035e24)~INNER)
<- DESTROY= undef at unknown location!
dbih_clearcom (h 0x40248170, com 0x40036c08):
   FLAGS 0x191: COMSET Warn RaiseError PrintError 
   TYPE 2
   PARENT DBI::dr=HASH(0x40035d1c)
   KIDS 0 (0 active)
   IMP_DATA undef in 'DBD::Oracle::db'
dbih_clearcom 0x40248170 (com 0x40036c08, type 2) done.

-> DBI::END
>> disconnect_all DISPATCH (DBI::dr=HASH(0x40175714) rc1/3 @1 g0
a401b2fe8) at /var/tools/lib/perl5/PA-RISC1.1/DBI.pm line 424.
-> disconnect_all for DBD::Oracle::dr
(DBI::dr=HASH(0x40175714)~0x40035d1c)
<- disconnect_all= '' at /var/tools/lib/perl5/PA-RISC1.1/DBI.pm line
424.
<- DBI::END complete
>> DESTROY DISPATCH (DBI::dr=HASH(0x40035d1c) rc1/1 @1 g0 a0) during
global destruction.
-> DESTROY in DBD::_::common for DBD::Oracle::dr
(DBI::dr=HASH(0x40035d1c)~INNER)
<- DESTROY= undef during global destruction.
dbih_clearcom (h 0x40175714, com 0x4003c088):
   FLAGS 0x215: COMSET Active Warn AutoCommit 
   TYPE 1
   PARENT undef
   KIDS 0 (0 active)
   IMP_DATA undef in 'DBD::Oracle::dr'
dbih_clearcom 0x40175714 (com 0x4003c088, type 1) done.

>> DESTROY DISPATCH (DBI::dr=HASH(0x40175714) rc1/1 @1 g0 a0) during
global destruction.
<> DESTROY for DBI::dr=HASH(0x40175714) ignored (inner handle gone)


---
Frans Postma, (050-58) 81 852
KPN Datacenter, SDU Unix Support 

> -Oorspronkelijk bericht-
> Van: Tim Bunce [mailto:[EMAIL PROTECTED]]
> Verzonden: vrijdag 1 juni 2001 11:24
> Aan: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> Onderwerp: Re: DBI error expected but didn't get any
> 
> 
> First try rebuilding DBD::Oracle if it wasn't built for the version of
> Oracle you're talking to.
> 
> If that doesn't help then talk to Oracle about it. Don't mention the
> DBI, just talk about your 'Oracle OCI application' :)
> 
> On the upside, it seems that it does say 0 rows updated :)
> 
> Tim.
> 
> On Fri, Jun 01, 2001 at 10:52:59AM +0200, [EMAIL PROTECTED] wrote:
> > Hi,
> > 
> > I'm using DBI 1.16 with DBD:Oracle 1.06 , the following 
> line does NOT give
> > me an error, while the same code DOES give an error (as it 
> should) when run
> > through sqlplus:
> > 
> > update DC_PATROL_STATUS_TABLE set
> > SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
> > MESSAGE='Reset from GUI by user:
> > user',TIMESTAMP=991379859000
> > where SYSTEM_NAME='hdxh20' and MODULE='KPN_Log' and
> > INSTANCE='-tmp-logfile1_txt'
> > and (PARAMETER = 'Msg' or PARAMETER = 'OldMsg');
> > 
> > The point is that the value for SEVERITY is too large for 
> the column, which
> > oracle sqlplus reports as:
> > 
> > update DC_PATROL_STATUS_TABLE set
> > SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
> >*
> > ERROR at line 1:
> > ORA-01401: inserted value too large for column
> > 
> > My question is: why does the $dbh->do() I issue the same 
> command with using
> > DBI/DBD not return an error??
> > (RaiseError = 1, PrintError = 1)
> > 
> > Oracle version is 8.1.7.
> > OS = HPUX 11.00
> > 
> > ** Trace with level 7 and perl -V output appended:
> > 
> >DBI 1.16-nothread dispatch trace level set to 7
> > Note: perl is running without the recommended perl -w option
> > -> do in DBD::_::db for DBD::Oracle::db
> > (DBI::db=HASH(0x402406c0)~0x4023a7ec 'update 
> DC_PATROL_STATUS_TABLE set
> > SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
> > MESSAGE='Reset from GUI by user:
> > patrolAgent',TIMESTAMP=99138546
> > where SYSTEM_NAME='hdxh20' and MODULE='KPN_Log' and
> > INSTANCE='KPN_Log' and (PARAMETER = 'Msg' or PARAMETER = 'OldMsg')')
> > 2   -> prepare for DBD::Oracle::db 
> (DBI::db=HASH(0x4023a7ec)~INNER 'update
> > DC_PATROL_STATUS_TABLE set
> > SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
> > MESSAGE='Reset from GUI by user:
> &g

Re: DBI error expected but didn't get any

2001-06-01 Thread Tim Bunce

First try rebuilding DBD::Oracle if it wasn't built for the version of
Oracle you're talking to.

If that doesn't help then talk to Oracle about it. Don't mention the
DBI, just talk about your 'Oracle OCI application' :)

On the upside, it seems that it does say 0 rows updated :)

Tim.

On Fri, Jun 01, 2001 at 10:52:59AM +0200, [EMAIL PROTECTED] wrote:
> Hi,
> 
> I'm using DBI 1.16 with DBD:Oracle 1.06 , the following line does NOT give
> me an error, while the same code DOES give an error (as it should) when run
> through sqlplus:
> 
> update DC_PATROL_STATUS_TABLE set
> SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
>   MESSAGE='Reset from GUI by user:
> user',TIMESTAMP=991379859000
>   where SYSTEM_NAME='hdxh20' and MODULE='KPN_Log' and
> INSTANCE='-tmp-logfile1_txt'
>   and (PARAMETER = 'Msg' or PARAMETER = 'OldMsg');
> 
> The point is that the value for SEVERITY is too large for the column, which
> oracle sqlplus reports as:
> 
> update DC_PATROL_STATUS_TABLE set
> SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
>*
> ERROR at line 1:
> ORA-01401: inserted value too large for column
> 
> My question is: why does the $dbh->do() I issue the same command with using
> DBI/DBD not return an error??
> (RaiseError = 1, PrintError = 1)
> 
> Oracle version is 8.1.7.
> OS = HPUX 11.00
> 
> ** Trace with level 7 and perl -V output appended:
> 
>DBI 1.16-nothread dispatch trace level set to 7
> Note: perl is running without the recommended perl -w option
> -> do in DBD::_::db for DBD::Oracle::db
> (DBI::db=HASH(0x402406c0)~0x4023a7ec 'update DC_PATROL_STATUS_TABLE set
> SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
> MESSAGE='Reset from GUI by user:
> patrolAgent',TIMESTAMP=99138546
> where SYSTEM_NAME='hdxh20' and MODULE='KPN_Log' and
> INSTANCE='KPN_Log' and (PARAMETER = 'Msg' or PARAMETER = 'OldMsg')')
> 2   -> prepare for DBD::Oracle::db (DBI::db=HASH(0x4023a7ec)~INNER 'update
> DC_PATROL_STATUS_TABLE set
> SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
> MESSAGE='Reset from GUI by user:
> patrolAgent',TIMESTAMP=99138546
> where SYSTEM_NAME='hdxh20' and MODULE='KPN_Log' and
> INSTANCE='KPN_Log' and (PARAMETER = 'Msg' or PARAMETER = 'OldMsg')' undef)
> New DBI::st (for DBD::Oracle::st, parent=DBI::db=HASH(0x4023a7ec), id=)
> dbih_setup_handle(DBI::st=HASH(0x4024072c)=>DBI::st=HASH(0x401f791c),
> DBD::Oracle::st, 40240774, Null!)
> dbih_make_com(DBI::db=HASH(0x4023a7ec), DBD::Oracle::st, 204)
> dbih_setup_attrib(DBI::st=HASH(0x401f791c), Err,
> DBI::db=HASH(0x4023a7ec)) SCALAR(0x40242da0) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x401f791c), State,
> DBI::db=HASH(0x4023a7ec)) SCALAR(0x4018def0) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x401f791c), Errstr,
> DBI::db=HASH(0x4023a7ec)) SCALAR(0x40242dc4) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x401f791c), Handlers,
> DBI::db=HASH(0x4023a7ec)) ARRAY(0x4026e2fc) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x401f791c), Debug,
> DBI::db=HASH(0x4023a7ec)) 0 (already defined)
> OCIHandleAlloc(4002d6b8,40227084,4,0,)=SUCCESS
> OCIStmtPrepare(4028d920,4003eb30,'update DC_PATROL_STATUS_TABLE set
> SEVERITY='OK',date_inserted=sysdate,escalation_id='*NONE*',
> MESSAGE='Reset from GUI by user:
> patrolAgent',TIMESTAMP=99138546
> where SYSTEM_NAME='hdxh20' and MODULE='KPN_Log' and
> INSTANCE='KPN_Log' and (PARAMETER = 'Msg' or PARAMETER =
> 'OldMsg')',286,1,0)=SUCCESS
> OCIAttrGet(4028d920,4,40227088,,24,4003eb30)=SUCCESS
> dbd_st_prepare'd sql UPDATE
> dbd_describe skipped for UPDATE
> 2   <- prepare= DBI::st=HASH(0x4024072c) at
> /var/tools/lib/perl5/PA-RISC1.1/DBI.pm line 930.
> -> execute for DBD::Oracle::st (DBI::st=HASH(0x4024072c)~0x401f791c)
> dbd_st_execute UPDATE (out0, lob0)...
> OCIStmtExecute(4003e900,4028d920,4003eb30,1,0,,,0)=SUCCESS
> OCIAttrGet(4028d920,4,7f7e2430,,9,4003eb30)=SUCCESS
> OCIAttrGet(4028d920,4,7f7e2454,,10,4003eb30)=SUCCESS
> dbd_st_execute UPDATE returned (SUCCESS, rpc0, fn5, out0)
> <- execute= '0E0' at /var/tools/lib/perl5/PA-RISC1.1/DBI.pm line 931.
> -> rows for DBD::Oracle::st (DBI::st=HASH(0x4024072c)~0x401f791c)
> OCIAttrGet(4028d920,4,7f7e23b8,,9,4003eb30)=SUCCESS
> <- rows= 0 at /var/tools/lib/perl5/PA-RISC1.1/DBI.pm line 932.
> <- do= '0E0' at ./set_status line 31.
> <> DESTROY ignored for outer handle DBI::st=HASH(0x4024072c) (inner
> DBI::st=HASH(0x401f791c))
> -> DESTROY for DBD::Oracle::st (DBI::st=HASH(0x401f791c)~INNER)
> OCIHandleFree(4028d920,4)=SUCCESS
> <- DESTROY= undef at ./set_status line 39.
> dbih_clearcom (h 0x4024072c, com 0x40227008):
>FLAGS 0x191: COMSET Warn RaiseError