RE: DBI error expected but didn't get any

2001-06-01 Thread f . n . postma
):
   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:
  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

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.