help with odd DBI perpare/execute errors

[William Bulley]

Environment Perl script trying to query Oracle 11g database:

FreeBSD 9.3-STABLE

DBI 1.633

oracle8-client 0.2.0

DBD::Oracle 1.19

I have no trouble connecting with the Oracle database. And I do
recover data when I use the temporary workaround described below.

I have a query/prepare setup outside a foreach loop where I execute()
the prepared query something like this, only more complex:

my $query = "select column from table where column = ?";

my $sth = $dbh->prepare ($query);

foreach ()
{
$sth->execute($value);
}

I was getting invalid string ORA-0911 errors at the question mark.
I then replaced the question mark with a number (555) and made the
execute() call just "$sth->execute();"

This worked. But I really needed to bind to the $value variable
in the foreach loop.

In reading the DBI POD it said for Oracle the "?" is turned into
":p1" (in this case). So I replaced the question mark with :p1.

The prepare statement no longer generated an error, instead the
execute statement generated the error:

DBD::Oracle::st execute failed: called with 1 bind variables
when 0 are needed [for Statement ... ] at script.pl line xxx.

Can any one help me figure out this confusing situation? BTW, I
have been using Perl for twenty years and DBI for perhaps ten,
and I have used this query/prepare/bind/execute methodology in
the past with success. Something is different, but I don't know
what to look for.

Regards,

web...

--

/"\ ASCII RIBBON / William Bulley
\ / CAMPAIGN AGAINST /
X HTML E-MAIL AND / E-MAIL: w...@umich.edu
/ \ LISTSERV POSTINGS /

72 characters width template ----------------------------------------->|

[Martin J. Evans]

On 03/06/15 14:06, William Bulley wrote:
> Environment Perl script trying to query Oracle 11g database:
>
> FreeBSD 9.3-STABLE
>
> DBI 1.633
>
> oracle8-client 0.2.0
>
> DBD::Oracle 1.19
>
> I have no trouble connecting with the Oracle database. And I do
> recover data when I use the temporary workaround described below.
>
> I have a query/prepare setup outside a foreach loop where I execute()
> the prepared query something like this, only more complex:
>
> my $query = "select column from table where column = ?";
>
> my $sth = $dbh->prepare ($query);
>
> foreach ()
> {
> $sth->execute($value);
> }
>
> I was getting invalid string ORA-0911 errors at the question mark.
> I then replaced the question mark with a number (555) and made the
> execute() call just "$sth->execute();"

So, when this fails, what is the value of $value. Assuming you have RaiseError set, you can just put an eval around the execute and if $@ is set, print out $value.

> This worked. But I really needed to bind to the $value variable
> in the foreach loop.
>
> In reading the DBI POD it said for Oracle the "?" is turned into
> ":p1" (in this case). So I replaced the question mark with :p1.

Strictly speaking you do not need to do this - ? is fine. DBD::Oracle also supports named parameters e.g., ':myparam' which only has an advantage if you want to use :myparam more than once in the SQL.

> The prepare statement no longer generated an error, instead the
> execute statement generated the error:
>
> DBD::Oracle::st execute failed: called with 1 bind variables
> when 0 are needed [for Statement ... ] at script.pl line xxx.

Either because you omitted the value from execute but more likely because you need to associate $value with the NAMED parameter i.e., call bind_param.

> Can any one help me figure out this confusing situation? BTW, I
> have been using Perl for twenty years and DBI for perhaps ten,
> and I have used this query/prepare/bind/execute methodology in
> the past with success. Something is different, but I don't know
> what to look for.
>
> Regards,
>
> web...
>

Tell us the column type of 'column' and the value of $value when the original code fails. If this does not enlighten you, reduce this to a small reproducible script and re-run with ora_verbose set to 7. Paste the output somewhere we can view it.

Martin

[William Bulley]

According to "Martin J. Evans" <boh...@ntlworld.com> on Wed, 06/03/15 at 09:15:

