Re: DBD::Oracle & 10.1 client

On Thu, Oct 20, 2005 at 03:41:01PM -0500, Scott T. Hildreth wrote:
> To add more info, I was told this problem only occurs if there is only
> one row returned. If more than one row is returned, the arrayref is
> fine. I changed the selectall_arrayref to selectrow_array and the data
> (one row returned) was fine. I'm posting to dev as well, just in case
> this is a known bug.

It's not. (And even if it were, dbi-dev isn't meant for reporting bugs.
The dbi-users list is fine for that.)

> I copied the table to a 9i instance and the ran
> the code below, and it worked fine. So it seems to be related to 10g.

And since the DBD::Oracle code was the same, that implies it's not a
DBD::Oracle bug. Does seem very odd though.

A level 5 trace will show you what Oracle is returning for each field of
each row. If that shows the bad data then it's almost certainly an
Oracle bug. If it doesn't (ie it shows different values being returned
than what eventually gets returned by selectall_arrayref) then it's a
DBD::Oracle or DBI bug - but at the moment I doubt that.

Tim.

> Thu, 2005-10-20 at 14:07 -0500, Scott T. Hildreth wrote:
> > I am going to investigate more, but I thought I would post the question
> > to see if anyone has run into this problem.
> >
> > I have co-workers that connecting to a remote Oracle DB (10.1), I
> > compiled DBD::Oracle 1.16 with the 10.1 client libraries. The data
> > returned from a selectall_arrayref is 2 fields a filename and a
> > quantity. Here is the isolated code,
> >
> > 286: my $load_file_ar = $dbh->selectall_arrayref(q{
> > 287 select FILENAME, NUM_RECORDS
> > 288 from LOAD_DATA_SRC_FILE
> > 289 where LOAD_ID = ?
> > 290 and DATA_UPDATE_ID = ?
> > 291 order by FILE_ID
> > 292 }, undef, $load_id, $update_id);
> >
> > $load_id = 19 & $update_id = 51.
> >
> > ...here is the data returned.
> >
> > DB<4> x $files_ar
> > 0 ARRAY(0x8536328)
> > 0 ARRAY(0x85e40e0)
> > 0 (binary data)
> > 1 51
> >
> > what ever $update_id's value is, this is always returned in the [1] position
> > of the the arrayref and the filename is always binary data. This works fine
> > with sqlplus.
> >
> > I have tried it with Perl 5.8.[167] always the same results. The database
> > resides on an Alpha and the clients are on Linux. Trace doesn't show anything
> > unusual. I don't know if this is an NLS-utf8 issue. Any ideas?
> >
> > Thanks,
> > STH
> >
> > Trace- level 9 is attached.
> >
> --
> Scott T. Hildreth

Re: DBD::Oracle & 10.1 client

On Fri, Oct 21, 2005 at 04:07:20PM +0100, Tim Bunce wrote:
> On Thu, Oct 20, 2005 at 03:41:01PM -0500, Scott T. Hildreth wrote:
> > To add more info, I was told this problem only occurs if there is only
> > one row returned. If more than one row is returned, the arrayref is
> > fine. I changed the selectall_arrayref to selectrow_array and the data
> > (one row returned) was fine. I'm posting to dev as well, just in case
> > this is a known bug.
>
> It's not. (And even if it were, dbi-dev isn't meant for reporting bugs.
> The dbi-users list is fine for that.)
>
> > I copied the table to a 9i instance and the ran
> > the code below, and it worked fine. So it seems to be related to 10g.
>
> And since the DBD::Oracle code was the same, that implies it's not a
> DBD::Oracle bug. Does seem very odd though.
>
> A level 5 trace will show you what Oracle is returning for each field of
> each row. If that shows the bad data then it's almost certainly an
> Oracle bug. If it doesn't (ie it shows different values being returned
> than what eventually gets returned by selectall_arrayref) then it's a
> DBD::Oracle or DBI bug - but at the moment I doubt that.

Ah, I didn't spot the attached trace. Sorry.

OCIStmtExecute(831e534,8323594,831e5a8,0,0,0,0,0)=SUCCESS
OCIAttrGet(8323594,OCI_HTYPE_STMT,bfffe906,0,10,831e5a8)=SUC CESS
dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0)
dbd_st_fetch 2 fields...
OCIStmtFetch(8323594,831e5a8,1,2,0)=SUCCESS
dbih_setup_fbav for 2 fields => 0x829bfac
dbd_st_fetch 2 fields SUCCESS
0 (rc=0): '?.'
1 (rc=0): '51'

Sure looks like an Oracle problem.

Tim.

DBI::db and invisibility

hey,

I've been writing a DBD plugin for DBI, and was wondering why the DBI::db object
that I've been creating doesn't show its contents either via Dumper or via 'x' in
the database.

Is this a consequence of how DBI is programmed? Would it be easy to change to remove
this limitation? After all, it would be a lot easier to program/debug my driver
if I could use all of perl's debugging tools..

Ed

Re: DBI::db and invisibility

On Fri, Dec 09, 2005 at 10:13:19PM -0800, Ed Peschko wrote:
> hey,
>
> I've been writing a DBD plugin for DBI, and was wondering why the DBI::db object
> that I've been creating doesn't show its contents either via Dumper or via 'x' in
> the database.
>
> Is this a consequence of how DBI is programmed?

Yes.

> Would it be easy to change to remove this limitation?

No.

> After all, it would be a lot easier to program/debug my driver if I
> could use all of perl's debugging tools..

You can use $h->dump_handle($message, $level).

Umm, I see that's not documented... I'll fix that for the next release.

Meanwhile, try $h->dump_handle("my handle dump", 1);

The dump is sent to the trace filehandle, which defaults to STDERR.
If $level>0 then the dump includes the contents of the attribute cache
(attribute values which have been fetched and the driver has cached
because they don't change, such as $sth->{NAME})

Tim.