another odd error:
[for Statement "select distinct a.cn, a.email from admins a, resourceadminaffil
r, resources r2, adminaffil a2, affils a3 where a.pid = r.pid and r.resource_id
= r2.resource_id and a.pid = a2.pid and a2.affil_id = a3.affil_id and
a3.affil_code in ('1901','PHRM') and r2.resour
On Mar 29, 2012, at 2:45 PM, Bruce Johnson wrote:
> another odd error:
>
Accidentally clipped off the actual error:
DBD::Oracle::st fetchrow failed: ERROR no statement executing (perhaps you need
to call execute first)
> [for Statement "select distinct a.cn, a.email from admins a,
> resour
On 29/03/12 22:45, Bruce Johnson wrote:
another odd error:
[for Statement "select distinct a.cn, a.email from admins a, resourceadminaffil r,
resources r2, adminaffil a2, affils a3 where a.pid = r.pid and r.resource_id =
r2.resource_id and a.pid = a2.pid and a2.affil_id = a3.affil_id and a3.af
On Mar 30, 2012, at 5:38 AM, Martin J. Evans wrote:
> So, as far as DBD::Oracle is concerned the statement handle is not active.
>
> Perhaps setting ora_verbose before your code above and turning it off
> afterwards would help us see what is really happening.
Well, I've got a ton of output but
Are you selecting Lobs or Blobs??
Could be an issue. Crank up the ora_verbse to 15 to get everything.
It would do an extra select to get any lob types.
I will have to have a look at the full thread sometime tomorrow.
Cheers
John
> Subject: Re: It's a bad day here...
>
Oh man this is embarrassing :-) A sharp-eyed reader pointed out that I was not
doing what I thought I was doing!
"I noticed the following (edited for emphasis):
> foreach $i (@resources){
>$csr_prefapp->execute($i)
>$csr_prefapp->fetchrow())
>if (!$have_pref){
>$csr_allapp->e