>
> So, when this fails, what is the value of $value.

I just ran it again. The value is 547.

> Assuming you have RaiseError set, you can just put an eval
> around the execute and if $@ is set, print out $value.

I don't. I have a print statement in front of the execute to
show my what I am passing to the execute() method.

> Strictly speaking you do not need to do this - ? is fine.
> DBD::Oracle also supports named parameters e.g., ':myparam'
> which only has an advantage if you want to use :myparam
> more than once in the SQL.

The query is quite complex -- two SELECT statements connected
by a UNION statement -- and the "column = ?" syntax is used
twice. I changed the "?" to ":myparam" in both places and I
still get the error:

DBD::Oracle::st execute failed: called with 1 bind
variables when 0 are needed [for Statement...

> Either because you omitted the value from execute

In this case, it was not omitted.

> but more likely because you need to associate $value
> with the NAMED parameter i.e., call bind_param.

That will be my next test, but I don't hold out much hope for
that working either (I've never had to do this in the past).

> Tell us the column type of 'column' and the value of $value
> when the original code fails. If this does not enlighten you,
> reduce this to a small reproducible script and re-run with
> ora_verbose set to 7. Paste the output somewhere we can view it.

The Oracle type for the column in question is NUMBER. I assumed
that any integer value would be compatible. The value is 547 for
the run that just failed.

Never heard of ora_verbose -- where is this to be set? Just in
my code somewhere, or on the DBI->connect() method, or where?

[Martin J. Evans]

On 03/06/15 14:38, William Bulley wrote:
> According to "Martin J. Evans" <boh...@ntlworld.com> on Wed, 06/03/15 at 09:15:
>>
>> So, when this fails, what is the value of $value.
>
> I just ran it again. The value is 547.

Sounds ok but the error is "invalid string"

ORA-0911
You tried to execute a SQL statement that included a special character.

http://www.techonthenet.com/oracle/errors/ora00911.php
lists various causes.

>> Assuming you have RaiseError set, you can just put an eval
>> around the execute and if $@ is set, print out $value.
>
> I don't. I have a print statement in front of the execute to
> show my what I am passing to the execute() method.

I'm not sure I'd trust that - doesn't that mean you are expecting stdin and stout to be in order. If you can easily do it I would stick an eval around it and trap it that way. Also, if you trap it you can print the SQL using
http://search.cpan.org/~timb/DBI-1.633/DBI.pm#Statement
and the parameters using
http://search.cpan.org/~timb/DBI-1.633/DBI.pm#ParamValues

>> Strictly speaking you do not need to do this - ? is fine.
>> DBD::Oracle also supports named parameters e.g., ':myparam'
>> which only has an advantage if you want to use :myparam
>> more than once in the SQL.
>
> The query is quite complex -- two SELECT statements connected
> by a UNION statement -- and the "column = ?" syntax is used
> twice. I changed the "?" to ":myparam" in both places and I
> still get the error:
>
> DBD::Oracle::st execute failed: called with 1 bind
> variables when 0 are needed [for Statement...
>
>> Either because you omitted the value from execute
>
> In this case, it was not omitted.

I would not bother changing from ? to named - I seriously doubt this is the issue.

>> but more likely because you need to associate $value
>> with the NAMED parameter i.e., call bind_param.
>
> That will be my next test, but I don't hold out much hope for
> that working either (I've never had to do this in the past).
>
>> Tell us the column type of 'column' and the value of $value
>> when the original code fails. If this does not enlighten you,
>> reduce this to a small reproducible script and re-run with
>> ora_verbose set to 7. Paste the output somewhere we can view it.
>
> The Oracle type for the column in question is NUMBER. I assumed
> that any integer value would be compatible. The value is 547 for
> the run that just failed.
>
> Never heard of ora_verbose -- where is this to be set? Just in
> my code somewhere, or on the DBI->connect() method, or where?

http://search.cpan.org/~pythian/DBD-Oracle-1.74/lib/DBD/Oracle.pm#ora_verbose

Can be set in the connect attributes.

> Regards,
>
> web...
>

If I were you I'd try and simply the original case down as much as possible but getting a trace with ora_verbose might help identify the problem.

Martin

[William Bulley]

According to "Martin J. Evans" <boh...@ntlworld.com> on Wed, 06/03/15 at 09:48:

>
> Sounds ok but the error is "invalid string"
>
> ORA-0911
> You tried to execute a SQL statement that included a special character.
>
> http://www.techonthenet.com/oracle/errors/ora00911.php
> lists various causes.

Yep, I've been all over the net looking for this issue. I am not
doing anything wrong -- the "invalid string" is the darn "?"!!!


DBD::Oracle::db prepare failed: ORA-00911: invalid character
(DBD ERROR: error possibly near <*> indicator at char 370 in '
select distinct s.ITEMIDNUM,
c.STATUSDES,
s.ADDRESS128BIT,
s.PREFIX_LEN,
s.ENDADDRESS128BIT,
s.CREATED_USER,
to_char(s.CREATED_DATE, 'YYYY-MM-DD HH24:MI:SS'),
i.ITEMDES,
i.COMMENTS,
s.RESERVEDFOR,
s.AGGREGATE_STATUS,
i.STATUSCD,
i.ITEMNAME
from UMNET_ONLINE.IP6NET s, UMNET_ONLINE.ITEM i, UMNET_ONLINE.STATUS_CODE c
where i.PARENTITEMIDNUM = <*>?
and i.ITEMIDNUM = s.ITEMIDNUM
and i.STATUSCD = c.STATUSCD
and i.ITEMCATCD like 'IPv6'
union
select distinct s.ITEMIDNUM,
c.ITEMRELTYPDES,
s.ADDRESS128BIT,
s.PREFIX_LEN,
s.ENDADDRESS128BIT,
s.CREATED_USER,
...'

You can see the error complaining about the question mark above.
There is a second question mark in the second select statement.

> I'm not sure I'd trust that - doesn't that mean you are
> expecting stdin and stout to be in order.

Yes, and they are.

> If you can easily do it I would stick an eval around it and
> trap it that way. Also, if you trap it you can print the SQL using
> http://search.cpan.org/~timb/DBI-1.633/DBI.pm#Statement
> and the parameters using
> http://search.cpan.org/~timb/DBI-1.633/DBI.pm#ParamValues

I'll have to look into that. But recall this: I am not getting
to the execute() statement. The above error is on the prepare()
statment. This is so very confusing to me...

> I would not bother changing from ? to named - I seriously doubt this is the issue.

And you can see from the above that the question mark is back
in the mix.

> http://search.cpan.org/~pythian/DBD-Oracle-1.74/lib/DBD/Oracle.pm#ora_verbose
>
> Can be set in the connect attributes.

Thanks. :-)

> If I were you I'd try and simply the original case down as much as
> possible but getting a trace with ora_verbose might help identify the problem.

Okay, I'll try that next.

[Bruce Johnson]

> On Jun 3, 2015, at 6:57 AM, William Bulley <w...@umich.edu> wrote:
>
> Yep, I've been all over the net looking for this issue. I am not
> doing anything wrong -- the "invalid string" is the darn "?"!!!

Make sure your original $query is delimited by double quotes, not single.

if you do $sth->prepare(‘select column from table where column = ?’); you’ll get that error.

That’s the only way the ? would get past DBI, I’d think, which is what your oracle error seems to be indicating.


--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

[William Bulley]

According to Bruce Johnson <joh...@Pharmacy.Arizona.EDU> on Wed, 06/03/15 at 10:10:

>
>
> Make sure your original $query is delimited by double quotes, not single.

I've tried _everything_!!

Single quotes. Double quotes. q{} and qq{} (using the latter now).

But no matter what I try DBI complains about the darn question mark!

It is infuriating, I tell you! :-)

> if you do $sth->prepare('select column from table where column = ?');
> you'll get that error.
>
> That's the only way the ? would get past DBI, I'd think, which is
> what your oracle error seems to be indicating.

It is still not repsonding to any attempts to remedy the problem, sigh... :-(

[Howard, Chris]

Can you post a copy of your prepare statement?

[William Bulley]

According to "Howard, Chris" <How...@prpa.org> on Wed, 06/03/15 at 10:44:

>
> Can you post a copy of your prepare statement?

Sure. Here it is:

$sth = $dbh->prepare ($query) or die "Couldn't prepare statement: " . $dbh->errstr;

[Martin J. Evans]

On 03/06/15 17:12, Bruce Johnson wrote:

>
>> On Jun 3, 2015, at 7:19 AM, William Bulley <w...@umich.edu> wrote:
>>
>> According to Bruce Johnson <joh...@Pharmacy.Arizona.EDU> on Wed, 06/03/15 at 10:10:
>>>
>>>
>>> Make sure your original $query is delimited by double quotes, not single.
>>
>> I've tried _everything_!!
>>
>> Single quotes. Double quotes. q{} and qq{} (using the latter now).
>>
>> But no matter what I try DBI complains about the darn question mark!
>>
>> It is infuriating, I tell you! :-)
>

> Well, I just tested MY theory (RHEL v6.5, oracle 11.2g, oracle instant client for 11.2, perl, v5.10.1 (*) built for x86_64-linux-thread-multi) with:
>
> #!/usr/bin/perl
> use strict;
> use DBI;
> my $dbh= DBI->connect(“dbi:Oracle:host=$host", $user, $pass, {RaiseError =>1});
>
> my $qry1 ='select ? from dual';
> my $qry2 = "select ? from dual";
> my $sth = $dbh->prepare($qry1);
> $sth->execute('foo');
> my ($res)=$sth->fetchrow();
> print "single quote result is $res \n";
> $sth =$dbh->prepare($qry2);
> $sth->execute('bar');
> ($res)=$sth->fetchrow();
> print "double quote result is $res \n";
> exit;
>
> And got:
> # ./qmarktest.pl
> single quote result is foo
> double quote result is bar
>
> So yet another fine theory destroyed by reality…
>
> Possibly some sort of character set mess up? Could your 'question mark' be something else in the script? Maybe a 16-bit vs 8-bit character? I’ve had some weird issues in the past when I was handed a 16-bit unicode text file of insert statements and tried to run them.
>

Bruce,

Just so you know, I've already told William off list that question mark should not get through to Oracle and so the preparse method in DBD::Oracle is not spotting the ? - perhaps because it is not a ? or it thinks it is in a comment, literal etc. However, I expect, as you do, that one of the chrs in the SQL is not what it seems.

Sorry, as log file was sent to me I answered it and did not cc the list.

Martin

[Bruce Johnson]

> On Jun 3, 2015, at 7:19 AM, William Bulley <w...@umich.edu> wrote:
>

> According to Bruce Johnson <joh...@Pharmacy.Arizona.EDU> on Wed, 06/03/15 at 10:10:
>>
>>
>> Make sure your original $query is delimited by double quotes, not single.
>
> I've tried _everything_!!
>
> Single quotes. Double quotes. q{} and qq{} (using the latter now).
>
> But no matter what I try DBI complains about the darn question mark!
>
> It is infuriating, I tell you! :-)

Well, I just tested MY theory (RHEL v6.5, oracle 11.2g, oracle instant client for 11.2, perl, v5.10.1 (*) built for x86_64-linux-thread-multi) with:

#!/usr/bin/perl
use strict;
use DBI;
my $dbh= DBI->connect(“dbi:Oracle:host=$host", $user, $pass, {RaiseError =>1});

my $qry1 ='select ? from dual';
my $qry2 = "select ? from dual";
my $sth = $dbh->prepare($qry1);
$sth->execute('foo');
my ($res)=$sth->fetchrow();
print "single quote result is $res \n";
$sth =$dbh->prepare($qry2);
$sth->execute('bar');
($res)=$sth->fetchrow();
print "double quote result is $res \n";
exit;

And got:
# ./qmarktest.pl
single quote result is foo
double quote result is bar

So yet another fine theory destroyed by reality…

Possibly some sort of character set mess up? Could your 'question mark' be something else in the script? Maybe a 16-bit vs 8-bit character? I’ve had some weird issues in the past when I was handed a 16-bit unicode text file of insert statements and tried to run them.

[Martin J. Evans]

On 03/06/15 14:06, William Bulley wrote:

> Environment Perl script trying to query Oracle 11g database:
>
> FreeBSD 9.3-STABLE
>
> DBI 1.633
>
> oracle8-client 0.2.0
>
> DBD::Oracle 1.19

It seems I missed this ^^^^^

A 9 year old DBD::Oracle. I can well believe the preparse code has changed or been fixed in all that time.

I've recommended William tries a newer version as I suspect the preparse code it failing since those ? should not get to Oracle.

Martin

[Howard, Chris]

Thanks!
And what does $query contain?

-----Original Message-----
From: William Bulley [mailto:w...@umich.edu]
Sent: Wednesday, June 03, 2015 9:14 AM
To: Howard, Chris
Cc: Martin J. Evans; dbi-...@perl.org
Subject: Re: help with odd DBI perpare/execute errors

[William Bulley]

According to "Howard, Chris" <How...@prpa.org> on Wed, 06/03/15 at 12:30:

>
> Thanks!
> And what does $query contain?

That is the issue! Martin has worked with me off-line and clearly
the query contained some quote characters. I've attempted to either
remove those or quote them the DBI quote() way, but since some of
my columns have VARCHAR2 types, I must issue this sort of syntax in
my WHERE clause:

column LIKE 'something'

It can't be avoided. And since the basic structure of the "query"
is like this:

select distinct
column,
column,
column
from table, table, table
where column = ?
column = column,
column = column,
column LIKE 'something'
union
select distinct
column,
column,
column
from table, table, table
where column = ?
column = column,
column = column,
column LIKE 'something'

Note the two question marks. The first one passes muster, but the
second one is flagged as an error (invalid character):

DBD::Oracle::db prepare failed: ORA-00911: invalid character

(DBD ERROR: error possibly near <*> indicator at char 788 in'
<< snipped query here>>' at script.pl line xxx

Martin thinks the parsing in the dbd_preparse() function within the
dbdimp.c file (part of DBD::Oracle) has issues so that it cannot deal
with the second question mark given the preceding single quote(s).

It seems plausible, yet odd, to me, but it isn't my module. Perhaps
I have an older version? I dunno... :-(

[Howard, Chris]

Yes, that is the issue.

I was hoping you could share the actual code
with us. But no problem. Sounds like you have
some good clues.

Using Oracle 8 client and ancient DBI libraries
probably isn't helping, but also seems unlikely to hurt.

I'm leaning toward the opinion of an invisible special character
of some sort embedded in your query string.
But I could be all wet.

Does it exhibit the same failure if you swap the selects
around the 'UNION' ?

-----Original Message-----
From: William Bulley [mailto:w...@umich.edu]
Sent: Wednesday, June 03, 2015 10:44 AM
To: Howard, Chris
Cc: Martin J. Evans; dbi-...@perl.org
Subject: Re: help with odd DBI perpare/execute errors

[William Bulley]

According to "Howard, Chris" <How...@prpa.org> on Wed, 06/03/15 at 13:09:

>
> I was hoping you could share the actual code
> with us. But no problem. Sounds like you have
> some good clues.
>
> Using Oracle 8 client and ancient DBI libraries
> probably isn't helping, but also seems unlikely to hurt.
>
> I'm leaning toward the opinion of an invisible special character
> of some sort embedded in your query string.
> But I could be all wet.
>
> Does it exhibit the same failure if you swap the selects
> around the 'UNION' ?

My focus now is trying to install DBD::Oracle 1.74 from CPAN (from
April of 2014) on my system. Yes, I am using the Oracle 8 instant
client. What is confusing to me is why FreeBSD _still_ contains
DBD::Oracle 1.19 in their "ports" tree! After all these years!

[Howard, Chris]

cat scriptname | od -bc | more

-----Original Message-----
From: Bruce Johnson [mailto:joh...@Pharmacy.Arizona.EDU]
Sent: Wednesday, June 03, 2015 11:13 AM
To: William Bulley
Cc: dbi-...@perl.org
Subject: Re: help with odd DBI perpare/execute errors

> On Jun 3, 2015, at 9:44 AM, William Bulley <w...@umich.edu> wrote:
>
> Martin thinks the parsing in the dbd_preparse() function within the
> dbdimp.c file (part of DBD::Oracle) has issues so that it cannot deal
> with the second question mark given the preceding single quote(s).
>
> It seems plausible, yet odd, to me, but it isn't my module. Perhaps
> I have an older version? I dunno... :-(

I have numerous constructions like yours in my scripts and they work just fine (and have for a very long time, I’m pretty sure prior to 2006 which is when 1.19 was released, so I don’t believe it’s your DBD::Oracle version )

Double check those single quotes, though, I’ve seen editors that try to sneak in ‘smart quotes’ and those’ll bollix you every time.

Here’s a quicky test:

#!/usr/bin/perl
use strict;

foreach my $i (qw (? ' " “ ” ‘ ’ )){
print "$i is ascii ".(ord $i)."\n"
}

exit;

This is what it produces:

dbdev2:~ johnson$ perl test
? is ascii 63
' is ascii 39
" is ascii 34
? is ascii 210
? is ascii 211
? is ascii 212
? is ascii 213

Note the displayed ‘?’’s….this is in my standard OSX terminal, which is a VT-100 emulator using UTF-8 as the text encoding.

[Bruce Johnson]

> On Jun 3, 2015, at 9:44 AM, William Bulley <w...@umich.edu> wrote:
>

> Martin thinks the parsing in the dbd_preparse() function within the
> dbdimp.c file (part of DBD::Oracle) has issues so that it cannot deal
> with the second question mark given the preceding single quote(s).
>
> It seems plausible, yet odd, to me, but it isn't my module. Perhaps
> I have an older version? I dunno... :-(

[pa...@pair.com]

in message <2015060317...@itcom245.staff.itd.umich.edu>,
wrote William Bulley thusly...
>
...

> My focus now is trying to install DBD::Oracle 1.74 from CPAN (from
> April of 2014) on my system.

...

> What is confusing to me is why FreeBSD _still_ contains
> DBD::Oracle 1.19 in their "ports" tree! After all these years!

Since it's maintainership was passed to perl@freebsd ...

r296145 | skv | 2012-05-07 05:42:51 -1000 (Mon, 07 May 2012) | 4 lines

Pass maintainership of almost of my "p5-*" ports to "perl@".

(I hope updating of them will be improved).


... DBD::Oracle has not been updated. (The updates that are there are
related to Ports infrastructure & build/install.)

Somebody needs to file a PR to update the port. (Tsk, tsk [0,1].)


- parv


[0] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/

[1] https://bugs.freebsd.org/bugzilla/enter_bug.cgi?component=Individual%20Port%28s%29&product=Ports%20%26%20Packages

--

[Kurt Jaeger]

Hi!

> What is confusing to me is why FreeBSD _still_ contains
> DBD::Oracle 1.19 in their "ports" tree! After all these years!

Because:

DBD::Oracle no longer supports Oracle client versions before 9.2
Try a version before 1.25 for 9 and 1.18 for 8! at ./Makefile.PL line 271.

and there is no oracle9-client port on FreeBSD.

--
p...@opsec.eu +49 171 3101372 5 years to go !

[William Bulley]

According to Kurt Jaeger <dbi-...@opsec.eu> on Thu, 06/04/15 at 02:50:

>
> DBD::Oracle no longer supports Oracle client versions before 9.2
> Try a version before 1.25 for 9 and 1.18 for 8! at ./Makefile.PL line 271.
>
> and there is no oracle9-client port on FreeBSD.

Thanks. That makes sense. What doesn't make sense and begs the
following question is:

Why isn't there an oracle9-client port for FreeBSD?

Is this an Oracle issue? Is this a FreeBSD issue? Or what? Thanks!

[Kurt Jaeger]

Hi!

> According to Kurt Jaeger <dbi-...@opsec.eu> on Thu, 06/04/15 at 02:50:

> > DBD::Oracle no longer supports Oracle client versions before 9.2
> > Try a version before 1.25 for 9 and 1.18 for 8! at ./Makefile.PL line 271.
> >
> > and there is no oracle9-client port on FreeBSD.
>
> Thanks. That makes sense. What doesn't make sense and begs the
> following question is:
>
> Why isn't there an oracle9-client port for FreeBSD?
>
> Is this an Oracle issue? Is this a FreeBSD issue? Or what? Thanks!

My guess: no-one had the need, time and skills to fix it.

There's a newer linux-oracle-instantclient-sdk available in the
ports (10.2.0.3), and maybe it helps to compile and link a newer
DBD::Oracle.

And there's an newer version (12.1.0.2.0) pending commit:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157544

[William Bulley]

According to Kurt Jaeger <dbi-...@opsec.eu> on Thu, 06/04/15 at 09:38:

>
> My guess: no-one had the need, time and skills to fix it.
>
> There's a newer linux-oracle-instantclient-sdk available in the
> ports (10.2.0.3), and maybe it helps to compile and link a newer
> DBD::Oracle.

I have that one (actually, those three), but they are nine
years old as well: 20061115_5 is coded into the ports name.

> And there's an newer version (12.1.0.2.0) pending commit:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=157544

Thanks! :-)

[Kurt Jaeger]

Hi!

> > There's a newer linux-oracle-instantclient-sdk available in the
> > ports (10.2.0.3), and maybe it helps to compile and link a newer
> > DBD::Oracle.
>
> I have that one (actually, those three), but they are nine
> years old as well: 20061115_5 is coded into the ports name.

The API did not change that much, so I guess it might work to use 10.2.0.3
to update the DBD::Oracle port to 1.74.

I'm currently upgrading my test host from perl5.20 to perl5.22, so it
will take some time until I can experiment with 1.74.

[Kurt Jaeger]

It looks promising, but:

The FreeBSD ld does not like the SYSV shared lib to link with:

LD_RUN_PATH="/compat/linux/usr/lib/oracle/10.2.0.3/client/lib" cc -shared -L/usr/ports/lang/perl5.22/work/perl-5.22.0 -L/usr/local/lib/perl5/5.22/mach/CORE -Wl,-rpath=/usr/local/lib/perl5/5.22/mach/CORE -lperl -L/usr/local/lib -fstack-protector Oracle.o dbdimp.o oci8.o -o blib/arch/auto/DBD/Oracle/Oracle.so -L/compat/linux/usr/lib/oracle/10.2.0.3/client/lib -L/usr/local/home/pi/myp/databases/p5-DBD-Oracle/work/DBD-Oracle-1.74/../.. -locci -lclntsh -lpthread
/usr/bin/ld: skipping incompatible /compat/linux/usr/lib/oracle/10.2.0.3/client/lib/libocci.so when searching for -locci
/usr/bin/ld: cannot find -locci
cc: error: linker command failed with exit code 1 (use -v to see invocation)

file /compat/linux/usr/lib/oracle/10.2.0.3/client/lib/libocci.so

libocci.so.10.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

and I do not have a non-shared lib to link against. Any ideas ?

Can a SYSV shared lib be transformed into some other shlib ?