Thanks to all of you for taking the time to answer my questions. Unfortunately I don't have the output from the compile. However consider that we are able to connect, select, insert, and update regular fields, it would seem that for the most part things were successful, unless I'm missing something.
As to the make test. Pretty much all tests passed, however there was one
test that failed and that was, you guessed it, the 31lob.t test. The
31lob_extended.t passed.
So 31lob.t produced :
t/31lob.t ............... 2/12 DBD::Oracle::db do failed: ORA-00942: table
or view does not exist (DBD ERROR: error possibly near <*> indicator at char
14 in 'select * from <*>v$session where 0=1') [for Statement "select * from
v$session where 0=1"] at t/31lob.t line 79.
the user doesn't have access to v$session and we can't really change that.
Anyway, as I have updated before it would seem that the use of the ora_types
constants is what's affecting this. When I bind parameters using an %attr
hash with bind params, it triggers the lob refetch issue. Without it,
however things seems fine.
my bind params call was something like
$sth->bind_param($binder_symbol, $value, {ora_types=>ORA_CLOB,
ora_field=>$fieldname});
So without the anonymous hash ref, things seem hunky dory, however the docs
say I need those params for handling lobs, so it has me worried.
I'll keep y'all posted.
Thanks,
Carl Furst
CMS Developer
MLB Advanced Media
-----Original Message-----
From: John Scoles [mailto:sco...@pythian.com]
Sent: Tuesday, December 21, 2010 8:51 AM
To: dbi-users@perl.org
Subject: Re: DBD::Oracle, 10g Lob Refetch problem
On 20/12/2010 3:17 PM, Furst, Carl wrote:
> Hello,
>
> I just built DBD::Oracle 1.26 on Solaris SPARC 2.10 using perl 5.8.5 32
bit
> against client 10.0.2.4
>
> We've been having trouble since day one. The biggest problem is that we
are
> having a problem writing LOB fields. We get the following error:
>
> DBD::Oracle::st execute failed: ORA-00903: invalid table name (DBD
> ERROR: OCIStmtExecute/LOB refetch)
>
To start we will need to see the output from the perl Makefile.PL and
the make, and make test to see if there is something wrong with the way
it is being built
> We think it's the LOB refetch that's causing the issue.
>
> the encoding of the database and the NLS_LANG parameter are both UTF8
> nls_lang specifically is AMERICAN_AMERICA.UTF8
>
> If anyone has any advice about this, it would be a big help.
>
Next we will need to see an example of your code as there are at least 4
different ways to write lob fields with DBD::Oracle
> My questions are the following:
> 1) do we need an actual Oracle server to build the DBD - if so what libs
> would we need to link against?
No you do not need a server you only need the client. Instant client
should work fine
> 2) Has anyone else experienced this; building again lib32 client libs.
Solaris SPARC tends to have more problems that other OS when attempting to
compile DBD::Oracle in 32bit but since you
have it working you should be past this point
> 3) What role does oraperl have in all this? If oraperl fails to compile,
is
> that a blocker for DBD?
>
No it is a separate and deprecated hunk of code for perl 4. It may be a
symptom of a deeper problem so we need to see the Makefile.pl and make
output to know for sure.
Cheers
John Scoles
> Thanks in advance,
>
> Carl Furst
> CMS Developer
> MLB Advanced Media
>
>
>
>
>
>
>
> **********************************************************
>
> MLB.com: Where Baseball is Always On
smime.p7s
Description: S/MIME cryptographic signature
********************************************************** MLB.com: Where Baseball is Always On
