On Tue, Nov 02, 2004 at 02:56:10PM -0500, Jason White wrote: > > > >FYI DBD::Oracle 1.06 is over 4 years old. > > Yes, was aware of that to my own frustration. Was able to work with > sysadmin to get upt to 1.14 at least ... an advance of 2.5 years at > least.
So does DBD::Oracle 1.14 pass its test suite? Does the same problem still happen? [Could you build 1.16 locally, but not install it, for testing?] > >Please generate a trace file (level 4 should be detailed enough). > > Here's the level 4 trace output, I focused the query (as you'll see > below) to limit the output to one record. When I run the same query > manually, it comes back with a 2. It appears blank here or if piped to > a file will show up as "Seats - ^V" > > -> prepare for DBD::Oracle::db (DBI::db=HASH(0x187100)~0x104948 > 'select STS_ISS from umeg.UMEG_INSTR_TO_EVAL where trm='200408' and > crs='HISP619' and sec='0101' and LAST_NAME LIKE 'Niev%'') > dbd_describe SELECT (EXPLICIT, lb 80)... > fbh 1: 'STS_ISS' NULLable, otype 2-> 5, dbsize 22/134, p3.s0 That shows Oracle telling DBD::Oracle the field is a NUMBER (type 2) and DBD::Oracle asking Oracle to return it as a STRING (type 5). Try selecting TO_CHAR(STS_ISS) to force the number to string conversion to happen on the server instead of the client. > 1 -> fetch for DBD::Oracle::st (DBI::st=HASH(0xf0a50)~INNER) > dbd_st_fetch 1 fields... > dbih_setup_fbav for 1 fields => 0x104bdc > dbd_st_fetch 1 fields SUCCESS > 1 <- fetch= [ '.' ] row1 at sisQuery.pl line 27 Something is clearly very wrong, but I find it hard to believe that DBD::Oracle code is the cause - given so many people using it without problems. I've never seen a problem like this reported. Tim.
