See below ...
On Nov 2, 2004, at 3:23 PM, Tim Bunce wrote:
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?
Initially it skipped most tests as the host, username etc. were/are empty. The initial test passed and then it skipped a number of tests ... and failed (I assumed) due to the lack of that information so went ahead and did the make install.
After a few more rounds with the make test, I'm convinced that my environment vars aren't correct for the test ... TWO_TASK should be set to the remote host correct?
Does the same problem still happen?
Yep. (see more below)
[Could you build 1.16 locally, but not install it, for testing?]
Cannot get 1.15 or 1.16 (fails on dbdimp.o) to make. We have a separate install of perl and the script needs to use that instance of perl, so we have to build with that install. Furthermore it's on a distributed computing system, so we can only muck with our partition of the box with our root instance ... which usually works fine, just requires that we be specific.
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
I changed the query back to select * instead of select STS_ISS ... and it shows that it is changing the type wholesale, not just on the number field. Apparently it doesn't matter on the other ones in terms of the data since they are type VARCHAR2
...
fbh 7: 'FIRST_NAME' NO null , otype 1-> 5, dbsize 40/41, p40.s0
fbh 8: 'STS_ISS' NULLable, otype 2-> 5, dbsize 22/134, p3.s0
fbh 9: 'XLIST' NULLable, otype 1-> 5, dbsize 8/9, p8.s0
So ... what might cause this or how might types be strictly defined?
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.
Unfortunately this didn't work.
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 believe you and asked this question fully suspecting it to be something on my part. Always encouraging to hear the
I've never seen a problem like this reported.
;)
BTW ... congrats on your developer of the year award!
Jason
