On Fri, 2005-10-21 at 20:47 +0100, Tim Bunce wrote:
>
> 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)=SUCCESS
> dbd_st_execute SELECT returned (SUCCESS,
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 t
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 re
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 kno
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
