Re^2: LOB's refetch improperly

Andye,

Thanks for taking time to respond. I just posted another reply regarding SCHEMATABLE.TABLE providing more details, but to summarize: its not a typo. DBD::Oracle seems to be putting this together on the LOB refetch.

More specific to your questions: 1> No, I haven't tried setting up the alias like that. I think I may. 2> It happens on execute, not prepare.

I appreciate the attention that monks are giving this. All ideas are welcome, and I'll happily provide more code samples to illustrate various ideas on request.

Bro. Doug :wq

Comment on Re^2: LOB's refetch improperly

Replies are listed 'Best First'.
Re^3: LOB's refetch improperly by andye (Curate) on Mar 19, 2007 at 19:17 UTC
Hi again Doug. A different idea: I'm looking at this bit of the Oracle::DBD docs: "One further wrinkle: for inserts and updates of LOBs, DBD::Oracle has to be able to tell which parameters relate to which table fields. In all cases where it can possibly work it out for itself, it does, however, if there are multiple LOB fields of the same type in the table then you need to tell it which field each LOB param relates to" Although if that was the problem then it would be really weird for it to work as one user but not as another - but maybe the aliases are screwing things up somehow. Does it help if you use `$sth->bind_param($idx, $value, { ora_type=>ORA_CLOB, ora_field=>'foo' });` ? HTH, andye	[reply] [d/l]
Re^4: LOB's refetch improperly by Bro. Doug (Monk) on Mar 19, 2007 at 22:36 UTC
I'm reading this, uncertain of why I haven't tried that. I've looked at that several times in perldoc DBD::Oracle. I believe this is one of those cases where 'it works it out for itself' because I have other programs accessing these tables (though in their own schemas). That said, I'll try anything at this point. I can see where it could be an issue, so I should do it... runs off and does it No dice. Worth a try, though. Bro. Doug :wq	[reply]