Re: Translate between DBI and SQL

[John Scoles]

Well not really much DBI can do for you.  You usually start from scratch trying 
to write SQL that is not Driver Specific though that can be hard.

you are usually stuck with something like this

sub edit_sql {
my ($self, $sql) = @_;​
​
if ($self->isPostgres) {​
return InformixToPgsSQL::modify($sql);​
} else {​
return PgsToInformixSQL::modify($sql);​
}​
}​
​
sub prepare {​
my ($this, $sql) = @_;​
​
$sql = $this->edit_sql($sql);​
​
if (0 && exists $this->{'cursors'}->{$sql} && $sql !~ /ref_cron_exec/si) {​
return ($this->{'cursors'}->{$sql});​
}​
else {​
my $start = Time::HiRes::time;​
my $qry;​
eval { $qry = $this->{'dbh'}->prepare($sql); };​
if ($qry) {​
$this->{'cursors'}->{$sql} = $qry;​
$this->{'stmts'}->{$qry}   = $sql;​
$this->report("Prepared", $sql, [], $start, Time::HiRes::time)​
if $$this{'monitor'};​
}​
else {​
my $err = "";​
eval { $err = $this->{'dbh'}->errstr(); };​
$this->log($err, $sql);​
}​
return ($qry);​
}​
}​

where in this case I have a Module that does the 'prepare' and there I check 
the SQL and make the required changes

the 'InformixToPgsSQL' and 'PgsToInformixSQL' just use regex to swap out any 
SQL that is not compatible like

this
 if ($sql =~ /\btoday\b/i) {
  $sql =~ s/\btoday\b/ current_date /gi;​
   }​

today vs current_date

One way around this situation is to write custom functions on the RDBMS side to 
mimic the functionality ie a 'current_date' function to mimic 'today'


Many here will say start afresh and use an ORM like DBIx::Class or 
Fey::ORM  or alike

Cheers

From: Mike Martin 
Sent: February 8, 2019 5:37 PM
To: dbi-users@perl.org
Subject: Translate between DBI and SQL

Has anyone done any work on converting SQL queries between RDBMS and perl?

My particular interest is DBD::Pg but anything would be of use

It would be very useful when I am testing complex SQL, it's very easy to miss a 
\ or quote between the two

Thanks
Mike

Re: Tim Bunce - RE: DBD-DBI Insert Binary Files and using Perl modules in cPanel environment

[John Scoles]

I would agree MySQL my not be the platform you want.  It is limited in what it 
can do.  I would give Postgress SQL a go.  You have the use the  'pg_lo_???' 
functions to manipulate your objects.  They work quite well.

By the way saving  images, mp3 etc  as blobs or lobs to a DB is not used in 
many new systems. It is now a rather dated as  it is much cheaper, more 
efficient and even more secure to save the file up on the cloud someplace (ie 
Amazon S3) and then use the DB to simply point to that file.

Blobs and Lobs where a solution to a problem from 20+ years ago when disk-space 
was very expensive and ban-with was low.  If you had to download a 10mg file 
you would have to break it up into 10~1 mg  blocks and lob/blobs where very 
good at this.  At the time someone with a home line over 128k was quite rare 
56k being the morm and 1meg being fantastically expensive.





From: Kimar Miller 
Sent: September 23, 2018 7:34 PM
To: dbi-users@perl.org
Subject: Tim Bunce - RE: DBD-DBI Insert Binary Files and using Perl modules in 
cPanel environment

Hi Tim - How's it going?

My name is Kimar and I'm looking to find out how to go about the development of 
a video application using the database MySQL as I own my own Domain name and am 
renting web host. This app may extend to greater than just a video but more of 
a multimedia app.

I'm a developer based in Florida; I was trained at Atlantic Technical College 
Coconut Creek. My instructor Ellen Williams; the hardest nut to crack but a 
very generous woman. Lots of years experience and lots of students. I graduated 
July 2017 and I've been doing some serious work on my own until I was 
approached by some friends of mine that have angel investors interested in a 
security login I've created.

I was recently attacked by someone from In2Cable India. I traced the IP that 
was logged in the cPanel. The deal is my app is more secure than my cPanel that 
requires me to have a hardware firewall that much I discovered after the breach 
that there's little I can do about it unless there's a hardware firewall or an 
app that is integrated in my browser to encrypt my submission to the login 
until it hits the server. None the less I have ongoing copyrighting processes 
occurring. You may or may not know about it but copyright protects you more 
than patents. Explaining what your thing does in the copyright proves you are 
the creator based on copyright clause "Works of the Mind".

I am particularly interested in having the system input the actual audio and 
video files such as MP3, or MPEG files to the database. I don't care about 
memory or resources.

CREATE TABLE `video` (
 `ID` int(11) NOT NULL
 PRIMARY KEY ,
  `NAME` varchar(40) DEFAULT NULL,
  `DESCRIPTION` varchar(100) DEFAULT NULL,
 `BLOBFILE` varchar(20) );

That's the table I used and the web page below


 Test submit 


 Test Perl Programming CGI post
http://post.pl>" method="POST">
home.pl: Nr 1 w Polsce. Domeny, Hosting, Serwery WWW, Strony, 
Sklepy
post.pl
Domeny internetowe: 1,2 mln | Serwery wirtualne: 150 tys. | Sklepy internetowe: 
7 tys. | Działamy niezawodnie od 20 lat. Dołącz do 2 mln użytkowników home.pl!



 Select a file to upload
Name: 
Description: 






My question is how can I get the insert to work.

I tried reading the books on this topic and did a global search, I long after 
exhausted all the links available.

I also am interested in using modules, is there a better explanation on using 
the maker object on CPAN its a hard read as I still am lost to some of the 
concepts in the manual.

I heavily rely on the perl.org resources so I decided to ask a 
professional.

Re: (Fwd) Perl with Oracle 12c

[John Scoles]

Hmm unless you change the installed clients you DBD::Oracle should still work. 
as 11->12 should work
If you are having problems you most likely will have to recompile DBD::Oracle 
against the new client

Checking DBD::Oracle I see it hasn't seen an update for at least 4 years or so 
and therefor not sure if you will need to re-compile and they do not list a 
compatibly chart anymore  so not 100% sure on the aboce.  Hopefully your 
DBD::Oracle was copiled against the 11.2 client and therefor you should have a 
seemless update to the 12 server.

cheers
John

From: tim.bu...@pobox.com 
Sent: April 10, 2018 11:02 AM
To: dbi-users@perl.org
Cc: Seidler, Reinhard
Subject: (Fwd) Perl with Oracle 12c

- Forwarded message from "Seidler, Reinhard" 
 -

Date: Tue, 10 Apr 2018 12:16:09 +
From: "Seidler, Reinhard" 
To: "tim.bu...@pobox.com" 
Subject: Perl with Oracle 12c

   Hi Tim,

   We develop Perl applications connecting and working with Oracle database 
(DBD:Oracle). So far it was
   Oracle version 11. Now the database will be migrated to 12.2.0.1. How should 
we deal with that? Any
   answer would be appreciated.

   Thanks in advance.

   With best regards
   Reinhard

   ***
   Reinhard Seidler
   Automation Engineer

   Advanced Mask Technology Center GmbH & Co. KG
 Phone:  [+49] (0) 351 4048 384
 Fax:   [+49] (0) 351 4048 189
 [1]mailto:reinhard.seid...@amtc-dresden.com

 Advanced Mask Technology Center GmbH & Co. KG
 Raehnitzer Allee 9  | D-01109 Dresden | GERMANY
 Sitz: Dresden
 Registergericht:Dresden
 HRA Nummer:   HRA 4820

 persönlich haftender Gesellschafter:
 Advanced Mask Technology Center Verwaltungs GmbH
 Sitz des persönlich haftenden Gesellschafters: Dresden
 Registergericht:  Dresden
 HRB-Nummer: HRB 22745
 Geschäftsführer:Thomas Schmidt
   ***

   Diese Mail einschliesslich der Anhänge könnte vertraulich sein. Sollten Sie 
nicht der beabsichtigte
   Empfänger dieser Mail sein, so ist jegliches Verwenden, Offenbaren oder 
Kopieren der Mail und ihrer
   Anhänge untersagt.
   Bitte informieren Sie den Absender und löschen Sie die Mail und deren 
Anhänge von Ihrem Rechner.
   Vielen Dank.

   This email and its attachments may be confidential and/or privileged. If you 
are not the intended
   recipient, any use, disclosure or copying of this email and its attachments 
is prohibited.
   If you have received this email in error, please notify immediately the 
sender by return email and
   delete this email and its attachments from your computer system. Thank you.




References

   Visible links
   1. mailto:reinhard.seid...@amtc-dresden.com

- End forwarded message -

Re: Hunting down (possible) memory leak in DBD::Oracle

[John Scoles]

Well it will be in either one of two .c files  dbdimp.c or oci8.c  The XS side 
of things Oracle.xs is not used very much.


The level 15 debug will get deep inside the c to see where it is happening. The 
trace you gave is a little high level


you are right ORA-01403 dose not make much sense here.


If could be running out of buffer.  Give some of the caching params a tweak


https://metacpan.org/pod/DBD::Oracle#RowCacheSize


if you can try give  fetchrow_hashref a try as see if the error happens there 
as well.


Cheers

John

DBD::Oracle - Oracle database driver for the DBI module 
...<https://metacpan.org/pod/DBD::Oracle#RowCacheSize>
metacpan.org
Oracle database driver for the DBI module ... NAME; VERSION; SYNOPSIS; 
DESCRIPTION; CONSTANTS; DBI CLASS METHODS. connect. OS authentication






From: Fennell, Brian 
Sent: December 18, 2017 11:25 AM
To: John Scoles; dbi-users@perl.org
Subject: RE: Hunting down (possible) memory leak in DBD::Oracle

John,
Thanks so much for your reply!

I have put off this work for a few years and now the pressure is on - the 
original box and OS are so old that the DBA and System Engineer and the 
Operations manager have all ganged up on me.

I suppose I could try and work around by downgrading both the perl and the 
DBD::Oracle to the same version we use in production, but it would be nice to 
actually fix the bug if I can.

I tried just downgrading the DBD::Oracle, but changes in perl 5 to support 
MULTIPLICITY made that look like more than just a little work - spend two days 
on it and then backed off.

I am a polyglot programmer so I can program in C and Perl (and about a dozen 
other languages).  I have done enough time with C that it doesn't scare me.  
Valgrind is new to me, but make and gcc and ld are not.
I have started to read the Valgrind docs and it seems to make sense - it 
basically emulates all the CPU instructions with injected instrumentation - I 
assume it works for Intel and Red Hat if it works at all
(and it seems to have a long history and good open source support community).  
Perhaps I am fooling myself, but I figure it is worth a try.

I have negotiated support from both DBA and System Engineering (the Red Hat OS 
guys) so if I am going to fix this now is the time.

The only other option I can think of is to try to get the old code working with 
the DBD::JDBC driver (which would mean adding a JVM running in parallel and 
additional overhead - so I would rather not).

1) The error changes depending on the data - which is why I think it is a 
buffer overrun or a wild pointer - but it is  always in "field N of N" - 
Current I can reproduce with ORA-01403
2) I will re-try at level 15 and post the results - current at 4 (or perhaps 5) 
here is a section from the log (which suggests to me it is happing in the C 
code and not in the Perl

-> fetchrow_array for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)
field #2 with rc=0(OK)
field #3 with rc=0(OK)
field #4 with rc=1405(NULL)
field #5 with rc=0(OK)
field #6 with rc=0(OK)
-> fetchrow_array for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010
dbd_st_fetch 6 fields...
dbd_st_fetched 6 fields with status of 0(SUCCESS)
field #1 with rc=0(OK)
field #2 with rc=0(OK)
field #3 with rc=0(OK)
field #4 with rc=14135(UNKNOWN RC=14135))
OCIErrorGet after ORA-14135 error on field 4 of 6, ora_type 2 (er1:ok): 
-1, 1403: ORA-01403: no data found

-- HandleSetErr err=1403, errstr='ORA-01403: no data found (DBD ERROR: 
ORA-14135 error on field 4 of 6, ora_type 2)', state=undef, undef
field #5 with rc=0(OK)
field #6 with rc=0(OK)
1   -> FETCH for DBD::Oracle::st 
(GSI::DBI::Connection::st=HASH(0x286f6b0)~INNER 'ParamValues') thr#134c010

3) I think the most exotic thing in these tables is a VARCHAR2 but I will check 
and post the results.
4) I looks like it is in the XS to me (see answer to 2) - but I suppose it 
could be elsewhere - like a loopback-perl-ref that should be weak but is not.
5) I think I have what I need, DBA installed Oracle 12 OCI client and "dot.so" 
libraries but currently I am concerned that I am using "ins_rdbms.mk" when I 
should be using "demo.mk" or similar - I am getting a Warning (see details 
below) when I run Makefile.PL - I asked DBA to look into installing the 
"demo.mk" file and consider opening up a Oracle METALINK support ticket to see 
if another customer had already solved this with Oracle's help.

Details:

# /usr/local/bin/perl Makefile.PL -g
Using DBI 1.637 (for perl 5.016003 on x86_64-linux-thread-multi) installed in 
/usr/local/lib64/perl5/auto/DB

Re: Hunting down (possible) memory leak in DBD::Oracle

[John Scoles]

Hmm this type of DBD::Oracle debugging will be tricky.

Could be almost anything.  You are jumping versions in a big way but that still 
should be ok

A few questions

1)  What is the  ORA-NN  in question
2) Set trace to 15  to see if that give you more details
3) What are the type of fields?  Lob and blob and large varchars can be tricky
4) does the error happen in perl or XS (the 15 trace should)
5) To recompile you will need the latest version of the OCI client. Not sure 
what that is

Cheers
John





From: Fennell, Brian 
Sent: December 16, 2017 5:19 PM
To: dbi-users@perl.org
Subject: Hunting down (possible) memory leak in DBD::Oracle

Dear DBI people -

I am trying to port some old perl code to a new box.  (see Details below) 
Needless to say the original box and code works fine, but the new box (and old 
code) does not.
Specifically what I am seeing is that when I select slightly over a million 
records from a specific join of two tables (to be dumped one row at a time into 
a TSV file) we get strange ORA-N errors that don't really make any sense in 
this context.
The Same database and same table works fine on the original box with the large 
number of records.  2 million records always causes errors but two groups of 
1million (divided up by ROWNUM - the EXACT same rows) causes no errors.  I am 
using a test database with little activity do I am reasonably certain that the 
queries deal with the same rows.
So I am thinking the problem is data volume and not any specific piece of data 
(originally I thought it might be an odd string/data related error, but I am 
starting to think it is a memory leak of some kind).
The error always happens inside of fetchrow_array - and "$dbh->trace( 4 , 
$filename )" shows that the error originates inside the DBD::Oracle module 
while reading field 3 of 6.
Researching the ORA-NN error gives a perfectly sane description that makes 
no sense at all in the context of reading a specific field.

We are going thru an Audit and tightening up security so there are some things 
(like REAL hostnames and REAL column/table names) that I cannot share - but I 
will try to share as much as I can.

The Host I am calling "prod" below is the only one NOT exhibiting this issue.

Things I want to try -

1) recompile the DBD::Oracle module on Host "sandbox" with "perl Makefile.PL 
-g" and then use Valgrind.  I haven't used Valgrind before, but I guess it is 
time to learn.
2) Anything else this list suggests.

Details:

Host: prod
OS: Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
Perl: 5.8.8 built for x86_64-linux
DBI: 1.53
DBD::Oracle: 1.19
Oracle: 10.2.0.1.0

Host: dev
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.74
Oracle: 11.2.0.3.0

Host: prodnew
OS: Red Hat Enterprise Linux Server release 6.5 (Santiago)
Perl: 5.16.1  built for x86_64-linux
DBI: 1.631
DBD::Oracle: 1.70
Oracle: 11.2.0.1.0

Host: sandbox
OS: CentOS Linux release 7.4.1708 (Core)
Perl: 5.16.3  built for x86_64-linux-thread-multi
DBI: 1.637
DBD::Oracle: 1.74
Oracle: 12.1.0.2.0

--
Brian Fennell, Software Engineer | Radial
O: 610 491 7308 | M: 484 354 1699
fenne...@radial.com

The information contained in this electronic mail transmission is intended only 
for the use of the individual or entity named in this transmission. If you are 
not the intended recipient of this transmission, you are hereby notified that 
any disclosure, copying or distribution of the contents of this transmission is 
strictly prohibited and that you should delete the contents of this 
transmission from your system immediately. Any comments or statements contained 
in this transmission do not necessarily reflect the views or position of Radial 
or its subsidiaries and/or affiliates.

 >++[>++>++>++>+++>+++>++>+++>+++><-]>-->++>+>>>+>-->--><>.>.>.>.>.>.>.>.

RE: Surprising DBD::Oracle error raised

[John Scoles]

Well isn't he is calling with the alias 'fetch' and he is calling it in I think 
scalar context

 

 

my ($row) = $s->fetchrow_array;


vs

 

 if ($price_sth->fetch) 


There is the odd chance that he is doing the SQL against a 'view', 'cursor'   
or alike but I doupt that is it.

 

 

> Date: Wed, 5 Feb 2014 13:25:03 +
> From: martin.ev...@easysoft.com
> To: davidni...@gmail.com; dbi-users@perl.org
> Subject: Re: Surprising DBD::Oracle error raised
> 
> On 04/02/14 19:36, David Nicol wrote:
> > $price_sth->execute;
> > my ($o_file_price) = $price_sth->fetchrow_array();
> > if ($price_sth->fetch) {
> > $this->log_error('ERROR: scalar select returned second row at
> > %s line %d', __FILE__, __LINE__);
> > }
> >
> >
> > I expected the fetch to return undef, but it throws an Oracle error.
> > My best ignorant guess here is that fetchrow_array does some cleanup
> > on one-row datasets, but that isn't documented.
> >
> > Advise?
> >
> >
> 
> That is in deed interesting. When I run the following with DBD::ODBC to MS 
> SQL Server:
> 
> use strict;
> use warnings;
> use DBI;
> 
> my $h = DBI->connect();
> eval {
> $h->do(q/drop table mje/);
> };
> 
> $h->do(q/create table mje (a int)/);
> my $s = $h->prepare(q/insert into mje values(?)/);
> $s->execute(1);
> $s->execute(2);
> 
> $s = $h->prepare(q/select * from mje where a = 1/);
> $s->execute;
> my ($row) = $s->fetchrow_array;
> print "$row\n";
> $row = $s->fetch;
> print "$row\n";
> 
> 
> I get:
> 
> 1
> Use of uninitialized value $row in concatenation (.) or string at 
> mje/fetch_off_end.pl line 20.
> 
> However, I get the same with DBD::Oracle so how is you code different from 
> the above.
> 
> Martin
  

RE: Surprising DBD::Oracle error raised

[John Scoles]

You are fetching off the end of a cursor so you would expect an error on any sql

Would be the same sort of thing as 

 

my @test= (1,2);

print $test[100];

 

If you know your recordset will be small I would use fetchall_arrrayref  or 
fetchall_hashref rather than just fetch.

 

 The normal way is to fetch is in a loop with  'while'.  As there is no way to 
tell how many records will be in 

your set before you do you SQL unless you tell the SQL to return only x rows.

 

Cheers

John

 

> Date: Tue, 4 Feb 2014 13:36:50 -0600
> Subject: Surprising DBD::Oracle error raised
> From: davidni...@gmail.com
> To: dbi-users@perl.org
> 
> $price_sth->execute;
> my ($o_file_price) = $price_sth->fetchrow_array();
> if ($price_sth->fetch) {
> $this->log_error('ERROR: scalar select returned second row at
> %s line %d', __FILE__, __LINE__);
> }
> 
> 
> I expected the fetch to return undef, but it throws an Oracle error.
> My best ignorant guess here is that fetchrow_array does some cleanup
> on one-row datasets, but that isn't documented.
> 
> Advise?
> 
> 
> -- 
> The one L lama, he's a priest
> The two L llama, he's a beast
> And I will bet my silk pyjama
> There isn't any three L lllama. -- Ogden Nash
  

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

 



From: byter...@hotmail.com
To: tim.bu...@pobox.com
CC: martin.ev...@easysoft.com; hhferre...@gmail.com; dbi-users@perl.org
Subject: RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
Date: Fri, 31 Jan 2014 18:04:44 -0500




 Opp hit send too fast

 
> Date: Fri, 31 Jan 2014 22:09:02 +
> From: tim.bu...@pobox.com
> To: byter...@hotmail.com
> CC: martin.ev...@easysoft.com; tim.bu...@pobox.com; hhferre...@gmail.com; 
> boh...@ntlworld.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> 
> On Fri, Jan 31, 2014 at 12:50:36PM -0500, John Scoles wrote:
> > Well I did do some testing. The leak was very small (1k over 10 min run) 
> > but only when one does
> > $shift->FETCH( 'ParamValues' ),
> > in the child callback.
> 
 
With of course the older DBI <1.63, 
 
 I did not see a leak with 1.63  no matter how long I let it run

> If it doesn't keep growing with more call then it's not a leak.
> 
> > Tim what would the impact of the above?? I know before 1.63 this
> > $shift->{ParamValues'},
> > gave you undef which is why the WTF comment was there.
> 
> Because the inner handle is a plain blessed hash ref, whereas the outer
> handle is *tied* blessed hash ref.
> 
> There's no 'ParamValues' key in that hash, so you get an undef.
> 
> The ParamValues lookup is handled by the FETCH method call.
> 
> > Why if in the CB we had the outter handle would the FETCH give you the 
> > attributes of the Inner handle??
> 
> Calling $outer->{ParamValues} in a tied hash ref triggers a call to
> $outer->FETCH('ParamValues') which then gets dispatched by the DBI to
> $inner->FETCH('ParamValues') which does the work.
> 
 
In pre 1.63 in the callback it  would be like this;
 
Calling $inner->{ParamValues}  = undef;

calling  $inner->FETCH('ParamValues') which does the work.
 
OK

> 
$inner->{ParamValues} 
 
 

> For more details see http://perldoc.perl.org/perltie.html
> 
> > Just a silly question?
> 
> No such thing :)
> 
> Tim.
> 
> > Cheers
> > 
> > 
> > 
> > > Date: Fri, 31 Jan 2014 17:00:20 +
> > > From: martin.ev...@easysoft.com
> > > To: tim.bu...@pobox.com; byter...@hotmail.com
> > > CC: hhferre...@gmail.com; boh...@ntlworld.com; dbi-users@perl.org
> > > Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> > >
> > > On 31/01/14 16:21, Tim Bunce wrote:
> > > > On Fri, Jan 31, 2014 at 09:11:28AM -0500, John Scoles wrote:
> > > >> A final note on this.
> > > >>
> > > >> Seems there was a very very long unknown bug in DBI which was only fix 
> > > >> a few days ago wiht DB
> > 1.6.31
> > > >
> > > > If you mean Callbacks getting an inner handle, that wasn't a bug as 
> > > > such.
> > > > More like a design choice that proved non-optimal.
> > > >
> > > >> [1]http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
> > > >
> > > > That's 
> > > > http://blogs.perl.org/users/byterock/2014/01/callbacks-ate-my-brain.html
> > > > I presume.
> > > >
> > > >> The end result of this bug was that when callbacks are used on the
> > > >> statement handle some attributes will not be there so you
> > > >> programmer who did this
> > > >>
> > > >> $sth->FETCH( 'ParamValues' ), # WTF? - returns a reference to an array 
> > > >> of hashes
> > > >>
> > > >> was most likely complaing that the
> > > >>
> > > >> $sth->{ParamValues},
> > > >>
> > > >> should return a ref but was just returning undef.
> > > >>
> > > >> So he 'Kludged' the code to get the value directly with the FETCH 
> > > >> which works
> > > >
> > > > I'm not sure what you're saying here John. Using 
> > > > $sth->FETCH('ParamValues')
> > > > is perfectly reasonable. It was required before 1.631 and optional with
> > > > 1.631+ now that $h->{ParamValues} works.
> > > >
> > > >> sort of, but it does bleed memory every so slighly.
> > > >
> > > > Are you sure? This is the first I've heard of such a leak.
> > > >
> > > > Tim.
> > >
> > > I've found no evidence of a 

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

 

> Date: Fri, 31 Jan 2014 22:09:02 +
> From: tim.bu...@pobox.com
> To: byter...@hotmail.com
> CC: martin.ev...@easysoft.com; tim.bu...@pobox.com; hhferre...@gmail.com; 
> boh...@ntlworld.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> 
> On Fri, Jan 31, 2014 at 12:50:36PM -0500, John Scoles wrote:
> > Well I did do some testing. The leak was very small (1k over 10 min run) 
> > but only when one does
> > $shift->FETCH( 'ParamValues' ),
> > in the child callback.
> 
> If it doesn't keep growing with more call then it's not a leak.
> 
> > Tim what would the impact of the above?? I know before 1.63 this
> > $shift->{ParamValues'},
> > gave you undef which is why the WTF comment was there.
> 
> Because the inner handle is a plain blessed hash ref, whereas the outer
> handle is *tied* blessed hash ref.
> 
> There's no 'ParamValues' key in that hash, so you get an undef.
> 
> The ParamValues lookup is handled by the FETCH method call.
> 
> > Why if in the CB we had the outter handle would the FETCH give you the 
> > attributes of the Inner handle??
> 
> Calling $outer->{ParamValues} in a tied hash ref triggers a call to
> $outer->FETCH('ParamValues') which then gets dispatched by the DBI to
> $inner->FETCH('ParamValues') which does the work.
> 
> For more details see http://perldoc.perl.org/perltie.html
> 
> > Just a silly question?
> 
> No such thing :)
> 
> Tim.
> 
> > Cheers
> > 
> > 
> > 
> > > Date: Fri, 31 Jan 2014 17:00:20 +
> > > From: martin.ev...@easysoft.com
> > > To: tim.bu...@pobox.com; byter...@hotmail.com
> > > CC: hhferre...@gmail.com; boh...@ntlworld.com; dbi-users@perl.org
> > > Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> > >
> > > On 31/01/14 16:21, Tim Bunce wrote:
> > > > On Fri, Jan 31, 2014 at 09:11:28AM -0500, John Scoles wrote:
> > > >> A final note on this.
> > > >>
> > > >> Seems there was a very very long unknown bug in DBI which was only fix 
> > > >> a few days ago wiht DB
> > 1.6.31
> > > >
> > > > If you mean Callbacks getting an inner handle, that wasn't a bug as 
> > > > such.
> > > > More like a design choice that proved non-optimal.
> > > >
> > > >> [1]http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
> > > >
> > > > That's 
> > > > http://blogs.perl.org/users/byterock/2014/01/callbacks-ate-my-brain.html
> > > > I presume.
> > > >
> > > >> The end result of this bug was that when callbacks are used on the
> > > >> statement handle some attributes will not be there so you
> > > >> programmer who did this
> > > >>
> > > >> $sth->FETCH( 'ParamValues' ), # WTF? - returns a reference to an array 
> > > >> of hashes
> > > >>
> > > >> was most likely complaing that the
> > > >>
> > > >> $sth->{ParamValues},
> > > >>
> > > >> should return a ref but was just returning undef.
> > > >>
> > > >> So he 'Kludged' the code to get the value directly with the FETCH 
> > > >> which works
> > > >
> > > > I'm not sure what you're saying here John. Using 
> > > > $sth->FETCH('ParamValues')
> > > > is perfectly reasonable. It was required before 1.631 and optional with
> > > > 1.631+ now that $h->{ParamValues} works.
> > > >
> > > >> sort of, but it does bleed memory every so slighly.
> > > >
> > > > Are you sure? This is the first I've heard of such a leak.
> > > >
> > > > Tim.
> > >
> > > I've found no evidence of a memory leak with a simple test calling 
> > > ParamValues a lot with some
> > parameters. However, I'm not using ORA_VARCHAR2_TABLE. The code is:
> > >
> > > else if (kl==11 && strEQ(key, "ParamValues")) {
> > > HV *pvhv = newHV();
> > > if (imp_sth->all_params_hv) {
> > > SV *sv;
> > > char *key;
> > > I32 keylen;
> > > hv_iterinit(imp_sth->all_params_hv);
> > > while ( (sv = hv_iternextsv(imp_sth->all_params_hv, &key, &keylen)) ) {
> > > phs_t *phs = (phs_t*)(void*)SvPVX(sv); /* placeholder struct */
> > > (void)hv_store(pvhv, key, keylen, newSVsv(phs->sv), 0);
> > > }
> > > }
> > > retsv = newRV_noinc((SV*)pvhv);
> > > cacheit = FALSE;
> > >
> > > }
> > >
> > > which looks sane to me right now. ORA_VARCHAR2_TABLE seems to do strange 
> > > things with parameters I
> > don't quite get right now.
> > >
> > > As I said previously to H�lder and John (some of the discussion was off 
> > > dbi-users list presumably
> > because it contained log data), although I accept taking the call to 
> > ParamValues out has on this
> > occasion made the problem go away I don't understand why. I think there is 
> > more to this than it so far
> > looks but without a way of reproducing it myself I won't be spending any 
> > more time on it. If it is
> > reproducible in a standalone script I will happily look again.
> > >
> > > Martin
  

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

 Well I did do some testing. The leak was very small (1k over 10 min run) but 
only when one does

 

$shift->FETCH( 'ParamValues' ), 

 in the child callback. 

 

Tim what would the impact of the above??  I know before 1.63 this

 

$shift->{ParamValues'}, 

 

gave you undef which is why the WTF comment was there.

 

Why if in the CB we had the outter handle would the FETCH give you the 
attributes of the Inner handle??

 

Just a silly question?

 

Cheers

 

 

 

> Date: Fri, 31 Jan 2014 17:00:20 +
> From: martin.ev...@easysoft.com
> To: tim.bu...@pobox.com; byter...@hotmail.com
> CC: hhferre...@gmail.com; boh...@ntlworld.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> 
> On 31/01/14 16:21, Tim Bunce wrote:
> > On Fri, Jan 31, 2014 at 09:11:28AM -0500, John Scoles wrote:
> >> A final note on this.
> >>
> >> Seems there was a very very long unknown bug in DBI which was only fix a 
> >> few days ago wiht DB 1.6.31
> >
> > If you mean Callbacks getting an inner handle, that wasn't a bug as such.
> > More like a design choice that proved non-optimal.
> >
> >> [1]http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
> >
> > That's 
> > http://blogs.perl.org/users/byterock/2014/01/callbacks-ate-my-brain.html
> > I presume.
> >
> >> The end result of this bug was that when callbacks are used on the
> >> statement handle some attributes will not be there so you
> >> programmer who did this
> >>
> >> $sth->FETCH( 'ParamValues' ), # WTF? - returns a reference to an array of 
> >> hashes
> >>
> >> was most likely complaing that the
> >>
> >> $sth->{ParamValues},
> >>
> >> should return a ref but was just returning undef.
> >>
> >> So he 'Kludged' the code to get the value directly with the FETCH which 
> >> works
> >
> > I'm not sure what you're saying here John. Using $sth->FETCH('ParamValues')
> > is perfectly reasonable. It was required before 1.631 and optional with
> > 1.631+ now that $h->{ParamValues} works.
> >
> >> sort of, but it does bleed memory every so slighly.
> >
> > Are you sure? This is the first I've heard of such a leak.
> >
> > Tim.
> 
> I've found no evidence of a memory leak with a simple test calling 
> ParamValues a lot with some parameters. However, I'm not using 
> ORA_VARCHAR2_TABLE. The code is:
> 
> else if (kl==11 && strEQ(key, "ParamValues")) {
> HV *pvhv = newHV();
> if (imp_sth->all_params_hv) {
> SV *sv;
> char *key;
> I32 keylen;
> hv_iterinit(imp_sth->all_params_hv);
> while ( (sv = hv_iternextsv(imp_sth->all_params_hv, &key, &keylen)) ) {
> phs_t *phs = (phs_t*)(void*)SvPVX(sv); /* placeholder struct */
> (void)hv_store(pvhv, key, keylen, newSVsv(phs->sv), 0);
> }
> }
> retsv = newRV_noinc((SV*)pvhv);
> cacheit = FALSE;
> 
> }
> 
> which looks sane to me right now. ORA_VARCHAR2_TABLE seems to do strange 
> things with parameters I don't quite get right now.
> 
> As I said previously to Hélder and John (some of the discussion was off 
> dbi-users list presumably because it contained log data), although I accept 
> taking the call to ParamValues out has on this occasion made the problem go 
> away I don't understand why. I think there is more to this than it so far 
> looks but without a way of reproducing it myself I won't be spending any more 
> time on it. If it is reproducible in a standalone script I will happily look 
> again.
> 
> Martin
  

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

 A final note on this.

 

Seems there was a very very long unknown bug in DBI which was only fix a few 
days ago wiht DB 1.6.31

 

http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165

 

The end result of this bug was that when callbacks are used on the statement 
handle some attributes will not be there

so you programmer who did this

 

$sth->FETCH( 'ParamValues' ), # WTF? - returns a reference to an array of hashes

 

was most likely complaing that the 

 

$sth->{ParamValues}, 

 

should return a ref but was just returning undef.

 

So he 'Kludged' the code to get the value directly with the FETCH which works 
sort of, but it does bleed memory every so slighly.

 

The latest version of DBI with the 

 

$sth->{ParamValues}, 

 

Should solve all you problems

 

As a bonus I have another topic for me blog

 

Cheers

John



Date: Wed, 29 Jan 2014 14:21:28 +
Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
From: hhferre...@gmail.com
To: boh...@ntlworld.com
CC: byter...@hotmail.com


You are right Martin.. Shame on me :( 


At the time you suggested that we did not know about the callbacks, sorry for 
that, our fault :(á


Now that we know the root of the problem I'm sure we will be able to implement 
a solution.á
Thanks a lot for your time, tips and patience :)


I would be more than pleased to offer you a ginginha, porto /portuguese wine 
accompanied by a special local cheese or a "portuguese egg tart" case you pass 
by here!


Best Regards,
HÚlder Hugo Ferreira





On Wed, Jan 29, 2014 at 12:04 PM, Martin J. Evans  wrote:


On 29/01/14 11:02, hhferreira wrote:

Hey Guys!

John, your tip about the callbacks revealed to be very accurate!!

I seem to remember saying a long time back in this thread: 


"Have you got some sort of execute callback? I ask because of the following in 
the trace:


á á {{ execute callback CODE(0xb832be8) being invoked


and it is only present before the error."

hmmm.
á


We managed to isolate the issue into this statement:

á debug( "Executing SQL on OptiDb database:",
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
ásql_executer á á á á => sprintf( "%s line %s (%s)", (caller(0))[1,2], 
$sth->{private_keep_alive_seconds} ? 'active: keeping connection open' : 
'maintenance' ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
ástatement á á á á á á=> $sth->{Statement},
*params á á á á á á á => $sth->FETCH( 'ParamValues' ), # WTF? - returns a 
reference to an array of hashes* 

á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
áconnected_since á á á=> sprintf( "%s (%.3f seconds)",
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á á ástrftime( "%H:%M:%S", localtime( 
$dbh->{private_connected_at_timestamp}[0] ) ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á á átv_interval( $dbh->{private_connected_at_timestamp} ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á á á),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
ákeep_alive_timestamp => $dbh->{private_keep_alive_until_timestamp}
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á? sprintf( "%s (%s seconds to live)",
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á á á á á á ástrftime( "%H:%M:%S", localtime( 
$dbh->{private_keep_alive_until_timestamp} ) ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á á á á á á á( $dbh->{private_keep_alive_until_timestamp} - 
time() ),
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á á á á á á á)
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á 
á á á á á á á á á á á: '',
á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á á);

I guess the former developer added that suggestive comment for a reason :)

Now we don't really now how to resolve this issue here because this debug 
function cannot simply be removed as it logs into a file very important data 
required in case we need to track down business issues. I suppose the problem 
here is that the ora_varchar2_table parameters are themselves arrays and when 
they reach a certain size it crashes.

Any tip to replace this $sth->FETCH('ParamValues') statement into a workable 
one? Maybe reduce the number of items in each of the inner arrays to 100 or so 
could be a solution... We will try to investigate in this direction. If you 
have some sort of magic that could share we would be very appreciated :)

P.S. If you ever come to Portugal let us know and we will be very pleased to go 
out with you for a beer or two!

Best Regards,
HÚlder Hugo Ferreira



All the FETCH doe

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

Looking at the code changes I was mistaken that this has anyting to do with the 
native_execute aray.  My Bad on that.

That code had been around for a very long time well before 2005.

 

As the value changes I would think there is some memory leak somplace that is 
corrupting the the 'all_params_hv' deep inside the 'c' struct?

 

cheers



Date: Fri, 24 Jan 2014 15:34:44 +
Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
From: hhferre...@gmail.com
To: boh...@ntlworld.com
CC: martin.ev...@easysoft.com; byter...@hotmail.com; dbi-users@perl.org


Theá3443804ávalue is the one we get most of the times but distinct values were 
already seen and were also big number which make no sense... Do you know if 
this function has been changed since DBD version 1.21?á



All points out to be a memory leak I guess...


Thanks!
HÚlder



On Fri, Jan 24, 2014 at 3:21 PM, Martin J. Evans  wrote:


On 24/01/14 14:59, hhferreira wrote:

Hi Guys,

We have made the dump of the contents of /$sth->{ParamValues} /into the 
attached file which basically contains all values set for the 6 input binds 
(ora_varchar2_table elements actually).

Looks good to me. wc -l on the file shows 9389 and / 6 = ~ 1564

I cannot as yet explain why dbdxst_bind_params thinks there are 3443804 
parameters.

Even in hex 3443804 is 348c5c so it doesn't look like an overflow.

The code reporting the issue is as follows:

static int
dbdxst_bind_params(SV *sth, imp_sth_t *imp_sth, I32 items, I32 ax)
{
á á /* Handle binding supplied values to placeholders. á á á á á*/
á á /* items = one greater than the number of params á á á á á á*/
á á /* ax = ax from calling sub, maybe adjusted to match items á*/
á á dTHX;
á á int i;
á á SV *idx;
á á if (items-1 != DBIc_NUM_PARAMS(imp_sth)
á á á á && DBIc_NUM_PARAMS(imp_sth) != DBIc_NUM_PARAMS_AT_EXECUTE
á á ) {
á á á á char errmsg[99];
á á á á /* clear any previous ParamValues before error is generated */
á á á á SV **svp = hv_fetch((HV*)DBIc_MY_H(imp_sth),"ParamValues",11,FALSE);
á á á á if (svp && SvROK(*svp) && SvTYPE(SvRV(*svp)) == SVt_PVHV) {
á á á á á á HV *hv = (HV*)SvRV(*svp);
á á á á á á hv_clear(hv);
á á á á }
á á á á sprintf(errmsg,"called with %d bind variables when %d are needed",
á á á á á á á á (int)items-1, DBIc_NUM_PARAMS(imp_sth));
á á á á DBIh_SET_ERR_CHAR(sth, (imp_xxh_t*)imp_sth, "-1", -1, errmsg, Nullch, 
Nullch);
á á á á return 0;
á á }

and I don't particularly like that casting but I don't think it explains the 
problem.

Martin



We will proceed with the test environment setup using the latest perl and 
module versions, Martin mentioned this could be done without actually 
installing (overwriting) our existing versions, I suppose you are referring to 
those environment variables such like PERL5LIB which we can tweak to use the 
right versions right? Or there is a better approach? Our working environment is 
rather complex (big company overweight) and that task can take a while although 
seems simple to perform so if there is a simple way do let us know :-)

Thanks for your hints!

Best Regards,
HÚlder Hugo Ferreira





On Fri, Jan 24, 2014 at 1:28 PM, Martin J. Evans mailto:martin.ev...@easysoft.com>> wrote:

á á On 24/01/14 12:26, hhferreira wrote:

á á á á Hi,

á á á á We have already tried using ora_maxarray_numentries and other similar 
attributes unsuccessfully.

á á á á Martin found that immediately before the error the following message is 
written:
á á á á á á{{ execute callback CODE(0xb832be8) being invoked

á á á á However we have done a dbi_trace with 1000 elements in the arrays 
(which works!) to see whether a similar message is logged and it is, so I would 
not go into that direction though. Will setup a test environment using the 
latest DBD and DBI versions to see whether the leaks in DBD are causing this 
behavior.

á á á á Thanks.

á á á á Best Regards,
á á á á HÚlder Hugo Ferreira


á á The reason I pointed out the execute callback is that it is only called 
just before the failure and we cannot see from the trace what code is in it. If 
we cannot see the code who knows what it is doing?


á á 1 á -> FETCH for DBD::Oracle::st (DBI::st=HASH(0xd077218)~INNER 
'ParamValues') thr#8916008
á á 1 á <- FETCH= ( HASH(0xd0758e8)7keys ) [1 items] at /home/

á á Might have been interesting if we knew what was in it.

á á Perhaps you could get ParamValues just before execute and if execute fails 
catch it and Dumper them.

á á use Data::Dumper;
á á .
á á .
á á my $pv = $sth->{ParamValues};
á á eval {
á á á á á á á$sth->execute;
á á };
á á if (my $ev = $@) {
á á á á á á áprint Dumper($pv);
á á á á á á ádie $ev;
á á }

á á However, I still think testing the latest DBI/DBD::Oracle is the best thing 
to do first.

á á Martin




á á á á On Fri, Jan 24, 2014 at 12:09 PM, John Scoles mailto:byter...@hotmail.com> <mailto:byter...@hotmail.c

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

Hmm  

 

DBIc_NUM_PARAMS  would be the same as (int)HvKEYS(imp_sth->all_params_hv)

 

so it is couning the keys on the 'all_params_hv'  which is just a HV??

 

would have to put some debugging around it but all  'dbdxst_'  would be in the 
compiled Oracle.c code 

not the DBD::Code??

 

Odd.  Cross comple maybe or bug in the Oracle binarys??
 

> Date: Fri, 24 Jan 2014 15:21:47 +
> From: boh...@ntlworld.com
> To: hhferre...@gmail.com; martin.ev...@easysoft.com
> CC: byter...@hotmail.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> 
> On 24/01/14 14:59, hhferreira wrote:
> > Hi Guys,
> >
> > We have made the dump of the contents of /$sth->{ParamValues} /into the 
> > attached file which basically contains all values set for the 6 input binds 
> > (ora_varchar2_table elements actually).
> 
> Looks good to me. wc -l on the file shows 9389 and / 6 = ~ 1564
> 
> I cannot as yet explain why dbdxst_bind_params thinks there are 3443804 
> parameters.
> 
> Even in hex 3443804 is 348c5c so it doesn't look like an overflow.
> 
> The code reporting the issue is as follows:
> 
> static int
> dbdxst_bind_params(SV *sth, imp_sth_t *imp_sth, I32 items, I32 ax)
> {
> /* Handle binding supplied values to placeholders. */
> /* items = one greater than the number of params */
> /* ax = ax from calling sub, maybe adjusted to match items */
> dTHX;
> int i;
> SV *idx;
> if (items-1 != DBIc_NUM_PARAMS(imp_sth)
> && DBIc_NUM_PARAMS(imp_sth) != DBIc_NUM_PARAMS_AT_EXECUTE
> ) {
> char errmsg[99];
> /* clear any previous ParamValues before error is generated */
> SV **svp = hv_fetch((HV*)DBIc_MY_H(imp_sth),"ParamValues",11,FALSE);
> if (svp && SvROK(*svp) && SvTYPE(SvRV(*svp)) == SVt_PVHV) {
> HV *hv = (HV*)SvRV(*svp);
> hv_clear(hv);
> }
> sprintf(errmsg,"called with %d bind variables when %d are needed",
> (int)items-1, DBIc_NUM_PARAMS(imp_sth));
> DBIh_SET_ERR_CHAR(sth, (imp_xxh_t*)imp_sth, "-1", -1, errmsg, Nullch, Nullch);
> return 0;
> }
> 
> and I don't particularly like that casting but I don't think it explains the 
> problem.
> 
> Martin
> 
> > We will proceed with the test environment setup using the latest perl and 
> > module versions, Martin mentioned this could be done without actually 
> > installing (overwriting) our existing versions, I suppose you are referring 
> > to those environment variables such like PERL5LIB which we can tweak to use 
> > the right versions right? Or there is a better approach? Our working 
> > environment is rather complex (big company overweight) and that task can 
> > take a while although seems simple to perform so if there is a simple way 
> > do let us know :-)
> >
> > Thanks for your hints!
> >
> > Best Regards,
> > Hélder Hugo Ferreira
> >
> >
> >
> > On Fri, Jan 24, 2014 at 1:28 PM, Martin J. Evans  > <mailto:martin.ev...@easysoft.com>> wrote:
> >
> > On 24/01/14 12:26, hhferreira wrote:
> >
> > Hi,
> >
> > We have already tried using ora_maxarray_numentries and other similar 
> > attributes unsuccessfully.
> >
> > Martin found that immediately before the error the following message is 
> > written:
> > {{ execute callback CODE(0xb832be8) being invoked
> >
> > However we have done a dbi_trace with 1000 elements in the arrays (which 
> > works!) to see whether a similar message is logged and it is, so I would 
> > not go into that direction though. Will setup a test environment using the 
> > latest DBD and DBI versions to see whether the leaks in DBD are causing 
> > this behavior.
> >
> > Thanks.
> >
> > Best Regards,
> > Hélder Hugo Ferreira
> >
> >
> > The reason I pointed out the execute callback is that it is only called 
> > just before the failure and we cannot see from the trace what code is in 
> > it. If we cannot see the code who knows what it is doing?
> >
> >
> > 1 -> FETCH for DBD::Oracle::st (DBI::st=HASH(0xd077218)~INNER 
> > 'ParamValues') thr#8916008
> > 1 <- FETCH= ( HASH(0xd0758e8)7keys ) [1 items] at /home/
> >
> > Might have been interesting if we knew what was in it.
> >
> > Perhaps you could get ParamValues just before execute and if execute fails 
> > catch it and Dumper them.
> >
> > use Data::Dumper;
> > .
> > .
> > my $pv = $sth->{ParamValues};
> > eval {
> > $sth->execute;
> > };
> > if (my $ev = $@) {
> > print Du

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

had a look at the data nothing poped out to me, such as a reserved word or 
hidden contol character (\t and \x or UTF8)

 

Does the same number (ie 3443804 ) in the error  

 

DB: DBD::Oracle::st execute failed: called with 3443804 bind variables when 7 
are needed [for Statement..."/

 come up each time or does it change??  I susspect this my just be the int 
value of the callback and it would change each time you run?

 

cheers

John



Date: Fri, 24 Jan 2014 14:59:25 +
Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
From: hhferre...@gmail.com
To: martin.ev...@easysoft.com
CC: byter...@hotmail.com; boh...@ntlworld.com; dbi-users@perl.org


Hi Guys, 


We have made the dump of the contents of $sth->{ParamValues} into the attached 
file which basically contains all values set for the 6 input binds 
(ora_varchar2_table elements actually).


We will proceed with the test environment setup using the latest perl and 
module versions, Martin mentioned this could be done without actually 
installing (overwriting) our existing versions, I suppose you are referring to 
those environment variables such like PERL5LIB which we can tweak to use the 
right versions right? Or there is a better approach? Our working environment is 
rather complex (big company overweight) and that task can take a while although 
seems simple to perform so if there is a simple way do let us know :-)



Thanks for your hints!


Best Regards,
Hélder Hugo Ferreira





On Fri, Jan 24, 2014 at 1:28 PM, Martin J. Evans  
wrote:


On 24/01/14 12:26, hhferreira wrote:

Hi,

We have already tried using ora_maxarray_numentries and other similar 
attributes unsuccessfully.

Martin found that immediately before the error the following message is written:
  {{ execute callback CODE(0xb832be8) being invoked

However we have done a dbi_trace with 1000 elements in the arrays (which 
works!) to see whether a similar message is logged and it is, so I would not go 
into that direction though. Will setup a test environment using the latest DBD 
and DBI versions to see whether the leaks in DBD are causing this behavior.

Thanks.

Best Regards,
Hélder Hugo Ferreira

The reason I pointed out the execute callback is that it is only called just 
before the failure and we cannot see from the trace what code is in it. If we 
cannot see the code who knows what it is doing? 


1   -> FETCH for DBD::Oracle::st (DBI::st=HASH(0xd077218)~INNER 'ParamValues') 
thr#8916008
1   <- FETCH= ( HASH(0xd0758e8)7keys ) [1 items] at /home/

Might have been interesting if we knew what was in it.

Perhaps you could get ParamValues just before execute and if execute fails 
catch it and Dumper them.

use Data::Dumper;
.
.
my $pv = $sth->{ParamValues};
eval {
$sth->execute;
};
if (my $ev = $@) {
print Dumper($pv);
die $ev;
}

However, I still think testing the latest DBI/DBD::Oracle is the best thing to 
do first.

Martin





On Fri, Jan 24, 2014 at 12:09 PM, John Scoles mailto:byter...@hotmail.com>> wrote:

As Martin said that is rather old version of DBD only 3 since native 
exe_array was introduced 1.18, and I rember there being some leaks in early 
version of the native exe_array.

If you can upgrade you DBD.

Yyou might try to set the 'ora_maxarray_numentries'  on you binds as well 
as that works on the Oracle side of things to limit memory.

As it runs stands alone as you say it might be that the things you are 
binnding are not being released by perl as a referace to them may still exist.

Cheers
John

 > Date: Fri, 24 Jan 2014 10:53:54 +
 > From: boh...@ntlworld.com <mailto:boh...@ntlworld.com>
 > To: hhferre...@gmail.com <mailto:hhferre...@gmail.com>; 
dbi-users@perl.org <mailto:dbi-users@perl.org> 


 > Subject: Re: Issues with DBI Oracle Input Array Binds 
(ORA_VARCHAR2_TABLE)

 >
 > On 24/01/14 10:29, hhferreira wrote:
 > > Hi Guys,
 > >
 > > Hope you can provide us some enlightenment!
 > >
 > > We have the following code which basically calls an oracle procedure 
passing as inputs 6 bind arrays (converted in ORA_VARCHAR2_TABLE elements) and 
one string:
 > >
 > > /my $sth = $self->prepare( q{/
 > > / begin pkg_abcdef.pr_setAbcdef(/
 > > / :in_sourceType,/
 > > / :in_sourceNames,/
 > > / :in_peerTypes,/
 > > / :in_peerNames,/
 > > / :in_writables,/
 > > / :in_requireLevels,/
 > > / :in_testdefs/
 > > / );/
 > > / end;/
 > > /} );/
 > > /
 > > /
 > > /$sth->bind_param( ':in_sourceType', $sourceType, /
 > > / { ora_type => ORA_VARCHAR2 } );/
 > > /$sth->bind_param( ':in_sourceNames', $sourceNames, /
 > > / { ora_type =&

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

I will try and have a quick look at it.

 

I would go with perlbrew http://perlbrew.pl/ as  you can have many differnt 
versions of the mods/perl and test them all at once.

 


 



Date: Fri, 24 Jan 2014 14:59:25 +
Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
From: hhferre...@gmail.com
To: martin.ev...@easysoft.com
CC: byter...@hotmail.com; boh...@ntlworld.com; dbi-users@perl.org


Hi Guys, 


We have made the dump of the contents of $sth->{ParamValues} into the attached 
file which basically contains all values set for the 6 input binds 
(ora_varchar2_table elements actually).


We will proceed with the test environment setup using the latest perl and 
module versions, Martin mentioned this could be done without actually 
installing (overwriting) our existing versions, I suppose you are referring to 
those environment variables such like PERL5LIB which we can tweak to use the 
right versions right? Or there is a better approach? Our working environment is 
rather complex (big company overweight) and that task can take a while although 
seems simple to perform so if there is a simple way do let us know :-)



Thanks for your hints!


Best Regards,
Hélder Hugo Ferreira





On Fri, Jan 24, 2014 at 1:28 PM, Martin J. Evans  
wrote:


On 24/01/14 12:26, hhferreira wrote:

Hi,

We have already tried using ora_maxarray_numentries and other similar 
attributes unsuccessfully.

Martin found that immediately before the error the following message is written:
  {{ execute callback CODE(0xb832be8) being invoked

However we have done a dbi_trace with 1000 elements in the arrays (which 
works!) to see whether a similar message is logged and it is, so I would not go 
into that direction though. Will setup a test environment using the latest DBD 
and DBI versions to see whether the leaks in DBD are causing this behavior.

Thanks.

Best Regards,
Hélder Hugo Ferreira

The reason I pointed out the execute callback is that it is only called just 
before the failure and we cannot see from the trace what code is in it. If we 
cannot see the code who knows what it is doing? 


1   -> FETCH for DBD::Oracle::st (DBI::st=HASH(0xd077218)~INNER 'ParamValues') 
thr#8916008
1   <- FETCH= ( HASH(0xd0758e8)7keys ) [1 items] at /home/

Might have been interesting if we knew what was in it.

Perhaps you could get ParamValues just before execute and if execute fails 
catch it and Dumper them.

use Data::Dumper;
.
.
my $pv = $sth->{ParamValues};
eval {
$sth->execute;
};
if (my $ev = $@) {
print Dumper($pv);
die $ev;
}

However, I still think testing the latest DBI/DBD::Oracle is the best thing to 
do first.

Martin





On Fri, Jan 24, 2014 at 12:09 PM, John Scoles mailto:byter...@hotmail.com>> wrote:

As Martin said that is rather old version of DBD only 3 since native 
exe_array was introduced 1.18, and I rember there being some leaks in early 
version of the native exe_array.

If you can upgrade you DBD.

Yyou might try to set the 'ora_maxarray_numentries'  on you binds as well 
as that works on the Oracle side of things to limit memory.

As it runs stands alone as you say it might be that the things you are 
binnding are not being released by perl as a referace to them may still exist.

Cheers
John

 > Date: Fri, 24 Jan 2014 10:53:54 +
 > From: boh...@ntlworld.com <mailto:boh...@ntlworld.com>
 > To: hhferre...@gmail.com <mailto:hhferre...@gmail.com>; 
dbi-users@perl.org <mailto:dbi-users@perl.org> 


 > Subject: Re: Issues with DBI Oracle Input Array Binds 
(ORA_VARCHAR2_TABLE)

 >
 > On 24/01/14 10:29, hhferreira wrote:
 > > Hi Guys,
 > >
 > > Hope you can provide us some enlightenment!
 > >
 > > We have the following code which basically calls an oracle procedure 
passing as inputs 6 bind arrays (converted in ORA_VARCHAR2_TABLE elements) and 
one string:
 > >
 > > /my $sth = $self->prepare( q{/
 > > / begin pkg_abcdef.pr_setAbcdef(/
 > > / :in_sourceType,/
 > > / :in_sourceNames,/
 > > / :in_peerTypes,/
 > > / :in_peerNames,/
 > > / :in_writables,/
 > > / :in_requireLevels,/
 > > / :in_testdefs/
 > > / );/
 > > / end;/
 > > /} );/
 > > /
 > > /
 > > /$sth->bind_param( ':in_sourceType', $sourceType, /
 > > / { ora_type => ORA_VARCHAR2 } );/
 > > /$sth->bind_param( ':in_sourceNames', $sourceNames, /
 > > / { ora_type => ORA_VARCHAR2_TABLE } );/
 > > /$sth->bind_param( ':in_peerTypes', $peerTypes, /
 > > / { ora_type => ORA_VARCHAR2_TABLE } );/
 > > /$sth->bind_param( ':in_peerNames', $peerNames, /
 > >

RE: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)

[John Scoles]

As Martin said that is rather old version of DBD only 3 since native exe_array 
was introduced 1.18, and I rember there being some leaks in early version of 
the native exe_array.

 

If you can upgrade you DBD.

 

Yyou might try to set the 'ora_maxarray_numentries'  on you binds as well as 
that works on the Oracle side of things to limit memory.

 

As it runs stands alone as you say it might be that the things you are binnding 
are not being released by perl as a referace to them may still exist.

 

Cheers

John

 

> Date: Fri, 24 Jan 2014 10:53:54 +
> From: boh...@ntlworld.com
> To: hhferre...@gmail.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> 
> On 24/01/14 10:29, hhferreira wrote:
> > Hi Guys,
> >
> > Hope you can provide us some enlightenment!
> >
> > We have the following code which basically calls an oracle procedure 
> > passing as inputs 6 bind arrays (converted in ORA_VARCHAR2_TABLE elements) 
> > and one string:
> >
> > /my $sth = $self->prepare( q{/
> > / begin pkg_abcdef.pr_setAbcdef(/
> > / :in_sourceType,/
> > / :in_sourceNames,/
> > / :in_peerTypes,/
> > / :in_peerNames,/
> > / :in_writables,/
> > / :in_requireLevels,/
> > / :in_testdefs/
> > / );/
> > / end;/
> > /} );/
> > /
> > /
> > /$sth->bind_param( ':in_sourceType', $sourceType, /
> > / { ora_type => ORA_VARCHAR2 } );/
> > /$sth->bind_param( ':in_sourceNames', $sourceNames, /
> > / { ora_type => ORA_VARCHAR2_TABLE } );/
> > /$sth->bind_param( ':in_peerTypes', $peerTypes, /
> > / { ora_type => ORA_VARCHAR2_TABLE } );/
> > /$sth->bind_param( ':in_peerNames', $peerNames, /
> > / { ora_type => ORA_VARCHAR2_TABLE } );/
> > /$sth->bind_param( ':in_writables', $writables, /
> > / { ora_type => ORA_VARCHAR2_TABLE } );/
> > /$sth->bind_param( ':in_requireLevels', $requireLevels, /
> > / { ora_type => ORA_VARCHAR2_TABLE } );/
> > /$sth->bind_param( ':in_testdefs', $testDefs, /
> > / { ora_type => ORA_VARCHAR2_TABLE } );/
> > /
> > /
> > /$sth->execute();/
> >
> >
> > The problem is that if we have around 1000 elements per array the call 
> > works beautifully, but with for instance 1500 it raises an exception, 
> > namely an invalid number of bind elements!
> >
> > /19:05:57 ERROR: Caught an exception from DB: DBD::Oracle::st execute 
> > failed: called with 3443804 bind variables when 7 are needed [for 
> > Statement..."/
> > /
> > /
> >
> > Here is the output of dbi_Trace=15:
> >
> 
> 
> As I answered in perlmonks, that log didn't give me enough info. Perhaps you 
> could send me personally all the log.
> 
> > PERL version: 5.12.1
> > DBI version: 1.611
> > DBD::Oracle: 1.21
> 
> That version of DBD::Oracle is very old - 11th April 2008.
> 
> On the other hand your DBI is 19th April 2010.
> 
> I'd rather not debug the issue on versions so old. Is it at all possible you 
> can try the latest versions so we can at least see if the problem is already 
> fixed? You can do this without actually installing (overwriting) your 
> existing versions (ask if you are unsure how to do this).
> 
> 
> > We have made a standalone script and it works perfectly even with 2 
> > entries per array. In our application we are using perl objects all over 
> > the code, can this be a memory leak somewhere else in the code?!
> 
> Shame, as this would definitely be the best way to go. It would be worth 
> putting a bit more effort into this.
> 
> > Any help would be highly appreciated!
> >
> > Thanks in advance.
> >
> > Best Regards,
> > Hélder Hugo Ferreira
> >
> 
> Martin
  

RE: Failed DBD oracle module

[John Scoles]

No time to look at it today but these two sites might help

 

http://coding.derkeiler.com/Archive/Perl/perl.dbi.users/2006-12/msg00029.html 

 

or

 

http://www.pythian.com/blog/fixing-the-dreaded-unable-to-locate-an-oracle-mk-proc-mk-or-other-suitable-mk-error-in-dbdoracle-insalls/
 

> From: john...@pharmacy.arizona.edu
> CC: dbi-users@perl.org
> Subject: Re: Failed DBD oracle module
> Date: Mon, 23 Sep 2013 21:09:34 +
> 
> 
> On Sep 23, 2013, at 2:02 PM, Bruce Johnson  
> wrote:
> 
> > This can happen if you have 32-bit oracle db installed on the system, but 
> > use the 64-bit Oracle Instant Client to compile DBD::Oracle. 
> 
> Or Vice-versa, of course, which might be what your problem is.
> 
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs
> 
> 
  

RE: "connect" not connecting

[John Scoles]

 Hmm??
 
DBI just does not 'stop' working from one day to another.
 
What I suspect has happened is one of the following
 
1) Some-one have change the DSN on your DB
2) Some-one has changed permissions on the DB file 
3) As you are not getting an error you might be connected but your DB file is 
gone or you have no permission on them
 
Find out who changed something on you 
 
Cheers
John 
To: db...@comcast.net; dbi-users@perl.org
Date: Fri, 28 Jun 2013 13:44:17 -0400
Subject: RE: "connect" not connecting
From: eric.b...@barclays.com

DBI->trace(…) might help. You should also review the docs on the use of errstr. 
 You should be using $DBI::errstr, not DBI->errstr to the best of my knowledge 
and according to the docs. Eric D. BergIPRS Infrastructure  From: 
dbenti...@gmail.com [mailto:dbenti...@gmail.com] On Behalf Of Dan Bent
Sent: Wednesday, June 26, 2013 4:15 AM
To: dbi-users@perl.org
Subject: "connect" not connecting I have been using DBI for several years, and 
have a fairly extensive group of programs that relay on DBI to connect to a 
database and extract data. All my programs use a common library of functions 
that includes a function which connects to the database: $dsn =  
'dbi:ODBC:prod1' ;$user =  'user' ;$passwd =  '' ;$dbh = 
DBI->connect($dsn, $user, $passwd,
{RaiseError => 1, AutoCommit => 0})
or die "Could not connect to database: " . DBI->errstr ; This has 
worked for years, but yesterday, it suddenly stopped working. Now my programs 
get to this function, and stop. No error messages are generated, and the 
database logs do not show a connection attempt, failed or otherwise. The 
database itself is an odd thing that I don't expect folks to be familiar with. 
We use Relativity, which allows CISAM flat files to be used like a relational 
database. There have not been recent changes to Relativity, and I can see that 
other (non-Perl) applications are accessing the database without any issues. So 
the problem seems to be isolated to Perl programs attempting to connect to this 
database. I am not sure what to do to gather more information about this issue. 
I wrote s test program to isolate the DBI->connect method, and gather 
information. I am able to list the available drivers: Proxy, Sponge, DBM, 
ExampleP, File, ODBC, but I'm not sure what else I can do. I would appreciate 
any suggestions about how to gather more information or resolve this issue.
___

This message is for information purposes only, it is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is not intended for retail customer use. Intended for 
recipient only. This message is subject to the terms at: 
www.barclays.com/emaildisclaimer.

For important disclosures, please see: 
www.barclays.com/salesandtradingdisclaimer 
regarding market commentary from Barclays Sales and/or Trading, who are active 
market participants; and in respect of Barclays Research, including disclosures 
relating to specific issuers, please see http://publicresearch.barclays.com.

___
  

RE: cross database queries?

[John Scoles]

 
> Date: Wed, 26 Jun 2013 08:26:36 -0400
> From: a...@dancingjars.com
> To: dbi-users@perl.org
> Subject: cross database queries?
> 
> I want to write a query like:
> 
> select clients.client.client_id, columnar.sales.total_sales, 
> web.page_hits from clients, columnar, web
> where clients.client_id = columnar.client_id
> and  clients.client_id = web.client_id
> 
> in a system where 'clients' is actually one or more relational 
> databases, 'columnar' is one or columnar databases, and 'web' is the 
> Apache logs on one or more web servers.  The dbi driver would be 
> configured to connect to the correct databases and filter web hits based 
> on 'client_id'.
> 
> Has somebody written that already?
>  Yes but it depends largely on what  DB you are hitting against.  Really has 
> nothing to do with DBI. The above query would work perfectly fine in oracle 
> as long as the connection user has permission on all the schema.  Now if you 
> are asking if the above will work across one or more DBDs and different 
> Databases (oracle, files MySQL) then the answer is no. There are drivers out 
> there for example that let Oracle hit LDAP tables and do joins but that is 
> part of the Oracle DB not DBI and DBD.  DBI does not do the join it is the DB 
> that does that. DBI only issues the command Cheers John
> Thanks,
> Andrew
> 
  

RE: (Fwd) Quick Perl Questions - DBI and DBD

[John Scoles]

It should just work as long as you did not change your Oracle client. 
 
Most of the time Oracle clients are compatible two forward and two back. 
 
> Date: Mon, 10 Jun 2013 17:54:59 +0100
> From: tim.bu...@pobox.com
> To: dbi-users@perl.org
> CC: douglas.e.prin...@citi.com
> Subject: (Fwd) Quick Perl Questions - DBI and DBD
> 
> - Forwarded message from "Prindle, Douglas E " 
>  -
> 
> Date: Mon, 10 Jun 2013 15:11:26 +
> From: "Prindle, Douglas E " 
> To: "tim.bu...@pobox.com" 
> Subject: Quick Perl Questions - DBI and DBD
> 
>Hi Tim.
> 
> 
>I have emailed you before.
> 
>Just had a quick question for you being Perl expert you are.
> 
> 
>We are going from Oracle 10 to Oracle 11.
> 
>I recompiled our modules last year we are using version DBI-1.53 and 
> DBD-Oracle-1.19 they have worked
>fine with Oracle 10. No issues.
> 
> 
>Can I just continue to use them with Oracle 11 or would a recompile be 
> necessary ?
> 
> 
> 
>Thank You,
>Douglas E. Prindle | Credit Decisioning Systems | Apollo Infrastructure
>((904) 954-2472 |  6(904) 954-6305 |  *  [1]douglas.e.prin...@citi.com
> 
> 
> - End forwarded message -
  

RE: DBD installtion 11G R2 (64Bit) & 32 bit perl version

[John Scoles]

 That will be a bit of a problem and a bugger to fix.
 
I can only offer a general solution as each case is different but the short 
answer is yes you can run 32bit perl and 64 bit oracle together.
 
1) you have to get the 32bit oracle instant client for the version of oracle 
you want to use
2) that 32 bit client has to work on the 32 bit platform (test this with the 
sqlplus that come with it)
3) you will have to recompile reinstall your DBD for the 32 bit instanctclient 
with 'make'  
4) when you run your perl make sure it uses the ORACLE_HOME of the 32 bit 
instant client
 
cheers
John
 
 
From: anoop.ku...@nawras.om
To: dbi-users@perl.org
CC: go...@bildbasen.kiruna.se; jlip...@coefmd3.uswc.uswest.com; 
z50...@mip.lasc.lockheed.com; verb...@be.oracle.com; mou...@hometown.com; 
stephen.zan...@mckesson.com; earle.niet...@es.unisys.com; 
desca...@hermetica.com; carl...@tis.llnl.gov; d...@fndapl.fnal.gov; 
asloo...@alfabank.ru; t...@cpan.org; byter...@cpan.org; yan...@cpan.org; 
mjev...@cpan.org
Subject: RE: DBD installtion 11G R2 (64Bit) & 32 bit perl version
Date: Thu, 23 May 2013 14:03:09 +








Hi Support,
 
Please help me to solve this..

LD_RUN_PATH="/u01/app/oracle/product/11.2.0/dbhome_1/lib:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib"
 ld  -bhalt:4 -G -bI:/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE/perl.exp 
-bE:Oracle.exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib Oracle.o  dbdimp.o 
 oci8.o /lib/crt0_64.o  -o blib/arch/auto/DBD/Oracle/Oracle.so   
-L/u01/app/oracle/product/11.2.0/dbhome_1/lib/ -lclntsh -lld -lm -ldl -lc -lm 
-lpthreads -lodm -lbsd_r -lld -lperfstat -lm -lpthreads 

ld: 0711-736 ERROR: Input file /lib/crt0_64.o:
XCOFF64 object files are not allowed in 32-bit mode.
make: 1254-004 The error code from the last command is 8.
 
 
Stop.
 
 
After researching I could find this ,, But issue is that with 11gR2 onwards 
lib32 is not installing by default so need to install and configure seperatly 
its very difficuilt task for DBA..
 
Is DBD 64bit is available??
 
The problem looks like Perl and DBI run in 32-bit mode, but Oracle 9i
installs
as
64-bit.  (Oracle 8 installed as 32-bit.)  I saved the following email
with the
solution
in my bag of tricks.  This message was for Solaris, which is what I am
using.
A
week or so ago, it also worked for hpux.  Hopefully it will work for you
on
AIX.
=
Our solution: 
afer Makefile.PL creates the makefile, edit it in vi.
Replace '911/lib' with '911/lib32' everywhere
Replace 'rdbms/lib' with 'rdbms/lib32' everywhere.
Then do your make.
To really fix this will take someone who knows Makefile.PL to apply a
patch
detect the 64bit version of Oracle9i(the presense of lib32's is a tip
off).
In the mean time we applied a quick script to do it in our

install/distribution scripts.

 
 
 





 


 


 





 


From: Anoop Kumar Paramesweran


Sent: Thursday, May 23, 2013 4:25 PM

To: 'dbi-users@perl.org'

Subject: DBD error


 
Hi Support,
 
I am receiving following error while installing DBD Perl module on IBM AIX 7.1 
.Please help me to solve this..
 
bash-3.2# perl Makefile.PL 
Using DBI 1.625 (for perl 5.010001 on aix-thread-multi) installed in 
/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/
 
Configuring DBD::Oracle for perl 5.010001 on aix (aix-thread-multi)
 
Remember to actually *READ* the README file! Especially if you have any 
problems.
 
Installing on a aix, Ver#5.3
Using Oracle in /u01/app/oracle/product/11.2.0/dbhome_1
DEFINE _SQLPLUS_RELEASE = "1102000300" (CHAR)
Oracle version 11.2.0.3 (11.2)
Found /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk
Using /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk
Your LIBPATH env var is set to '/u01/app/oracle/product/11.2.0/dbhome_1/lib'
Reading /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk
Reading /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/env_rdbms.mk
Deleting -b64 from COMPOBJS because -b64 doesn't exist.
WARNING: Oracle /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ins_rdbms.mk 
doesn't define a 'build' rule.
 
WARNING: I will now try to guess how to build and link DBD::Oracle for you.
 This kind of guess work is very error prone and Oracle-version 
sensitive.
 It is possible that it won't be supported in future versions of 
DBD::Oracle.
 *PLEASE* notify dbi-users about exactly _why_ you had to build it this 
way.
 
Found header files in /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public.
 
client_version=11.2
 
 
DEFINE= -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 
-DORA_OCI_112
 
 
Checking for functioning wait.ph
 
 
System: perl5.010001 aix dennis01 3 5 00c72e9a4c00 
Compiler:   xlc_r -q32 -O -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE 
-qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT 
-qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong
Linker: /

RE: Trouble installing DBD::Oracle in OS X 10.8 ; Oracle 32 bit drivers the issue?

[John Scoles]

 > From: john...@pharmacy.arizona.edu
> Subject: Trouble installing DBD::Oracle in OS X 10.8 ; Oracle 32 bit drivers 
> the issue?
> Date: Mon, 17 Dec 2012 10:15:04 -0700
> To: dbi-users@perl.org
> 
> So I think I've found the bad news part of my recent update 10 OS X 10.8…
> 
> DBI installed just fine, went to install DBD::Oracle and at first it failed 
> entirely because it couldn't ID the Pracle version; then I discovered that 
> the 64-bit Instant Client does not work in 10.7 or 10.8 :
> 
> 
>  
> 
> Switch to 32-bit client, sqlplus runs ok, and the install of DBD::Oracle 
> starts auspiciously:
> 
>  CPAN.pm: Going to build P/PY/PYTHIAN/DBD-Oracle-1.52.tar.gz
> 
> Using DBI 1.622 (for perl 5.012004 on darwin-thread-multi-2level) installed 
> in /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/auto/DBI/
> 
> Configuring DBD::Oracle for perl 5.012004 on darwin 
> (darwin-thread-multi-2level)
> 
> Remember to actually *READ* the README file! Especially if you have any 
> problems.
> 
> Installing on a darwin, Ver#12.2
> Using Oracle in /oracle32
> DEFINE _SQLPLUS_RELEASE = "1002000400" (CHAR)
> Oracle version 10.2.0.4 (10.2)
> Looks like an Instant Client installation, okay
> Your DYLD_LIBRARY_PATH env var is set to '/oracle32'
> Oracle sysliblist: 
> Found header files in /oracle32/sdk/include.
> 
> client_version=10.2
> 
> 
> DEFINE= -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\"10.2.0.4\" 
> -DORA_OCI_102
> 
> 
> Checking for functioning wait.ph
> 
> 
> System: perl5.012004 darwin dbdev2.pharmacy.arizona.edu 12.2.0 darwin kernel 
> version 12.2.0: sat aug 25 00:48:52 pdt 2012; 
> root:xnu-2050.18.24~1release_x86_64 x86_64 
> Compiler:   /usr/bin/clang -O3 -O2  -fno-common -DPERL_DARWIN 
> -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe 
> -fstack-protector -I/opt/local/include
> Linker: /usr/bin/ld
> Sysliblist: 
> Linking with -lclntsh.
> 
> Checking if your kit is complete...
> Looks good
> LD_RUN_PATH=/oracle32
> Using DBD::Oracle 1.52.
> Using DBD::Oracle 1.52.
> Using DBI 1.622 (for perl 5.012004 on darwin-thread-multi-2level) installed 
> in /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/auto/DBI/
> Writing Makefile for DBD::Oracle
> 
> ***  If you have problems...
>  read all the log printed above, and the README and README.help.txt files.
>  (Of course, you have read README by now anyway, haven't you?)
> 
> 
> Then comes an endless line of errors like:
> 
> /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level/auto/DBI/Driver_xst.h:31:6:
>  warning: 
>   explicitly assigning a variable of type 'void *' to itself 
> [-Wself-assign]
> xxx = xxx; /* avoid unused var warning */
> ~~~ ^ ~~~
> ./Oracle.xsi:626:15: warning: explicitly assigning a variable of type 'I32'
>   (aka 'int') to itself [-Wself-assign]
> if (0) ix = ix; /* avoid unused variable warning */
>~~ ^ ~~
> ./Oracle.xsi:647:19: warning: explicitly assigning a variable of type 'I32'
>   (aka 'int') to itself [-Wself-assign]
> if (0) ix = ix; /* avoid unused variable warning */
>~~ ^ ~~
> ./Oracle.xsi:734:15: warning: explicitly assigning a variable of type 'I32'
>   (aka 'int') to itself [-Wself-assign]
> if (0) ix = ix; /* avoid unused variable warning */
>~~ ^ ~~
> Oracle.xs:311:150: warning: expression result unused [-Wunused-value]
>   ...OCIAttrSet_log_stat(imp_dbh, (dvoid*)admhp, (ub4)OCI_HTYPE_ADMIN, 
> (dvoid*)str, (ub4)svp_len, (ub4)OCI_ATTR_ADMIN_PFILE, 
> (OCIError*)imp_dbh->errhp, status)...
>  
> ~~~^~~
> ./ocitrace.h:325:26: note: expanded from macro 'OCIAttrSet_log_stat'
> oci_status_name(stat)),stat : stat
>^
> Oracle.xs:313:85: warning: expression result unused [-Wunused-value]
>   ...OCIDBStartup_log_stat(imp_dbh, imp_dbh->svchp, imp_dbh->errhp, admhp, 
> mode, flags, status)...
>  
> ~~~^~~
> ./ocitrace.h:587:26: note: expanded from macro 'OCIDBStartup_log_stat'
> oci_status_name(stat)),stat : stat
> 
> 
> Then
> 
> t/00versions.t  Can't load 
> '/Users/johnson/.cpan/build/DBD-Oracle-1.52-1xhbkg/blib/arch/auto/DBD/Oracle/Oracle.bundle'
>  for module DBD::Oracle: 
> dlopen(/Users/johnson/.cpan/build/DBD-Oracle-1.52-1xhbkg/blib/arch/auto/DBD/Oracle/Oracle.bundle,
>  2): Library not loaded: /b/227/rdbms/lib/libclntsh.dylib.10.1
>   Referenced from: 
> /Users/johnson/.cpan/build/DBD-Oracle-1.52-1xhbkg/blib/arch/auto/DBD/Oracle/Oracle.bundle
>   Reason: no suitable image found.  Did find:
>   /oracle32/libclntsh.dylib.10.1: mach-o, but wrong ar

RE: Perl DBI Hangs while execute()

[John Scoles]

Well I would do something like 
 
select 1 from dual
 
rather thatn '*'
 
It sounds like your DB coonection string is not correct.
 
Cheers
 

 

> From: amaresh.poth...@gmail.com
> Date: Mon, 19 Nov 2012 16:59:09 +0530
> Subject: Perl DBI Hangs while execute()
> To: dbi-users@perl.org
> 
> Hi All,
> 
> I am using Perl DBI to connect Oracle Database.
> The query runs if type from 'sqlplus' manually but hangs when I use the
> sql inside the script.
> Getting following error,
> "DBD::Oracle::st execute failed: ORA-36871: (XSFTDSC01) Object %s cannot be
> used to define a column in a LIMITMAP. (DBD ERROR: OCIStmtExecute) [for
> Statement"
> 
> And If remove that original query and replace 'select * from dual' and
> execute the script,
> I get 'Segementation Fault'.
> 
> Please help me to solve this.
> Thanks
> 
> -- 
> Amaresh P
  

RE: DBD::Oracle Schema different than User question

[John Scoles]

> Date: Mon, 12 Nov 2012 19:04:56 +
> From: martin.ev...@easysoft.com
> To: dbi-users@perl.org
> CC: kevin.k...@gmail.com
> Subject: Fwd: DBD::Oracle Schema different than User question
>
> Hi Kevin,
>
> I've forwarded your email on to the dbi-users list. See
> http://dbi.perl.org and look at the support page. Sorry for top posting
> but my email client is having some sort of fit with your email. I don't
> have any issue with any well formed patch to set the schema but I'll
> wait to see what others say as personally I've never had to change it.
>
> Martin
>
>
>  Original Message 
> Subject: DBD::Oracle Schema different than User question
> Date: Mon, 12 Nov 2012 13:04:05 -0500
> From: Kevin L. Kane 
> To: Tim Bunce , Yanick Champoux ,
> "Martin J. Evans" 
>
> Hi all,
> I am running into a problem and was planning on modifying my local
> DBD::Oracle to add support for a "schema=" construct in the
> connect string. Specifically, I want to connect as user X but set
> current_schema to Y. 

Sounds like someone tried to creata a MySQL type DB schema on Oracle again;)

Anyway if you want to log in wiht 1 generic user then change the 'schema'  just 
issue
an sql something like this

exec sql execute immediate  ALTER SESSION SET CURRENT_SCHEM=sss



> Another solution i've toyed with is having a
> trigger that switches my schema when I log in but I need to do this
> for a lot of different schemas and I will always be the same user. It
> seems weird to me that support for this isn't included in DBD::Oracle
> currently.
>
> If I do this in a sane way are you at all interested in the patch? 

IF if you come up with a patch we will have a look at it.

> Am I just missing something and this functionality is already there? Or
> should this functionality not exist in the first place and why?
>

I don't think it should be there because what oracle thinks a schema is 
different thatn other DB??  
A schema to an Oracle DB is the set of all tables and other objects owned by a 
user account if I am not mistaken 
not the grouping of all the table under an app or alike

Anyway off the top of head I do not think there is a way with OCI to change the 
shcema without loging in again as there
 is only OCISession begin OCIlogin2 neither take any shcema params???


Cheers
John
> Thanks,
> Kevin
> --
> Kevin L. Kane
> kevin.kane at gmail.com
>
>
>
>
>
> 

RE: (Fwd) DBD::Oracle Continuous Query Notification

[John Scoles]

Yes it is possiable but it has not been programmed yet in DBD::Oracle.
 
So far it is on the list of things to do for DBD::Oracle and at the Last Yapc 
EU conferance the other Maintainers and I have penceled it in once we get FAN 
and TAF fully working.
 
 
Look for it by Christmass sometime.
 
Cheers
John Scoles
 

> Date: Tue, 28 Aug 2012 13:06:59 +0100
> From: tim.bu...@pobox.com
> To: dbi-users@perl.org
> CC: rune.hens...@trapezegroup.eu
> Subject: (Fwd) DBD::Oracle Continuous Query Notification
> 
> - Forwarded message from Rune Henssel  -
> 
> Date: Tue, 28 Aug 2012 13:03:08 +0200
> From: Rune Henssel 
> To: t...@cpan.org
> Subject: DBD::Oracle Continuous Query Notification
> 
> Hi Tim
> 
> I hope that you might be able to help me with a problem that I have.
> 
> I am part of a team developing an application that needs to be notified 
> whenever data is changed in
> certain tables in a Oracle database. I know that this is possible in .NET 
> using ODP.NET but is it also
> possible in Perl and if so how?
> 
> Yours
> Rune Henssel
> Systemdeveloper
> 
> Trapeze Group Europe A/S
> Hersted�stervej 27-29
> Bygning A
> DK-2620 Albertslund
> 
> www.trapezegroup.com
> r...@trapezegroup.eu
> 
> - End forwarded message -
  

RE: Problems installing DBI on AIX5

[John Scoles]

Last time is did it Dan, was a year or two ago and I has the same sort of 
problem, no xlc,  so I just used the recipe here

http://search.cpan.org/~pythian/DBD-Oracle-1.47_00/lib/DBD/Oracle/Troubleshooting/Aix.pod#Using_gcc_C_Compiler

should work for you.  Though you might have to install the 'C' compiler and get 
it working like I did.

Cheers
John

> Date: Fri, 3 Aug 2012 16:43:07 +0100
> From: martin.ev...@easysoft.com
> To: donrwalt...@gmail.com
> CC: dbi-users@perl.org
> Subject: Re: Problems installing DBI on AIX5
>
> On 03/08/12 16:34, Don Walters wrote:
> >> I don't have an AIX box turned on right now but xlc must support -c (it
> >> means compile but do not link). What does perl -V output? Do you really 
> >> have
> >> a full AIX compiler installed or is this one of those silly mini compilers.
> >
> >
> >
> > srvdfj239 / # perl -V
> > Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
> > Platform:
> > osname=aix, osvers=5.3.0.0, archname=aix-thread-multi-64all
> > uname='aix akash79 3 5 00011a85d600 '
> > config_args='-desr -Dinstallprefix=/usr/opt/perl5
> > -Dprefix=/usr/opt/perl5 -Dcc=xlc_r -Duseshrplib -Dusethreads'
> > hint=recommended, useposix=true, d_sigaction=define
> > usethreads=define use5005threads=undef useithreads=define
> > usemultiplicity=define
> > useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> > use64bitint=define use64bitall=define uselongdouble=undef
> > usemymalloc=n, bincompat5005=undef
> > Compiler:
> > cc='cc_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE
> > -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN
> > -DNEED_PTHREAD_INIT -q64 -DUSE_64_BIT_ALL -q64',
> > optimize='-O',
> > cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
> > -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT'
> > ccversion='9.0.0.2', gccversion='', gccosandvers=''
> > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
> > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
> > ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
> > lseeksize=8
> > alignbytes=8, prototype=define
> > Linker and Libraries:
> > ld='ld', ldflags ='-brtl -bdynamic -b64'
> > libpth=/lib /usr/lib /usr/ccs/lib
> > libs=-lbind -lnsl -lgdbm -ldbm -ldb -ldl -lld -lm -lcrypt
> > -lpthreads -lc -lbsd
> > perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd
> > libc=, so=a, useshrplib=true, libperl=libperl.a
> > gnulibc_version=''
> > Dynamic Linking:
> > dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='
> > -bE:/usr/opt/perl5/lib64/5.8.8/aix-thread-multi-64all/CORE/perl.exp'
> > cccdlflags=' ', lddlflags='-b64 -bhalt:4 -bexpall -G -bnoentry
> > -lpthreads -lc'
> >
> >
> > Characteristics of this binary (from libperl):
> > Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
> > PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT
> > USE_ITHREADS USE_LARGE_FILES USE_PERLIO
> > USE_REENTRANT_API
> > Built under aix
> > Compiled at Jun 3 2009 12:34:41
> > %ENV:
> > PERL5LIB="/usr/local/libperl"
> > @INC:
> > /usr/local/libperl
> > /usr/opt/perl5/lib64/5.8.8/aix-thread-multi-64all
> > /usr/opt/perl5/lib64/5.8.8
> > /usr/opt/perl5/lib64/site_perl/5.8.8/aix-thread-multi-64all
> > /usr/opt/perl5/lib64/site_perl/5.8.8
> > /usr/opt/perl5/lib64/site_perl
> > .
> >
> > I tried to find xlC and here's the result:
> >
> >
> > srvdfj239 / # find . -name *xlc*
> >
> > Nothing was found from the above.
> >
> >
> > srvdfj239 / # find . -name *xlC*
> > ./etc/xlC.cfg_dce
> > ./usr/lpp/xlC
> > ./usr/lpp/xlC/exe/default_msg/xlCfe.cat
> > ./usr/lpp/xlC/exe/xlCcpp
> > ./usr/lpp/xlC.aix50
> > ./usr/lpp/xlC.aix50/deinstl/xlC.aix50.rte.al
> > ./usr/lpp/xlC.aix50/deinstl/xlC.aix50.rte.inventory
> > ./usr/lpp/xlC.aix50/deinstl/xlC.aix50.rte.unpost_i
> > ./usr/lpp/xlC.cpp
> > ./usr/lpp/xlC.cpp/deinstl/xlC.cpp.al
> > ./usr/lpp/xlC.cpp/deinstl/xlC.cpp.inventory
> > ./usr/lpp/xlC.msg.en_US
> > ./usr/lpp/xlC.msg.en_US/deinstl/xlC.msg.en_US.rte.al
> > ./usr/lpp/xlC.msg.en_US/deinstl/xlC.msg.en_US.rte.inventory
> > ./usr/lpp/xlC.rte
> > ./usr/lpp/xlC.rte/deinstl/xlC.rte.al
> > ./usr/lpp/xlC.rte/deinstl/xlC.rte.inventory
> > srvdfj239 / #
> >
> > Compilers is not really my thing. Currently I'm using
> > /usr/ccs/lib/cpp. Is that not the same thing?
> >
>
> no, I don't think so. I presume you did not build this Perl yourself, but 
> downloaded from some IBM site as a binary. You need a "proper" C compiler to 
> compile XS modules (which DBI is). That is the xlc package from IBM and it 
> costs money usually (but I could be out of date on that). If you cannot spend 
> money or cannot get xlc you can always build your own Perl with perlbrew and 
> install gcc for the compiler but you cannot mix gcc compiled stuff with xlc 
> compiled stuff (which your current Perl is).
>
> Martin
> --
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com 

RE: Cannot connect to Oracle db; script will not run

[John Scoles]

have a look at 

http://search.cpan.org/~pythian/DBD-Oracle-1.46/lib/DBD/Oracle/Troubleshooting.pm

it should answer most of your questions


> From: james.war...@acxiom.com
> To: beginn...@perl.org; dbi-users@perl.org
> CC: newbie01.p...@gmail.com; rob.di...@gmx.com
> Subject: Cannot connect to Oracle db; script will not run
> Date: Wed, 1 Aug 2012 00:54:13 +
>
> --Beyond some training, I'm very much a newbie to Perl (and this list). So, 
> please indulge me with my first attempt at a posted question to you; please 
> see below (*with the full code Perl script toward the bottom of my email)...
>
> -I've been dealing with an issue in a Perl script that I'm writing, similar 
> to what was posted recently under 'Subject: Script to test connecting to 
> Oracle DBs' (and 'Subject: Re: Script to test connecting to Oracle DBs' by 
> Rob Dixon).
> Specifically, from my code:
> $ENV{TWO_TASK} = "lady";
>
> $dbh = DBI->connect("$connString", "$ladyUser", "$ladyPass",
> { AutoCommit=>0, RaiseError=>0, PrintError=>0, ora_check_sql=>0 }) or die 
> "Could not connect to database: " . DBI->errstr ;
>
> ... ...but I still keep getting the same error message at command line in 
> unix:
> naszcard@gustavo: /ou8/naszcard/sox => perl -c Clapper_jjw_lookups.pl
> Clapper_jjw_lookups.pl syntax OK
> naszcard@gustavo: /ou8/naszcard/sox => perl Clapper_jjw_lookups.pl -t
> Could not connect to database: ORA-24327: need explicit attach before 
> authenticating a user (DBD ERROR: OCISessionBegin) at Clapper_jjw_lookups.pl 
> line 134.
>
> FYI: line 134 is above - "{ AutoCommit=>0, RaiseError=>0, PrintError=>0, 
> ora_check_sql=>0 }) or die "Could not connect to database: " . DBI->errstr;"
>
> -So, after double-checking that I was using the correct SID, and banging my 
> head against the wall ;-), I commented out the 'use DBI;' and the section 
> above, and just tried to go straight to it, command line, and do it this way 
> instead:
> my $tempCmd = "sqlplus /nolog \@" . '/ou8/naszcard/sox/spool_lookup1b.sql ' . 
> "$gustavoUser $gustavoPass | grep ORA";
> @oracleErrors = '$tempCmd';
>
> if(@oracleErrors ne 0) {
> $tempDate = `date`;
> chomp($tempDate);
>
> my $tempORAError = join("/n",@oracleErrors);
> system("echo \"Clapper_jjw_lookups.pl has failed due to ORACLE ERROR(S): \n\n 
> It is $tempDate \n\n $tempORAError\" | mailx -s \"Moja Table Lookups Errors\" 
> \" $global_email \" ");
> exit;
> }
>
> ~That produces this not very informative, error generated email:
> -Original Message-
> From: service - PRC [mailto:naszc...@acxiom.com]
> Sent: Monday, July 30, 2012 10:51 PM
> To: Warren James - jawarr
> Subject: Moja Table Lookups Errors
>
> Clapper_jjw_lookups1.pl has failed due to ORACLE ERROR(S):
>
> It is Mon Jul 30 22:50:47 CDT 2012
>
>
> (@oracleErrors is an array which doesn't seem to be working...)
>
> *Here is the current, full text of my Perl code (passwords and other 
> sensitive, proprietary, etc., info. changed/hidden/masked to protect the 
> innocent ;-):
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> #use DBI;
> #use DBD::Oracle qw(:ora_types);
> use Net::SFTP::Foreign;
> use diagnostics;
>
> 
> ## SCRIPT: Clapper_jjw_lookups.pl
> ## AUTHOR: James J. Warren -- jawarr
> ## NOTES: ERRORs logged and emailed
> ##
> ## First Perl script for James
> ##
> 
>
> # --
> #  Global Declaration --
> # --
>
> my $logPath = ""; #-- Directory where all logs go (Does include last '/' )
> my $codePath = ""; #-- Directory where all scripts are (Does include last 
> '/' )
> my $ftpDirectory = '/outbound/sftpp/xpj123/';
>
> my $global_email = " naszprod\@acxiom.com"; # -- Global email (All emails 
> will be mailed to this address)
>
>
> # my $dbh = ""; # -- Database handle that will be initiated later
> my $sth = ""; # -- Statement handle that will be initiated later
>
>
> my @oracleErrors;
>
> my $fileConnectionString = " ";
> my $connString = " ";
>
> my $ladyUser = " ";
> my $ladyPass = " ";
> my $gustavoUser = " ";
> my $gustavoPass = " ";
>
> my @finishedSqlScripts;
>
> my $tempQuery = "";
> my $err_str = "";
>
>
> # --
> #  End of Global Declaration ---
> # --
>
> my $startupCounter = 0;
>
> our($opt_t);
> &init();
>
>
>
> if ( $opt_t ){
>
> $fileConnectionString = `cat ///xxx/logon.sql`; # -- The string 
> passed into the code that decides what user and password to use when login 
> into Oracle
> $connString = 'dbi:Oracle:SID';
> $logPath = '/xxx//logs/reporting/

RE: Odd error using bind_param_inout

[John Scoles]

Funny, you are right it does not look incorrect

 

give this a quick try

 


$csr_insert->bind_param_inout(':new_id', \my $new_resource_id, 99);


 

Was this working before?

Did it break after an upgrade or something??

 

cheers 

 

John

 

 

> 
> From: john...@pharmacy.arizona.edu
> Subject: Odd error using bind_param_inout
> Date: Mon, 4 Jun 2012 11:01:29 -0700
> To: dbi-users@perl.org
>
> I'm getting the following error:
>
> [Mon Jun 04 09:14:49 2012] [error] [client 128.196.45.237] DBD::Oracle::db do 
> failed: ORA-01008: not all variables bound (DBD ERROR: OCIStmtExecute) [for 
> Statement "insert into resources ( 
> short_name,long_name,building_id,room_desc,isaroom,numseats,numtables,hour_open,hour_close,available,computer,enet_num,approved_text)values(
>  'B340','SP Training Room','1062','','1','','','7','20','A','','','') 
> returning resource_id into :new_id"] at 
> /home/allwebfiles/perl/resource_mgmt2.pl line 67., referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/resource_mgmt.pl
>
>
> The relevant perl code is:
>
> my $new_resource_id = 0;
> my $csr_insert = $lda->do($sq_insert);
> $csr_insert->bind_param_inout(':new_id', \$new_resource_id, 25);
> $csr_insert->execute();
>
> There's only one variable, and as far as I can see it's correct.
>
> $sq_insert is the statement listed in the logged error. resource_id is 
> created via an 'on insert' trigger.
>
>
> --
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
>
> Institutions do not have opinions, merely customs
>
> 

RE: DBD::Oracle build on aix 6.1 ( host is 64 bit db server )

[John Scoles]

Short answer no.  I would not see any reason why you would need to install the 
instance client as well.
 
In the long run it depends on what you are doing.  If you are going to use perl 
for only loacal access then no need for the instanct cleint.  If you want to 
use Perl for say connecting via a web server or alike using the instant client 
may be what you want.
 
In the end what do you want to do??
 
Cheers
John
 

> To: dbi-users@perl.org
> From: xtdk...@gmail.com
> Subject: DBD::Oracle build on aix 6.1 ( host is 64 bit db server )
> Date: Sat, 19 May 2012 09:27:05 -0700
> 
> The 64 bit Oracle server is loaded on this host.
> 
> Do I still have to load an Oracle client?
> 
> README.clients.txt says:
> 
> *** THE PREFERED METHOD IS TO USE Oracle Instant Client ***
> 
> So should I install the 'Oracle Instant Client' before attempting
> the build of DBD::Oracle?
> 
> --
> thanks!
> 
  

RE: It's a bad day here...

[John Scoles]

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...
> From: john...@pharmacy.arizona.edu
> Date: Fri, 30 Mar 2012 15:04:42 -0700
> CC: dbi-users@perl.org
> To: martin.ev...@easysoft.com
> 
> 
> 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 not really enlightened any more:
> 
> I did the following:
> 
> $lda->{ora_verbose} =6;
> foreach $i (@resources){
> $have_pref=0; 
> $csr_prefapp->execute($i) or die $DBI::errstr;
> while (($k, $j) = $csr_prefapp->fetchrow()){$approvers{$k}=$j;$have_pref=1;}
> if (!$have_pref){
> $csr_allapp->execute($i) or die $DBI::errstr;
> while (($k, $j) = $csr_prefapp->fetchrow()){$approvers{$k}=$j;}
> }
> }
> $lda->{ora_verbose} =1;
> 
> And got the following output, in which everything is a success up until the 
> final message, if I read this correctly.
> 
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] dbd_bind_ph(1): 
> bind :p1 <== '120' (type 0 (DEFAULT (varchar)), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] ), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] dbd_rebind_ph() 
> (1): rebinding :p1 as '120' (not-utf8, ftype 1 (VARCHAR), csid 0, csform 
> 0(0), inout 0), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> dbd_rebind_ph_char() (1): bind :p1 <== '120' (, referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] size 3/8/0, , 
> referer: https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] ptype 8(VARCHAR), 
> otype 1 ), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> dbd_rebind_ph_char() (2): bind :p1 <== ''12' (size 3/8, otype 1(VARCHAR), 
> indp 0, at_exec 1), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] \t bind :p1 as 
> ftype 1 (VARCHAR), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> \tOCIBindByName(1ac0678,19dc6d8,1996df0,":p1",placeh_len=3,value_p=1ab01f0,value_sz=8,dty=1,indp=19dc6f8,alenp=0,rcodep=19dc6f0,maxarr_len=0,curelep=0
>  (*=0),mode=DATA_AT_EXEC,2)=SUCCESS, referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> \tOCIBindDynamic(1ac02f8,1996df0,19dc6a0,7f3aca306120,19dc6a0,7f3aca306410)=SUCCESS,
>  referer: https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> \tOCIAttrGet(1ac02f8,OCI_HTYPE_BIND,19dc6bc,0,31,1996df0)=SUCCESS, referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] dbd_rebind_ph(): 
> bind :p1 <== '120' (in, not-utf8, csid 1->0->1, ftype 1 (VARCHAR), csform 
> 0(0)->0(0), maxlen 8, maxdata_size 0), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> \tOCIAttrSet(1ac02f8,OCI_HTYPE_BIND, 7fff1105787c,0,Attr=31,1996df0)=SUCCESS, 
> referer: https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] dbd_st_execute 
> SELECT (out0, lob0)..., referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] Statement Execute 
> Mode is 0 (DEFAULT), referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] \t\tin ':p1' 
> [0,0]: len 3, ind 0, value='120', referer: 
> https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> \tOCIStmtExecute(1996d10,1ac0678,1996df0,0,0,0,0,mode=DEFAULT,0)=SUCCESS, 
> referer: https://resource-scheduler.pharmacy.arizona.edu/calendar/reserve.pl
> [Fri Mar 30 14:19:25 2012] [error] [client 128.196.45.237] 
> \trs_array_init:imp_sth->rs_array_size=158, rs_array_id

RE: Error I've not seen before from oracle DBD

[John Scoles]

 > Date: Fri, 30 Mar 2012 09:10:41 +0100
> From: martin.ev...@easysoft.com
> To: john...@pharmacy.arizona.edu
> CC: dbi-users@perl.org
> Subject: Re: Error I've not seen before from oracle DBD
> 
> On 30/03/12 09:02, Martin J. Evans wrote:
> > On 29/03/12 22:10, Bruce Johnson wrote:
> >>
> >> On Mar 29, 2012, at 1:58 PM, Bill Ward wrote:
> >>
> >>> Try not using numbers for the placeholder names?
> >>>
> >>
> >> That worked...
> >>
> >> my $sq_res_pend = "insert into reservations_pend (pid, email, cn,
> >> purpose, reserver_affstring) values(:A,:B,:C,:D,:E) returning
> >> reservations_pend_id into :NEWID";
> >>
> >> my $csr_res_pend = $lda->prepare($sq_res_pend) or die
> >> $DBI::errstr; $csr_res_pend->bind_param(':A',$res_pid) or die
> >> $DBI::errstr; $csr_res_pend->bind_param(':B',$res_email) or die
> >> $DBI::errstr; $csr_res_pend->bind_param(':C',$res_name) or die
> >> $DBI::errstr; $csr_res_pend->bind_param(':D',$res_purp) or die
> >> $DBI::errstr; $csr_res_pend->bind_param(':E',$res_affil) or die
> >> $DBI::errstr;
> >> $csr_res_pend->bind_param_inout(":NEWID",\$new_res_id, 25) or die
> >> $DBI::errstr;
> >>
> >> $csr_res_pend->execute();
> >>
> >> Got right through.
> >>
> >> Is this a bug or a rule I'm not aware of?
> >>
> >>
> >
> > It is a rule in so far that, that is what the code says. Placeholders
> > of the form :N (where N is a number) are deemed different from
> > placeholders of the form :A (where the first chr of A is not a
> > number) are deemed different from placeholders of the form ?.
> >
> > Looking at the code (which I did not write) :N is a special case in
> > that you cannot have multiple Ns in the SQL where :A forms can be
> > repeated in the SQL. The ? form is just changed to :N internally in
> > the code.
> 
> Correction. :N is a special case because you can omit the ":N" from the 
> bind_param call and simply call bind_param(N,...). e.g.,
> 
> my $s = $h->prepare(q/insert into mje (a,b) values(:1, :1)/);
> $s->bind_param(1, 1); # you don't use ":1"
> 
> The :N form can be repeated as above. I'll try and find some time to update 
> the pod.
>  Boy that is a very old hunk of code.  funny this never came up till now.   
> cheersJohn
> > The relevant code is:
> >
> > if (*start == '?') { /* X/Open standard */ sprintf(start,":p%d",
> > ++idx); /* '?' -> ':p1' (etc) */ dest = start+strlen(start); style =
> > "?";
> >
> > } else if (isDIGIT(*src)) { /* ':1' */ idx = atoi(src); *dest++ =
> > 'p'; /* ':1'->':p1' */ if (idx <= 0) croak("Placeholder :%d invalid,
> > placeholders must be >= 1", idx);
> >
> > while(isDIGIT(*src)) *dest++ = *src++; style = ":1";
> >
> > } else if (isALNUM(*src)) { /* ':foo' */ while(isALNUM(*src)) /*
> > includes '_' */ *dest++ = toLOWER(*src), src++; style = ":foo";
> >
> > } else { /* perhaps ':=' PL/SQL construct */ /* if (src == ':')
> > *dest++ = *src++; XXX? move past '::'? */ continue; }
> >
> > *dest = '\0'; /* handy for debugging */ namelen = (dest-start); if
> > (laststyle && style != laststyle) croak("Can't mix placeholder styles
> > (%s/%s)",style,laststyle);
> >
> > The DBI documentation is too vague in this respect to say DBD::Oracle
> > is wrong here. I also know some drivers which support :xxx but then
> > when you call bind_param you don't specify the leading ':' (subject
> > of a dbi-dev posting of mine some years back). There are also drivers
> > which support :xxx but you cannot put that exact :xxx more than once
> > in the SQL (you can with DBD::Oracle).
> >
> > Martin
> 
> Martin
> -- 
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
  

RE: [DBD::Oracle] ORA-02005 on array insert

[John Scoles]

Ran into that one, or nearly like it, a while back.  Was not able to find a 
OCI/DBD solution so I just modified my code like this
 
$sth->execute_array({},\ @undefs, \@undefs, \@data_ids, \@set_ids, $ct_none);

 so I had an array for each param
 
a quick kludge only.
 
If I get a little time this week I will try to look into it.
 
Cheers
John
 

> Date: Tue, 20 Mar 2012 13:12:56 +0100
> From: h...@wsr.ac.at
> To: dbi-users@perl.org
> Subject: [DBD::Oracle] ORA-02005 on array insert
> 
> A few months ago we upgraded two of our servers from RHEL 4 to RHEL6.
> Unfortunately the upgrade involved the OS, the Perl version (5.8.8 ->
> 5.10.1), the Oracle client version (still 10g, but now instant client)
> and DBD::Oracle (1.19 -> 1.30 (now 1.38)), and we didn't note the
> problem at once, so it's unclear which of the many changes is the
> culprit, but I suspect it's a bug in DBD::Oracle.
> 
> Anyway, since the upgrade sometimes (not always) array inserts returned
> the error 
> 
> DBD::Oracle::st execute_array failed: ORA-02005: implicit (-1)
> length not valid for this bind or define datatype (DBD ERROR:
> OCIBindByName) 
> 
> Here is a test script which semi-reliably (>= 50% of the time) produces
> the error message:
> 
> 
> #!/usr/bin/perl
> 
> use warnings;
> use strict;
> 
> use DBI;
> 
> my $dbi_credential_file = $ARGV[0];
> my ($data_source, $username, $auth) = read_cred($dbi_credential_file);
> 
> my $conn_attr = {
> AutoCommit => 0,
> PrintError => 0,
> RaiseError => 1
> };
> $ENV{NLS_LANG} = '.AL32UTF8'; # real UTF-8
> my $dbh = DBI->connect($data_source, $username, $auth, $conn_attr);
> $dbh->{FetchHashKeyName} = 'NAME_lc';
> 
> $dbh->do("create table bug_ora_02005_$$ (
> set_id number not null,
> data_id number not null,
> time number,
> period_start number,
> period_end number,
> real number,
> string number,
> coordtype number,
> 
> constraint bug_ora_02005_${$}_pk primary key(data_id, set_id)
> )
> ");
> 
> my $n = 900;
> my $ct_none = undef;
> 
> for my $run (1 .. 1_000) {
> print STDERR "run: $run\n";
> my $data_ids;
> my @set_ids;
> for (1 .. $n) {
> push @$data_ids, $_;
> push @set_ids, $run;
> }
> my $sth = $dbh->prepare_cached("insert into bug_ora_02005_$$(period_start, 
> period_end, data_id, set_id, coordtype)
> values(?, ?, ?, ?, ? )");
> 
> $sth->execute_array({}, undef, undef, $data_ids, \@set_ids, $ct_none);
> }
> $dbh->commit();
> 
> $dbh->do("drop table bug_ora_02005_$$");
> $dbh->disconnect();
> 
> sub read_cred {
> my ($fn) = @_;
> 
> open(my $fh, "<$fn") or die "cannot open $fn: $!";
> my $line = <$fh>;
> my @cred = split(/[\s\n]+/, $line);
> return @cred;
> }
> __END__
> 
> Some notes:
> 
> ARGV[0] is supposed to be the name of a file containing space-separated
> connect data, e.g.:
> dbi:Oracle:ORCL scott tiger
> 
> When the script fails, it always fails on the second iteration of the
> loop. If it gets through the second iteration it completes all 1000
> iterations successfully.
> 
> When the call to prepare_cached is replaced by a simple prepare, the
> script fails less often. 
> 
> I have run the script with DBI_TRACE=4, but I don't see any significant
> difference between successful and unsuccessful runs.
> 
> hp
> 
> -- 
> _ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
> |_|_) | Sysadmin WSR | eingeprägt stehen: "Ein ewig Rätsel will ich
> | | | h...@wsr.ac.at | bleiben, mir und andern."
> __/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
  

RE: Oracle DBI on "trusted" hpux

[John Scoles]

I wish I could give you a 100% tumbs up on this but...
 
It should work without problems as I have used Oracle Wallet many times before 
and in theory the OCI client and not the perl code should take care of all that 
for you.
 
So if you can connect with DBD::Oracle it should just work.
 
You might need a good deal of tweaking of the ENV to get it to work though
 
Hope this helps

 

> From: Howardit c...@prpa.org
> To: dbi-users@perl.org
> Subject: Oracle DBI on "trusted" hpux
> Date: Tue, 7 Feb 2012 20:19:06 +
> 
> kind DBI users,
> 
> In order to get some security features that my users
> are asking for, it looks like I will need to 
> implement "trusted mode" on our HP-UX servers.
> 
> Will that have any impact on Perl/DBI scripts that
> run correctly in our current, "untrusted mode" environment?
> 
> We are using Oracle Wallet to store script credentials.
> 
> It seems to me that trusted mode should be ok, but
> thought I would check first before bringing the
> world crashing down.
> 
> 
> 
  

RE: What is the oldest community supported versions for PERL DBI and DBD::ORACLE?

[John Scoles]

I would have to agree with Martin.  The bigest jump, code-wise was the jump 
between 16~17 so you are very much out of luck if you want to get anything 
fixed in 16 or eariler. I you update to 17 first and see what happens you will 
get a good idea if you can update any futher.  I also depends on the version of 
oracle DB and client you are using.   CheersJohn 
 > Date: Mon, 23 Jan 2012 15:14:24 +
> From: martin.ev...@easysoft.com
> To: dbi-users@perl.org
> Subject: Re: What is the oldest community supported versions for PERL DBI and 
> DBD::ORACLE?
> 
> On 23/01/12 14:13, TIDWELL, GARY wrote:
> > Hi all, we are currently using DBD::ORACLE 1.16 and DBI 1.46, and I'm 
> > having a tough time
> > trying to determine if either of these are still supported by the open 
> > source community.
> >
> > All help is appreciated.
> >
> > Thanks,
> > Gary
> >
> >
> >
> 
> DBI 1.46 isn't even on cpan now - it has been moved to backpan. It was 
> released 16 Nov 2004 and has been superseded by 19 releases on CPAN.
> 
> DBD::Oracle 1.16 was released 22 Oct 2004 and has been superseded by 23 
> releases.
> 
> So you are using 7 year code both of which has moved on a lot since then.
> 
> I help out with both of those modules and if you had a problem with either of 
> them that old my response would likely be to upgrade. However, it depends on 
> what you mean by "support" - what do you mean?
> 
> Presumably because you are using really old perl modules either a) the code 
> was written ages ago or b) you need to use a really old version of Perl newer 
> DBI and DBD::Oracle modules no longer support? If it is (a) then so long as 
> you don't change anything why would you need support? If it is (b) and you 
> seriously cannot move to a newer Perl you've got the same problem with Perl 
> itself.
> 
> With DBD::Oracle, the latest version is so different from the one you are 
> using (code-wise) I doubt even if you found a bug which was still present in 
> the newest release you'd persuade anyone to also fix it in 1.16.
> 
> Perhaps you need to explain why you've asked the question.
> 
> Martin
> -- 
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
  

RE: question about bind_param_inout and oracle

[John Scoles]

 

> From: john...@pharmacy.arizona.edu
> Subject: question about bind_param_inout and oracle
> Date: Thu, 5 Jan 2012 11:37:50 -0700
> To: dbi-users@perl.org
> 
> In the docs there's a note that bind_param_inout_array requires a maxlen 
> value, but that Oracle ignores this.
> 
bind_param_inout_array  is an undocumented and implimented feature of DBI spec, 
I think DBD::Oracle is the only one that implements it, it doesn't need it but 
it is required as it is part of the DBI spec so it needs to take the empty 
value.
 

> "The third parameter of bind_param_inout_array, (0 in the example), "maxlen" 
> is required by DBI but not used by DBD::Oracle"
> 
> Is this true for the bind_param_inout method? as well?

bind_param_inout is implimented fully on the DBI side so what ever the DBI spec 
says it needs it then it needs it.
 
 
Hope this helps.
John Scoles
> 
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs
> 
> 
  

RE: [DBI-Users] Fwd: Problem to get UTF8-CSV-File

[John Scoles]

Let me chime in here as well.  Though I rarely ever use UTF but I beleive you 
can set and or override any of the ENV values
this at the handle level which I think is the best solution to the orginal 
problem
 
>From the POD
 
ora_charset, ora_ncharset
For oracle versions >= 9.2 you can specify the client charset and ncharset with 
the ora_charset and ora_ncharset attributes. You still need to pass ora_envhp = 
0 for all but the first connect.
These attributes override the settings from environment variables.  $dbh = 
DBI->connect ($dsn, $user, $passwd,
   {ora_charset => 'AL32UTF8'});
 
Never use the stuff so I may be way off base.
 
Cheers
and Happy Christmass
 

> Date: Fri, 23 Dec 2011 11:08:31 +
> From: c...@cam.ac.uk
> To: b...@wards.net
> CC: hermann.schwaerz...@uibk.ac.at; dbi-users@perl.org
> Subject: Re: [DBI-Users] Fwd: Problem to get UTF8-CSV-File
> 
> On 22/12/11 20:40, Bill Ward wrote:
> > Agreed. Any Oracle initialization environment variables need to be set
> > before your Perl script starts. Another approach is to set them and then
> > re-exec() from within the script ... though be careful to avoid infinitely
> > re-execing the same script!
> 
> This is not correct. With the script as written, no Oracle related code
> is executed until connect time, so enviroment variables which are interpreted
> by Oracle can be set any time before the first connect.
> 
> On the other hand, variables interpreted by the run-time loader, such as
> LD_LIBRARY_PATH, must be set before perl itself is loaded. So, re-execing
> is necessary for a change to LD_LIBRARY_PATH, but not, but not for a
> change of NLS_LANG.
> 
> >> hello ralf
> >> hello jens
> >>
> >> Jens Rehsack schrieb:
> >> [...]
> >>
> >> We have a problem. We want to get an UTF8-CSV-File from
> >>> UTF8-Oracle-Database. It seems to be that the CSV-File is always charset
> >>> "latin-1". What can we do to get UTF-8-File?
> >>> Here is our Testscript.
> >>>
> >>> #-- our Testscript**#
> >>> #!/usr/local/bin/perl -w -C64 use strict;
> >>>
> >> [...]
> >>
> >>> $ENV{NLS_LANG}="GERMAN_**GERMANY.AL32UTF8";
> >>>
> >> [...]
> >>
> >> I seem to remember that it's to late for the oracle-client libraries to
> >> set NLS_LANG here inside the script - I guess at this time they are loaded
> >> already and have finished initializing their charset, thus ignoring any
> >> change in NLS_LANG.
> >>
> >> try to set NLS_LANG before starting the script. either by "export"ing it
> >> or by doing
> >>
> >> NLS_LANG="GERMAN_GERMANY.**AL32UTF8" ./your-test-script
> >>
> >> greetings
> >> hermann
> >>
> >
> >
> >
> 
> 
> -- 
> Charles Jardine - Computing Service, University of Cambridge
> c...@cam.ac.uk Tel: +44 1223 334506, Fax: +44 1223 334679
  

RE: Problem with Oracle collections/objects

[John Scoles]

Well partial answer for you Martin.  
 
Seems Cast Array and Collect are new extended SQL commands which allow you to 
directly select embedded types with SQL.
 
So in this case we are mixing our metaphores.
 
DBD::Oracle will do the casting for you and your code is trying to do the 
casting as well so in the end it gets muddleded. The CAST and crew doing its 
work on the back end my DBD::ORacle code playing about in the front.
 
This I could see as a problem as some one who wants 'CAST' to work will find it 
doesn't which is bad. Though with embeded objects you have no need to use them.
 
Will have to put in some code someplace to detect these new sql commands and 
ignor the built in DBD::Oracle object.
 
No time for it today though.  
 
One way to check this theory is give it a try with an early version of 
DBD::Oracle that does not have the object stuff built in.  I think 19 will do 
it.
So iIf you can run your test below on a 1.19 install against 10g box and see 
what you get?
 
>From what I see we are just running out of itter resouses in the OCI client so 
>it has slows down untill some are freed up, I have seen this before with 
>embedded objects when they go very deep with many types. One has to remeber 
>that the Varray, object and type are not really what one thinks they are.  
>When you get into the actulle implimetation on the DB level you will see they 
>are just flat releational tables.  So a Varray in a table like this  table(id 
>number ,my_Varray number(6) )  would actully be  two tables one with ID and a 
>ref object field that points to another table that contains the ref and next 
>to it you varray values.  Not the most efficient way to store your data and 
>why it has largely been ignored by most DBA since it came out way back in 
>oracle 8
 
I will play a little more when I get some time and see if I can rewrite the 
code to not use the CAST and array 
 
Cheers
John
 

 

> From: byter...@hotmail.com
> To: martin.ev...@easysoft.com; dbi-...@perl.org
> CC: dbi-users@perl.org
> Subject: RE: Problem with Oracle collections/objects
> Date: Tue, 13 Dec 2011 06:42:12 -0500
> 
> 
> Well I am able to recreate it which is a good thing. Like you said about 52 
> iterations then it begins to gobble up memory in both oracle and perl so me 
> think i is running out of resources.
> 
> I will give it a closer look 
> 
> Cheers
> John 
> 
> > From: byter...@hotmail.com
> > To: martin.ev...@easysoft.com; dbi-...@perl.org
> > CC: dbi-users@perl.org
> > Subject: RE: Problem with Oracle collections/objects
> > Date: Sun, 11 Dec 2011 12:00:12 -0500
> > 
> > 
> > Well I wrote the code in DBD::Oracle for embedded objectes/types so I am 
> > the one to blame for that. From the SQL and connection string below looks 
> > like you are using the Oralce sql extensions to get the data back and not 
> > the native DBD::Oracle/OCI object selections so we might be looking at 
> > something else in DBD::Oracle. Will have to load this puppy up and have a 
> > look at the verbose trace 
> > 
> > Will have to wait till monday though swamped with SlJs here today
> > 
> > Cheers
> > John Scoles
> > 
> > > Date: Fri, 9 Dec 2011 14:01:43 +
> > > From: martin.ev...@easysoft.com
> > > To: dbi-...@perl.org
> > > CC: dbi-users@perl.org
> > > Subject: Problem with Oracle collections/objects
> > > 
> > > Hi,
> > > 
> > > If anyone is around who wrote or has worked on the object/collections 
> > > support in DBD::Oracle I'd greatly appreciate it if you could take a 
> > > quick look at this problem as the code in DBD::Oracle for this has 
> > > defeated me so far.
> > > 
> > > The problem is I have a query which uses types and collect and although 
> > > it works fine initially once it has been run a number of times in the 
> > > same connection it eventually goes from a 3s fetch time to a number of 
> > > minutes. I have reduced it to the example below.
> > > 
> > > I can run this code all day long in sqlplus without a problem so I don't 
> > > think it is an Oracle issue.
> > > 
> > > Changing the 3 numbers affects how many iterations it takes before it 
> > > goes wrong and how long the fetch eventually takes to retrieve the data. 
> > > Initially it seemed the calculation to find out which iteration it goes 
> > > wrong on was
> > > 
> > > 2655 / objects fetched (the 3 numbers multipled together) gave the 
> > > iteration
> > > 
> > > and that looked pretty close initially. Clutching at straws 2^31 / 
> > > 2655 is suspic

RE: Problem with Oracle collections/objects

[John Scoles]

Well I am able to recreate it which is a good thing. Like you said about 52 
iterations then it begins to gobble up memory in both oracle and perl so me 
think i is running out of resources.
 
I will give it a closer look 
 
Cheers
John 

> From: byter...@hotmail.com
> To: martin.ev...@easysoft.com; dbi-...@perl.org
> CC: dbi-users@perl.org
> Subject: RE: Problem with Oracle collections/objects
> Date: Sun, 11 Dec 2011 12:00:12 -0500
> 
> 
> Well I wrote the code in DBD::Oracle for embedded objectes/types so I am the 
> one to blame for that. From the SQL and connection string below looks like 
> you are using the Oralce sql extensions to get the data back and not the 
> native DBD::Oracle/OCI object selections so we might be looking at something 
> else in DBD::Oracle. Will have to load this puppy up and have a look at the 
> verbose trace 
> 
> Will have to wait till monday though swamped with SlJs here today
> 
> Cheers
> John Scoles
> 
> > Date: Fri, 9 Dec 2011 14:01:43 +
> > From: martin.ev...@easysoft.com
> > To: dbi-...@perl.org
> > CC: dbi-users@perl.org
> > Subject: Problem with Oracle collections/objects
> > 
> > Hi,
> > 
> > If anyone is around who wrote or has worked on the object/collections 
> > support in DBD::Oracle I'd greatly appreciate it if you could take a quick 
> > look at this problem as the code in DBD::Oracle for this has defeated me so 
> > far.
> > 
> > The problem is I have a query which uses types and collect and although it 
> > works fine initially once it has been run a number of times in the same 
> > connection it eventually goes from a 3s fetch time to a number of minutes. 
> > I have reduced it to the example below.
> > 
> > I can run this code all day long in sqlplus without a problem so I don't 
> > think it is an Oracle issue.
> > 
> > Changing the 3 numbers affects how many iterations it takes before it goes 
> > wrong and how long the fetch eventually takes to retrieve the data. 
> > Initially it seemed the calculation to find out which iteration it goes 
> > wrong on was
> > 
> > 2655 / objects fetched (the 3 numbers multipled together) gave the 
> > iteration
> > 
> > and that looked pretty close initially. Clutching at straws 2^31 / 2655 
> > is suspiciously 80.
> > 
> > Here are some results with the 3 number variations:
> > 
> > inner middle outer iteration_fail fetch_time_change
> > 10 100 500 53 8s->345s
> > 5 10 500 76 4s->200s
> > 20 100 500 37 12->632s
> > 5 120 500 64 5s->247s
> > 5 100 300 75 3s->121s
> > 
> > It seems the inner number determines how bad the fetch time increases and 
> > the sum how many iterations it takes to reach the point where it goes wrong.
> > 
> > I'd greatly appreciate any ideas.
> > 
> > The code to reproduce is:
> > 
> > #!/usr/bin/perl
> > use warnings;
> > use strict;
> > 
> > use DBI;
> > 
> > my $dbh = DBI->connect('dbi:Oracle:host=xxx.yyy.com;sid=xxx;',
> > 'xxx', 'xxx',
> > # just so we can ctrl/c does not affect results
> > {ora_connect_with_default_signals => ['INT']});
> > eval {
> > $dbh->do(q/drop type TABLE_A/);
> > };
> > eval {
> > $dbh->do(q/drop type TABLE_B/);
> > };
> > eval {
> > $dbh->do(q/drop type RECORD_B/);
> > };
> > eval {
> > $dbh->do(q/drop type RECORD_A/);
> > };
> > 
> > $dbh->do(q/CREATE OR REPLACE TYPE RECORD_B AUTHID DEFINER AS OBJECT (ID 
> > INT)/);
> > $dbh->do(q/CREATE OR REPLACE TYPE TABLE_B IS TABLE OF RECORD_B/);
> > $dbh->do(q/CREATE OR REPLACE TYPE RECORD_A AUTHID DEFINER AS OBJECT (ID 
> > INT, TBL TABLE_B)/);
> > $dbh->do(q/CREATE OR REPLACE TYPE TABLE_A IS TABLE OF RECORD_A/);
> > 
> > 
> > my $count = 0;
> > 
> > while () {
> > my $stime = time;
> > my $j = do_it ($dbh);
> > my $etime = time;
> > 
> > $count++;
> > 
> > print $count ." - ".($etime - $stime)." secs\n";
> > }
> > 
> > sub do_it {
> > my $dbh = shift;
> > 
> > my $sql = <<"EOT";
> > SELECT
> > LEVEL ID,
> > (
> > SELECT
> > CAST (COLLECT(RECORD_A(ID, ARRAY)) AS TABLE_A) AS ARRAY
> > FROM
> > (
> > SELECT
> > LEVEL ID,
> > (
> > SELECT CAST(COLLECT(RECORD_B(ID)) AS TABLE_B) AS ARRAY
> > FROM (SELECT LEVEL ID FROM dual CONNECT BY LEVEL <= 10)
> > ) ARRAY
> > FROM
> > DUAL CONNECT BY LEVEL <= 100
> > )
> > ) ARRAY
> > FROM
> > DUAL CONNECT BY LEVEL <= 500
> > EOT
> > 
> > my $s = $dbh->prepare($sql);
> > $s->execute;
> > my $r = $s->fetchall_arrayref;
> > 
> > return $r;
> > }
> > 
> > Thanks
> > 
> > Martin
> > -- 
> > Martin J. Evans
> > Easysoft Limited
> > http://www.easysoft.com
> 
  

RE: Problem with Oracle collections/objects

[John Scoles]

Well I wrote the code in DBD::Oracle for embedded objectes/types so I am the 
one to blame for that. From the SQL and connection string below looks like you 
are using the Oralce sql extensions to get the data back and not the native 
DBD::Oracle/OCI  object selections so we might be looking at something else in 
DBD::Oracle.  Will have to load this puppy up and have a look at the verbose 
trace  
 
Will have to wait till monday though swamped with SlJs here today
 
Cheers
John Scoles

> Date: Fri, 9 Dec 2011 14:01:43 +
> From: martin.ev...@easysoft.com
> To: dbi-...@perl.org
> CC: dbi-users@perl.org
> Subject: Problem with Oracle collections/objects
> 
> Hi,
> 
> If anyone is around who wrote or has worked on the object/collections support 
> in DBD::Oracle I'd greatly appreciate it if you could take a quick look at 
> this problem as the code in DBD::Oracle for this has defeated me so far.
> 
> The problem is I have a query which uses types and collect and although it 
> works fine initially once it has been run a number of times in the same 
> connection it eventually goes from a 3s fetch time to a number of minutes. I 
> have reduced it to the example below.
> 
> I can run this code all day long in sqlplus without a problem so I don't 
> think it is an Oracle issue.
> 
> Changing the 3 numbers affects how many iterations it takes before it goes 
> wrong and how long the fetch eventually takes to retrieve the data. Initially 
> it seemed the calculation to find out which iteration it goes wrong on was
> 
> 2655 / objects fetched (the 3 numbers multipled together) gave the 
> iteration
> 
> and that looked pretty close initially. Clutching at straws 2^31 / 2655 
> is suspiciously 80.
> 
> Here are some results with the 3 number variations:
> 
> inner middle outer iteration_fail fetch_time_change
> 10 100 500 53 8s->345s
> 5 10 500 76 4s->200s
> 20 100 500 37 12->632s
> 5 120 500 64 5s->247s
> 5 100 300 75 3s->121s
> 
> It seems the inner number determines how bad the fetch time increases and the 
> sum how many iterations it takes to reach the point where it goes wrong.
> 
> I'd greatly appreciate any ideas.
> 
> The code to reproduce is:
> 
> #!/usr/bin/perl
> use warnings;
> use strict;
> 
> use DBI;
> 
> my $dbh = DBI->connect('dbi:Oracle:host=xxx.yyy.com;sid=xxx;',
> 'xxx', 'xxx',
> # just so we can ctrl/c does not affect results
> {ora_connect_with_default_signals => ['INT']});
> eval {
> $dbh->do(q/drop type TABLE_A/);
> };
> eval {
> $dbh->do(q/drop type TABLE_B/);
> };
> eval {
> $dbh->do(q/drop type RECORD_B/);
> };
> eval {
> $dbh->do(q/drop type RECORD_A/);
> };
> 
> $dbh->do(q/CREATE OR REPLACE TYPE RECORD_B AUTHID DEFINER AS OBJECT (ID 
> INT)/);
> $dbh->do(q/CREATE OR REPLACE TYPE TABLE_B IS TABLE OF RECORD_B/);
> $dbh->do(q/CREATE OR REPLACE TYPE RECORD_A AUTHID DEFINER AS OBJECT (ID INT, 
> TBL TABLE_B)/);
> $dbh->do(q/CREATE OR REPLACE TYPE TABLE_A IS TABLE OF RECORD_A/);
> 
> 
> my $count = 0;
> 
> while () {
> my $stime = time;
> my $j = do_it ($dbh);
> my $etime = time;
> 
> $count++;
> 
> print $count ." - ".($etime - $stime)." secs\n";
> }
> 
> sub do_it {
> my $dbh = shift;
> 
> my $sql = <<"EOT";
> SELECT
> LEVEL ID,
> (
> SELECT
> CAST (COLLECT(RECORD_A(ID, ARRAY)) AS TABLE_A) AS ARRAY
> FROM
> (
> SELECT
> LEVEL ID,
> (
> SELECT CAST(COLLECT(RECORD_B(ID)) AS TABLE_B) AS ARRAY
> FROM (SELECT LEVEL ID FROM dual CONNECT BY LEVEL <= 10)
> ) ARRAY
> FROM
> DUAL CONNECT BY LEVEL <= 100
> )
> ) ARRAY
> FROM
> DUAL CONNECT BY LEVEL <= 500
> EOT
> 
> my $s = $dbh->prepare($sql);
> $s->execute;
> my $r = $s->fetchall_arrayref;
> 
> return $r;
> }
> 
> Thanks
> 
> Martin
> -- 
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
  

RE: Issue with DBD:Oracle 1.34 module on 64 bit Linux machine

[John Scoles]

I would agree with that.
 
One thing alsot to check is to make sure the Perl that you are using is the 
same as the one DBD::Oracle was compiled on.  Many times a use's perl could be 
a completed seperate path that the root perl
 
cheers
John
 

> Date: Fri, 9 Dec 2011 13:48:41 -0600
> From: mn...@genome.wustl.edu
> To: kirankumar...@gmail.com
> CC: dbi-users@perl.org
> Subject: Re: Issue with DBD:Oracle 1.34 module on 64 bit Linux machine
> 
> kiran,
> 
> Sounds like a permission issue with the oracle library. Make sure the 
> library is accessible by the user running the script. Make sure the 
> directory where the library resides and the library itself is accessible 
> by the user. make sure the LD_LIRARY_PATH contains the path the library 
> if its not install in the standard library path.
> 
> michael
> 
> 
> 
> On Fri, 9 Dec 2011, kiran kumar wrote:
> 
> > Date: Fri, 9 Dec 2011 19:10:50 +0530
> > From: kiran kumar 
> > To: dbi-users@perl.org
> > Subject: Issue with DBD:Oracle 1.34 module on 64 bit Linux machine
> > 
> > Hi,
> >
> >
> >
> > I have installed DBD:Oracle 1.34 module on 64 bit Linux machine with root
> > user and when I run it root user its working file,
> >
> > But when I run it using non root user, I am getting the error
> >
> >
> >
> > “install_driver(Oracle) failed: Can't load
> > '/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so'
> > for module DBD::Oracle: libclntsh.so.10.1: cannot open shared object file:
> > No such file or directory at
> > /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/DynaLoader.pm line 230.
> >
> > at (eval 3) line 3
> >
> > Compilation failed in require at (eval 3) line 3.
> >
> > Perhaps a required shared library or dll isn't installed where expected
> >
> > at ./PreciseMedia_update.pl line 32”
> >
> >
> >
> > Please help me.
> >
> >
> >
> > Attached is the list of logs required.
> >
> >
> >
> > Let me know if further information is required.
> >
> >
> >
> > Thanks in Advance.
> >
> >
> > Regards,
> >
> > Kiran P
> >
> 
> -- 
> ---//---
> Time flies like the wind. Fruit flies like bananas.
> --- Groucho Marx
> 
> Either write something worth reading or do something worth writing.
> --- Benjamin Franklin
> 
> A meeting is an event at which the minutes are kept and the hours are lost
  

RE: Maintaining simultaneous support for two Oracle versions in DBI

[John Scoles]

 

> From: b...@wards.net
> Date: Sun, 4 Dec 2011 19:15:20 -0800
> Subject: Re: Maintaining simultaneous support for two Oracle versions in DBI
> To: smi...@latfor.state.ny.us
> CC: dbi-users@perl.org
> 
> Aren't the Oracle driver libraries backward compatible? If you link DBD to
> the Oracle 11 drivers, won't it still be able to connect to an Oracle 8
> server?
> 
 
No they usually only go back one version. So 9 can connect to 8~10, 10 to 9~11 
ect at least that has been the trend with the last few clients at least with 
OCI.
 
They tend to change up the OCI packaging with each new version as well just to 
muck up us OCI coders.
 
cheers
John

> On Fri, Dec 2, 2011 at 10:27 AM, Scott Smith wrote:
> 
> > My workplace is transitioning from Oracle version 9 to version 11. I would
> > like to build the DBD driver to support connecting to the Oracle 11
> > database. However, until all the data are migrated from the old database to
> > the new one, I would need to maintain connectivity to the old Oracle 9
> > database. Since the driver and shared objects built for the new database
> > would be incompatible, I would need to build separate objects for the
> > Oracle 11 connection.
> >
> > Some of the items I can identify are:
> >
> > The module should be Oracle11.pm rather than Oracle.pm (called as
> > DBI->connect("dbi:Oracle11:", ...) rather than DBI->connect("dbi:Oracle:",
> > ...)).
> > The shared object and bootstrap files as Oracle11.so and Oracle11.bs
> > respectively. (Should these go in the same directory or should they be in
> > the directory Oracle11 and does the package name in Oracle11.pm have to be
> > changed to DBD::Oracle11 in order to find things there?)
> >
> > I have some idea of what I need to change in Makefile.PL in order to
> > achieve at least part of this. What I have so far is changing references to
> > Oracle.pm to Oracle11.pm and $opts{NAME} from DBD::Oracle to Oracle 11. Am
> > I right about the second? Are there others I should have included?
> >
> > Thanks for any help,
> > Scott Smith
> >
> 
> 
> 
> -- 
> Check out my LEGO blog at http://www.brickpile.com
> Follow/friend me: facebook.com/billward • flickr.com/photos/billward •
> twitter.com/williamward
  

RE: Maintaining simultaneous support for two Oracle versions in DBI

[John Scoles]

I went through this about a year or so ago with another client his was 8 and 11 
so a real big differace.
 
It can be done but you have to reaname or at least alias some of the oracle 
files as well or else they will step on each other.  That is if you are usng 
linux. It is a little easer with windows (I am not joking) as the oracle files 
are in nice compact DLLs.
 
As well you have to reaname a good number of other files here and there in both 
XS and 'C' and try to get it to complie.
 
And even before you do that I did this a while ago and still have the code 
online here 'http://svn.perl.org/modules/dbd-oracle/branches/DBD-Oracle8' 
Renamed 8 but you can still complile it against 9 client.
 
 
But before you go though that I would just get the instanct client 10 which can 
connect to both 9 and and 11 and that should work for you.
 
Cheers
John
 

> Date: Fri, 2 Dec 2011 13:27:09 -0500
> From: smi...@latfor.state.ny.us
> To: dbi-users@perl.org
> Subject: Maintaining simultaneous support for two Oracle versions in DBI
> 
> My workplace is transitioning from Oracle version 9 to version 11. I 
> would like to build the DBD driver to support connecting to the Oracle 
> 11 database. However, until all the data are migrated from the old 
> database to the new one, I would need to maintain connectivity to the 
> old Oracle 9 database. Since the driver and shared objects built for the 
> new database would be incompatible, I would need to build separate 
> objects for the Oracle 11 connection.
> 
> Some of the items I can identify are:
> 
> The module should be Oracle11.pm rather than Oracle.pm (called as 
> DBI->connect("dbi:Oracle11:", ...) rather than 
> DBI->connect("dbi:Oracle:", ...)).
> The shared object and bootstrap files as Oracle11.so and Oracle11.bs 
> respectively. (Should these go in the same directory or should they be 
> in the directory Oracle11 and does the package name in Oracle11.pm have 
> to be changed to DBD::Oracle11 in order to find things there?)
> 
> I have some idea of what I need to change in Makefile.PL in order to 
> achieve at least part of this. What I have so far is changing references 
> to Oracle.pm to Oracle11.pm and $opts{NAME} from DBD::Oracle to Oracle 
> 11. Am I right about the second? Are there others I should have included?
> 
> Thanks for any help,
> Scott Smith
  

RE: Building DBD::Oracle against Oracle full installs.

[John Scoles]

 Like I first suspected Oracle has changed things about agin.
 
Not much we can do about that except keep repatching the Makefile.PL (now by 
far the largest makefile on CPAN) and hope we do not break anything else.
 
Never hurts to set  'LD_LIBRARY_PATH'  as the Makefile will have to do less 
work.  I memory servers me correctly it was needed for eailer oracle full 
intalations like 8 and early 9 then by 10 it was no longer needed but was 
needed again when the instant client came out.
 
I guess it is a case of what goes around comes around.
 
Thanks for the patch.  If you have not done so open an RT ticket and put the 
patch there.  I am sure Martin will apply it as soon as it is ready.
 
 Cheers
John
 
 

> Date: Tue, 8 Nov 2011 12:55:04 +
> From: c...@cam.ac.uk
> To: byter...@hotmail.com
> CC: dbi-users@perl.org
> Subject: Re: Building DBD::Oracle against Oracle full installs.
> 
> On 07/11/11 17:56, John Scoles wrote:
> > 
> 
> >> What am I doing wrong?
> > 
> > Most likely nothing:)
> 
> It turns out that I was doing something quite seriously wrong:(
> 
> The make file Oracle recommend for building OCI programs, such as
> DBD::Oracle, is demo-rdbms.mk (or demo-rdms32.mk - see below). These
> make files should be found in the directory $ORACLE_HOM/rdbms/demo.
> 
> In Oracle 11, these make files are not included either on the
> database media or on the client media. The are on the examples
> media.
> 
> So, to get everything you need to compile and link an OCI
> program, you need to install the examples. This will increase
> the size of your ORACLE_HOME by >600Mb. That's life.
> 
> Installing the examples completely fixed the problem for my
> data base server, on which everything is 64-bit.
> 
> However, it did NOT fix the problem on my client box, which is
> all 32-bit. On this box, Makefile.PL gave up because it could
> not find demo-rdms32.mk. This is wrong. demo-rdms32.mk is only
> shipped with 64-bit Oracle distributions. It is intended only for
> compiling 32-bit programs on 64-bit platforms. On a 32-bit
> platform, demo-rdbms.mk should be used.See
> http://download.oracle.com/docs/cd/E11882_01/server.112/e10839/prcmp_cll_int.htm#BABDGIDJ
> 
> I will prepare a patch for Maekfile.PL to do two things:
> 
> 1. Generate a warning for Oracle 11 non-instant ORACLE_HOMEs
> which do not have rdbms/demo/demo-rdbms.mk, suggesting that
> the examples should be installed.
> 2. Use demo-rdbms.mk for 32-bit compilations in 32-bit
> environments.
> 
> > Are you setting the 'LD_LIBRARY_PATH' ENV value??
> 
> I have never found this to be necessary except with Instant Clients.
> -- 
> Charles Jardine - Computing Service, University of Cambridge
> c...@cam.ac.uk Tel: +44 1223 334506, Fax: +44 1223 334679
> 
> >> Date: Mon, 7 Nov 2011 17:15:47 +
> >> From: c...@cam.ac.uk
> >> To: dbi-users@perl.org
> >> Subject: Building DBD::Oracle against Oracle full installs.
> >>
> >> Operating System: SLES 11 SP 2 on x86-64
> >> Perl: 5.14.2
> >> Oracle: 11.2.0.3.0
> >> DBD::Oracle: 1.34
> >>
> >> If I try to build DBD::Oracle against a Server installation of Oracle,
> >> the output of Makefile.PL includes the following strong warning message
> >> mentioning this mailing list. Despite the warning message, the build
> >> is successful.
> >>
> >>> + /usr/local/perl/5.14.2-A/bin/perl Makefile.PL
> >>> Using DBI 1.616 (for perl 5.014002 on x86_64-linux-thread-multi) 
> >>> installed in 
> >>> /usr/local/perl/5.14.2-A/lib/site_perl/5.14.2/x86_64-linux-thread-multi/auto/DBI/
> >>>
> >>> Configuring DBD::Oracle for perl 5.014002 on linux 
> >>> (x86_64-linux-thread-multi)
> >>>
> >>> Remember to actually *READ* the README file! Especially if you have any 
> >>> problems.
> >>>
> >>> Installing on a linux, Ver#2.6
> >>> Using Oracle in /oracle/base/orahome/11.2.0.3.0
> >>> DEFINE _SQLPLUS_RELEASE = "1102000300" (CHAR)
> >>> Oracle version 11.2.0.3 (11.2)
> >>> Found /oracle/base/orahome/11.2.0.3.0/rdbms/lib/ins_rdbms.mk
> >>> Using /oracle/base/orahome/11.2.0.3.0/rdbms/lib/ins_rdbms.mk
> >>> Your LD_LIBRARY_PATH env var is set to ''
> >>> WARNING: Your LD_LIBRARY_PATH env var doesn't include 
> >>> '/oracle/base/orahome/11.2.0.3.0/lib' but probably needs to.
> >>> Reading /oracle/base/orahome/11.2.0.3.0/rdbms/lib/ins_rdbms.mk
> >>> Reading /oracle/base/orahome/11.2.0.3.0/rdbms/lib/env_rdbms.m

RE: Building DBD::Oracle against Oracle full installs.

[John Scoles]

> What am I doing wrong?

Most likely nothing:)
 
Are you setting the 'LD_LIBRARY_PATH'  ENV value??

This sort of error Usually means Oracle has changed things around again in 
thier packaging or the client so the Makefile.PL cant't find things.
 
So the Makefile.PL has to be pathched a little to fix the problem.
 
Hard to debug without access to the box or at least a box that looks like the 
one you are trying to install on.
 
Are you using 64 bit perl?
 
cheers
John Scoles
 

> Date: Mon, 7 Nov 2011 17:15:47 +
> From: c...@cam.ac.uk
> To: dbi-users@perl.org
> Subject: Building DBD::Oracle against Oracle full installs.
> 
> Operating System: SLES 11 SP 2 on x86-64
> Perl: 5.14.2
> Oracle: 11.2.0.3.0
> DBD::Oracle: 1.34
> 
> If I try to build DBD::Oracle against a Server installation of Oracle,
> the output of Makefile.PL includes the following strong warning message
> mentioning this mailing list. Despite the warning message, the build
> is successful.
> 
> > + /usr/local/perl/5.14.2-A/bin/perl Makefile.PL
> > Using DBI 1.616 (for perl 5.014002 on x86_64-linux-thread-multi) installed 
> > in 
> > /usr/local/perl/5.14.2-A/lib/site_perl/5.14.2/x86_64-linux-thread-multi/auto/DBI/
> > 
> > Configuring DBD::Oracle for perl 5.014002 on linux 
> > (x86_64-linux-thread-multi)
> > 
> > Remember to actually *READ* the README file! Especially if you have any 
> > problems.
> > 
> > Installing on a linux, Ver#2.6
> > Using Oracle in /oracle/base/orahome/11.2.0.3.0
> > DEFINE _SQLPLUS_RELEASE = "1102000300" (CHAR)
> > Oracle version 11.2.0.3 (11.2)
> > Found /oracle/base/orahome/11.2.0.3.0/rdbms/lib/ins_rdbms.mk
> > Using /oracle/base/orahome/11.2.0.3.0/rdbms/lib/ins_rdbms.mk
> > Your LD_LIBRARY_PATH env var is set to ''
> > WARNING: Your LD_LIBRARY_PATH env var doesn't include 
> > '/oracle/base/orahome/11.2.0.3.0/lib' but probably needs to.
> > Reading /oracle/base/orahome/11.2.0.3.0/rdbms/lib/ins_rdbms.mk
> > Reading /oracle/base/orahome/11.2.0.3.0/rdbms/lib/env_rdbms.mk
> > WARNING: Oracle /oracle/base/orahome/11.2.0.3.0/rdbms/lib/ins_rdbms.mk 
> > doesn't define a 'build' rule.
> > 
> > WARNING: I will now try to guess how to build and link DBD::Oracle for 
> > you.^G
> > This kind of guess work is very error prone and Oracle-version sensitive.
> > It is possible that it won't be supported in future versions of DBD::Oracle.
> > *PLEASE* notify dbi-users about exactly _why_ you had to build it this way.
> > 
> > Found header files in /oracle/base/orahome/11.2.0.3.0/rdbms/public.
> > 
> > client_version=11.2
> 
> 
> If I try to build against a full Oracle client installation,
> I get the following fatal error. However, if I follow the advice
> given in the error message, and add the following option to the Makefile.PL
> 
> -m /local/oracle/client.11.2.0.3.0/rdbms/lib/ins_rdbms.mk
> 
> the behaviour changes, and I get a warning like the one above, and a
> successful build.
> 
> > + /local/oracle/perl/5.14.2-A/bin/perl Makefile.PL
> > Using DBI 1.616 (for perl 5.014002 on i686-linux-thread-multi) installed in 
> > /local/oracle/perl/5.14.2-A/lib/site_perl/5.14.2/i686-linux-thread-multi/auto/DBI/
> > 
> > Configuring DBD::Oracle for perl 5.014002 on linux (i686-linux-thread-multi)
> > 
> > Remember to actually *READ* the README file! Especially if you have any 
> > problems.
> > 
> > Installing on a linux, Ver#2.6
> > Using Oracle in /local/oracle/client.11.2.0.3.0
> > DEFINE _SQLPLUS_RELEASE = "1102000300" (CHAR)
> > Oracle version 11.2.0.3 (11.2)
> > 
> > Unable to locate an oracle.mk or other suitable *.mk
> > file in your Oracle installation. (I looked in
> > /local/oracle/client.11.2.0.3.0/rdbms/demo/demo_xe.mk 
> > /local/oracle/client.11.2.0.3.0/rdbms/demo/demo_rdbms32.mk under 
> > /local/oracle/client.11.2.0.3.0)
> > 
> > The oracle.mk (or demo_rdbms.mk) file is part of the Oracle
> > RDBMS product. You need to build DBD::Oracle on a
> > system which has one of these Oracle components installed.
> > (Other *.mk files such as the env_*.mk files will not work.)
> > Alternatively you can use Oracle Instant Client.
> > 
> > In the unlikely event that a suitable *.mk file is installed
> > somewhere non-standard you can specify where it is using the -m option:
> > perl Makefile.PL -m /path/to/your.mk
> > 
> > See the appropriate README file for your OS for more information and some 
> > alternatives.
> > 
> > at Makefile.PL line 1185.
> 
> What am I doing wrong?
> 
> -- 
> Charles Jardine - Computing Service, University of Cambridge
> c...@cam.ac.uk Tel: +44 1223 334506, Fax: +44 1223 334679
  

RE: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh

[John Scoles]

Glad we can help.
 
Keep us informed on how it works out
 
cheers
John
 

> Date: Thu, 27 Oct 2011 14:39:15 -0400
> From: bro...@deseret.com
> To: byter...@hotmail.com
> CC: martin.ev...@easysoft.com; dbi-users@perl.org
> Subject: Re: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh
> 
> Ok, so with the following addition to Oracle.pm
> 
> DBD::Oracle::db->install_method("ora_oci_handles");
> 
> my little test program "worked". By "worked", I mean I did
> a connect to the database, then did
> 
> my @h = $dbh->ora_oci_handles();
> 
> and it returned 4 integers (ie. the value of the pointers), which
> is what I expected/wanted.
> 
> I haven't yet tested that I can now pass these pointer values to
> the C++ libraries and have them digest it properly...but that would
> be next.
> 
> As for how much anyone else might find use for thisprobably not
> a wide audience. But it is a nice hack!
> 
> Thanks for the pointers.
> 
> Quoting John Scoles (byter...@hotmail.com):
> > 
> > 
> > > Date: Thu, 27 Oct 2011 14:14:03 -0400
> > > From: bro...@deseret.com
> > > To: martin.ev...@easysoft.com
> > > CC: dbi-users@perl.org
> > > Subject: Re: DBD-Oracle - obtaining OCI handles from $dbh
> > > 
> > > 
> > > Thanks for those pointers.
> > > 
> > > I do agree with what Martin points out. My Perl script using DBI
> > > and some XS bindings to the legacy C++ libraries would share the
> > > same address space (not using threads in my application). This
> > > is why I thought I could return the handles/pointers as scalars.
> > > 
> > > Taking John's suggestions, here is a quick code hack that I made
> > > to Oracle.xs (I haven't tested this ...other than it compiles).
> > > "Looks like it should work." ;-)
> > > 
> > > void
> > > ora_oci_handles(dbh)
> > > SV *dbh
> > > PREINIT:
> > > D_imp_dbh(dbh);
> > > PPCODE:
> > > 
> > > /* Verify what is passed in is a $dbh object */
> > > if ( ! sv_derived_from(ST(0), "DBI::db")) {
> > > Perl_croak(aTHX_ "dbh is not of type DBI::db");
> > > }
> > > 
> > > mXPUSHi( (IV) imp_dbh->envhp ); /* Environment handle */
> > > mXPUSHi( (IV) imp_dbh->svchp ); /* Service Context handle */
> > > mXPUSHi( (IV) imp_dbh->srvhp ); /* Server handle */
> > > mXPUSHi( (IV) imp_dbh->authp ); /* Session handle */
> > > 
> > > XSRETURN(4);
> > > 
> > > 
> > > Then my idea is to use this in Perl space...
> > > 
> > > my($envhp, $svchp, $srvhp, $authp) = $dbh->ora_oci_handles();
> > > 
> > > 
> > > # Now share the OCI handles from DBI with the custom
> > > # C++ libraries.
> > > 
> > > my $cpp_dbh = MyCppOracleClass->new(); # creates custom C++ object
> > > 
> > > $cpp_dbh->envhp($envhp);
> > > $cpp_dbh->svchp($svchp);
> > > $cpp_dbh->srvhp($srvhp);
> > > $cpp_dbh->authp($authp);
> > > 
> > > # Do something interesting with the C++ object
> > > 
> > > $cpp_dbh->make_legacy_call_to_db();
> > > 
> > > 
> > > 
> > 
> > Yup that should work I didn't put two and two together and figure you 
> > already had XS for the C++. 
> > 
> > It could be something we could add to DBD::Oracle but I would return all of 
> > the handles not just the few you need.
> > 
> > I wonder how much it would be used though??
> > 
> > 
> > Cheers 
> > 
> > > 
> > > 
> > > Quoting Martin J. Evans (martin.ev...@easysoft.com):
> > > > On 27/10/2011 17:43, John Scoles wrote:
> > > > >Hmm!!
> > > > >
> > > > >Well yes could be done but not as part of any release of DBD::Oracle 
> > > > >it 
> > > > >would have to be you own hacked version
> > > > >
> > > > Why is that John? What is the problem with returning a C pointer via a 
> > > > DBD::Oracle attribute? It is just a pointer to some memory and loads of 
> > > > XS modules do this. There is an Oracle OCI module I played with for a 
> > > > short time but it is problematic to build. I looked at it as I could 
> > > > implement OCI calls separately from DBD::Oracle. I don't seem the harm 
> > > > in exposing OCI handles via DBD::Oracle - it would be useful for peo

RE: DBD-Oracle - obtaining OCI handles from $dbh

[John Scoles]

> Date: Thu, 27 Oct 2011 14:14:03 -0400
> From: bro...@deseret.com
> To: martin.ev...@easysoft.com
> CC: dbi-users@perl.org
> Subject: Re: DBD-Oracle - obtaining OCI handles from $dbh
> 
> 
> Thanks for those pointers.
> 
> I do agree with what Martin points out. My Perl script using DBI
> and some XS bindings to the legacy C++ libraries would share the
> same address space (not using threads in my application). This
> is why I thought I could return the handles/pointers as scalars.
> 
> Taking John's suggestions, here is a quick code hack that I made
> to Oracle.xs (I haven't tested this ...other than it compiles).
> "Looks like it should work." ;-)
> 
> void
> ora_oci_handles(dbh)
> SV *dbh
> PREINIT:
> D_imp_dbh(dbh);
> PPCODE:
> 
> /* Verify what is passed in is a $dbh object */
> if ( ! sv_derived_from(ST(0), "DBI::db")) {
> Perl_croak(aTHX_ "dbh is not of type DBI::db");
> }
> 
> mXPUSHi( (IV) imp_dbh->envhp ); /* Environment handle */
> mXPUSHi( (IV) imp_dbh->svchp ); /* Service Context handle */
> mXPUSHi( (IV) imp_dbh->srvhp ); /* Server handle */
> mXPUSHi( (IV) imp_dbh->authp ); /* Session handle */
> 
> XSRETURN(4);
> 
> 
> Then my idea is to use this in Perl space...
> 
> my($envhp, $svchp, $srvhp, $authp) = $dbh->ora_oci_handles();
> 
> 
> # Now share the OCI handles from DBI with the custom
> # C++ libraries.
> 
> my $cpp_dbh = MyCppOracleClass->new(); # creates custom C++ object
> 
> $cpp_dbh->envhp($envhp);
> $cpp_dbh->svchp($svchp);
> $cpp_dbh->srvhp($srvhp);
> $cpp_dbh->authp($authp);
> 
> # Do something interesting with the C++ object
> 
> $cpp_dbh->make_legacy_call_to_db();
> 
> 
> 
 
Yup that should work I didn't put two and two together and figure you already 
had XS for the C++. 
 
 It could be something we could add to DBD::Oracle but I would return all of 
the handles not just the few you need.
 
I wonder how much it would be used though??
 
 
Cheers 
 
> 
> 
> Quoting Martin J. Evans (martin.ev...@easysoft.com):
> > On 27/10/2011 17:43, John Scoles wrote:
> > >Hmm!!
> > >
> > >Well yes could be done but not as part of any release of DBD::Oracle it 
> > >would have to be you own hacked version
> > >
> > Why is that John? What is the problem with returning a C pointer via a 
> > DBD::Oracle attribute? It is just a pointer to some memory and loads of 
> > XS modules do this. There is an Oracle OCI module I played with for a 
> > short time but it is problematic to build. I looked at it as I could 
> > implement OCI calls separately from DBD::Oracle. I don't seem the harm 
> > in exposing OCI handles via DBD::Oracle - it would be useful for people 
> > like the OP.
> > 
> > >A few pointers to start.
> > >
> > >You will not be able to 'get' a handle and retrun it as a Scalar it will 
> > >only ever be a pointer so you will just get some sort of number,
> > >
> > >You would simly edit the Oracle.xs file
> > >
> > >add in the includes to your C++ .h files
> > >
> > >then add a few extra
> > >
> > >'ora_'
> > >
> > >functions to take care of you C++ calls;
> > >
> > >A quick example
> > >
> > >void
> > >ora_some_c_call(dbh)
> > > SV *dbh
> > > PREINIT:
> > > D_imp_dbh(dbh); //this gets all the OCI handles for you (see dbdimp.h 
> > > for the sturct imp_dbh_st)
> > > CODE:
> > > MYSomeC_Plus_Plus_method(dbh->envhp,dbh->svchp,dbh->seshp,dbh->srvhp);
> > >
> > >
> > He does not need to do this surely. So long as the C++ code and 
> > DBD::Oracle XS is running in the same process the pointers obtained from 
> > DBD::Oracle are just as valid in the C++ code as XS. However, if the 
> > code is multi-threaded there could be issues of multiple threads 
> > accessing the OCI handles at the same time.
> > 
> > >
> > >Myself I would write a small 'c' wrapper that would call you c++ and just 
> > >a single .XS function that calls that small 'c' wrapper to fire your 
> > >function.
> > >
> > My impression was that this was already done.
> > I quote:
> > 
> > "I have created some Perl bindings for some existing custom C++ libraries."
> > 
> > Martin
> > -- 
> > 
> > Martin J. Evans
> > Easysoft Limited
> > http://www.easysoft.com
> > 
> > 
> > >Hope this helps
> 

RE: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh

[John Scoles]

 

> Date: Thu, 27 Oct 2011 18:42:23 +0100
> From: martin.ev...@easysoft.com
> To: dbi-users@perl.org
> Subject: Re: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh
> 
> On 27/10/2011 17:43, John Scoles wrote:
> > Hmm!!
> >
> > Well yes could be done but not as part of any release of DBD::Oracle it 
> > would have to be you own hacked version
> >
> Why is that John? What is the problem with returning a C pointer via a 
> DBD::Oracle attribute? It is just a pointer to some memory and loads of 
> XS modules do this. 
 
I have no real problem with this either i guess here I am talking about calling 
his functions from XS as I denonstrated below.
 
>There is an Oracle OCI module I played with for a 
> short time but it is problematic to build. I looked at it as I could 
> implement OCI calls separately from DBD::Oracle. I don't seem the harm 
> in exposing OCI handles via DBD::Oracle - it would be useful for people 
> like the OP.
>
Oh yeah the old code of Tim B.  Never could get it to compile for me. I think 
the make file is only a few lines long and is only for 9i
 
> > A few pointers to start.
> >
> > You will not be able to 'get' a handle and retrun it as a Scalar it will 
> > only ever be a pointer so you will just get some sort of number,
> >
> > You would simly edit the Oracle.xs file
> >
> > add in the includes to your C++ .h files
> >
> > then add a few extra
> >
> > 'ora_'
> >
> > functions to take care of you C++ calls;
> >
> > A quick example
> >
> > void
> > ora_some_c_call(dbh)
> > SV *dbh
> > PREINIT:
> > D_imp_dbh(dbh); //this gets all the OCI handles for you (see dbdimp.h for 
> > the sturct imp_dbh_st)
> > CODE:
> > MYSomeC_Plus_Plus_method(dbh->envhp,dbh->svchp,dbh->seshp,dbh->srvhp);
> >
> >
> He does not need to do this surely. So long as the C++ code and 
> DBD::Oracle XS is running in the same process the pointers obtained from 
> DBD::Oracle are just as valid in the C++ code as XS. However, if the 
> code is multi-threaded there could be issues of multiple threads 
> accessing the OCI handles at the same time.
> 
> >
> > Myself I would write a small 'c' wrapper that would call you c++ and just a 
> > single .XS function that calls that small 'c' wrapper to fire your function.
> >
> My impression was that this was already done.
> I quote:

> 
> "I have created some Perl bindings for some existing custom C++ libraries."
> 
 
I guess I am just reading it differntly than you.  
 
Anway best would be to see some prototye code so we can get an better Idea of 
what he wants done.
 
If you just need the pointers to the OCI handles I think there is a way to have 
a look at them in Perl.  Seems I remember doing that or seeing it done one day 
but that would be a real hack.
 
I will have to look at some code at home. It may involve getting a little to 
deep into the exe tree.
 
cheers
John
> Martin
> -- 
> 
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
> 
> 
> > Hope this helps
> >
> > Cheers
> > John
> >
> >
> >> Date: Thu, 27 Oct 2011 09:48:54 -0400
> >> From: bro...@deseret.com
> >> To: byter...@hotmail.com
> >> CC: dbi-users@perl.org
> >> Subject: Re: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh
> >>
> >> Yes, I assumed I would need to extend DBD::Oracle is some manner
> >> to allow those handles to be extracted from a $dbh object.
> >>
> >> The specific OCI handles that the C++ libraries use are
> >>
> >> - Environment handle
> >> - Service Context handle
> >> - Session handle
> >> - Server handle
> >>
> >> My initial thought process on how it might work is this
> >>
> >> Create a method in the DBD::Oracle XS code to retrieve those
> >> handles and return them back to Perl space as a scalar.
> >>
> >> Then with the Perl scalars that hold the OCI handles obtained from
> >> $dbh, pass those values to my Perl bindings to the custom C++ libraries.
> >> (I would need to extend the C++ libraries to allow the set methods
> >> to the objects that hold those OCI handles).
> >>
> >> ...then the C++ libraries should work the same.
> >>
> >> The motivation for this approach is that I have a large code base
> >> of these C++ libraries that have been tested, so it would cost
> >> prohibitive to simply replace them with a pure Perl implementation.
> >>
&g

RE: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh

[John Scoles]

Hmm!!
 
Well yes could be done but not as part of any release of DBD::Oracle it would 
have to be you own hacked version
 
A few pointers to start.
 
You will not be able to 'get' a handle and retrun it as a Scalar it will only 
ever be a pointer so you will just get some sort of number,
 
You would simly edit the Oracle.xs file
 
add in the   includes to your C++ .h files
 
then add a few extra 
 
'ora_'
 
functions to take care of you C++ calls;
 
A quick example
 
void
ora_some_c_call(dbh)
   SV *dbh
   PREINIT:
   D_imp_dbh(dbh);  //this gets all the OCI handles for you (see dbdimp.h for 
the sturct imp_dbh_st)
   CODE:
   MYSomeC_Plus_Plus_method(dbh->envhp,dbh->svchp,dbh->seshp,dbh->srvhp);
 
 
 
Myself I would write a small 'c' wrapper that would call you c++ and just a 
single .XS function that calls that small 'c' wrapper to fire your function.
 
Hope this helps
 
Cheers
John
 

> Date: Thu, 27 Oct 2011 09:48:54 -0400
> From: bro...@deseret.com
> To: byter...@hotmail.com
> CC: dbi-users@perl.org
> Subject: Re: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh
> 
> Yes, I assumed I would need to extend DBD::Oracle is some manner
> to allow those handles to be extracted from a $dbh object.
> 
> The specific OCI handles that the C++ libraries use are
> 
> - Environment handle
> - Service Context handle
> - Session handle
> - Server handle 
> 
> My initial thought process on how it might work is this
> 
> Create a method in the DBD::Oracle XS code to retrieve those
> handles and return them back to Perl space as a scalar.
> 
> Then with the Perl scalars that hold the OCI handles obtained from
> $dbh, pass those values to my Perl bindings to the custom C++ libraries.
> (I would need to extend the C++ libraries to allow the set methods
> to the objects that hold those OCI handles).
> 
> ...then the C++ libraries should work the same.
> 
> The motivation for this approach is that I have a large code base
> of these C++ libraries that have been tested, so it would cost
> prohibitive to simply replace them with a pure Perl implementation.
> 
> However, it is so much easier to work with Perl and DBI, it would
> be useful to have DBI connect to the database and do some table
> lookups. The C++ code could then be integrated seemlessly with my
> Perl code. As time allows, I would gradually peel away functionality
> from the legacy C++ libraries and implement it in Perl. But to 
> ease the migration path, this approach seemed to have some merits.
> 
> 
> Quoting John Scoles (byter...@hotmail.com):
> > 
> > 
> > 
> > 
> > > Date: Wed, 26 Oct 2011 21:46:30 -0400
> > > From: bro...@deseret.com
> > > To: dbi-users@perl.org
> > > Subject: DBD-Oracle - obtaining OCI handles from $dbh
> > > 
> > > I have created some Perl bindings for some existing custom C++ 
> > > libraries.
> > > 
> > > One of these C++ libraries implements a class that uses Oracle
> > > OCI calls.
> > > 
> > > I would like to create a connection to the Oracle database 
> > > using Perl's DBI (DBD::Oracle) module, and then ideally share
> > > that connection with the C++ libraries.
> > > 
> > > This would require me to extract the Oracle OCI handles from
> > > the $dbh object...and then pass them to the C++ libraries.
> > > 
> > > What would be the best way to get access to the underlying
> > > Oracle OCI handles from a $dbh object?
> > 
> > Hmm! Interesting concept. Which OCI handles are we talking about??
> > Like Matin said you would have to do that with .XS and you would pass I 
> > guess a pointer to the 
> > 'C' struct that holds the pointers to DBD::Oraclles pointers? 
> > 
> > You would have to cast that struct into you C++ somehow??
> > 
> > There would be a good number of handles to pass over. You might be able to 
> > find them by looking at the Perl process tree
> > and finding the SV that holds the struct and then sening that over?
> > 
> > All just guesses on my part.
> > 
> > Interesting concept non the less.
> > 
> > Cheers
> > John
> > 
  

RE: DBD-Oracle - obtaining OCI handles from $dbh

[John Scoles]

 

> Date: Wed, 26 Oct 2011 21:46:30 -0400
> From: bro...@deseret.com
> To: dbi-users@perl.org
> Subject: DBD-Oracle - obtaining OCI handles from $dbh
> 
> I have created some Perl bindings for some existing custom C++ 
> libraries.
> 
> One of these C++ libraries implements a class that uses Oracle
> OCI calls.
> 
> I would like to create a connection to the Oracle database 
> using Perl's DBI (DBD::Oracle) module, and then ideally share
> that connection with the C++ libraries.
> 
> This would require me to extract the Oracle OCI handles from
> the $dbh object...and then pass them to the C++ libraries.
> 
> What would be the best way to get access to the underlying
> Oracle OCI handles from a $dbh object?

Hmm! Interesting concept.  Which OCI handles are we talking about??
Like Matin said you would have to do that with .XS and you would pass I guess a 
pointer to the 
'C' struct that holds the pointers to DBD::Oraclles pointers? 
 
You would have to cast that struct into you C++ somehow??
 
There would be a good number of handles to pass over.  You might be able to 
find them by looking at the Perl process tree
and finding the SV that holds the struct and then sening that over?
 
All just guesses on my part.
 
Interesting concept non the less.
 
Cheers
John
  

RE: DBD::Oracle 1.25 and DRCP

[John Scoles]

No Problem  Glad to help out.  
 
And even more glad to see someone using it.
 
I tried when I wrote the DRCP code to get it to take as many conenction styles 
I could think of.  But in the very large world there are as many way to connect 
to Oracle as there are Oracle devleopers so there is bound to be a few that 
slip though the cracks. 
 
Cheers
John Scoles
 

> Date: Sat, 15 Oct 2011 15:24:59 -0400
> Subject: Re: DBD::Oracle 1.25 and DRCP
> From: frie...@gmail.com
> To: byter...@hotmail.com
> CC: dbi-users@perl.org
> 
> Thanks John!
> 
> that seems to have fixed it:
> 
> charset id=1, name=US7ASCII, ncharset id=1, name=US7ASCII
> (csid: utf8=871 al32utf8=873)
> Useing DRCP Connection
> dbd_st_prepare'd sql ALTER (pl1, auto_lob1, check_sql1)
> dbd_describe skipped for ALTER
> dbd_st_execute ALTER (out0, lob0)...
> Statement Execute Mode is 0 (DEFAULT)
> dbd_st_execute ALTER returned (SUCCESS, rpc0, fn52, out0)
> 
> 
> and I am seeing my Connection Class with Num_hits incrementing:
> 
> CCLASS_NAME
> 
> NUM_REQUESTS NUM_HITS NUM_MISSES NUM_WAITS WAIT_TIME CLIENT_REQ_TIMEOUTS
>  -- -- -- -- ---
> NUM_AUTHENTICATIONS
> ---
> $user.feedAutomation
> 3 2 1 0 0 0
> 2
> 
> I had thought defining POOLED in the tnsnames.ora was enough to pick it up.
> 
> 
> On Fri, Oct 14, 2011 at 7:12 PM, John Scoles  wrote:
> > Your connection style is not setting up DRCP.
> >
> > Consult the DBD::Oracle docs to try another way to connect using DRCP
> >
> > I would use something like this
> >
> > $dbh = DBI->connect('dbi:Oracle:DB','username','password',{ora_drcp=>1})
> >
> >
> > set the verbose to 3 and it should (if it can) show you some place in the
> > trace
> >
> > Useing DRCP Connection
> >
> > just after it reports on your NLS env
> >
> > Just need to connect no need for any qurreries etc
> >
> > cheers
> > John Scoles
> >
> >> Date: Fri, 14 Oct 2011 18:53:09 -0400
> >> Subject: Re: DBD::Oracle 1.25 and DRCP
> >> From: frie...@gmail.com
> >> To: byter...@hotmail.com
> >> CC: dbi-users@perl.org
> >>
> >> Hey John,
> >>
> >> I had to trim out some data ( mostly just Environment Variables ). let
> >> me know if there are any specific you would like to know the value of
> >> if I did not provide below. here is the rest of the output:
> >>
> >> ORACLE_HOME=/app/oracle/product/current
> >> /app/oracle/product/current -> 11.2.0.2
> >>
> >> OCINlsEnvironmentVariableGet(1,0,93,0,2)=SUCCESS
> >> OCINlsEnvironmentVariableGet(1,0,94,0,2)=SUCCESS
> >> OCIEnvNlsEnvCreate(99359fc,THREADED | OBJECT,3,0,0,0,0,0,0,1,1)=SUCCESS
> >> OCIHandleAlloc(99a1a88,9935a00,OCI_HTYPE_ERROR,0,0)=SUCCESS
> >> OCIAttrGet(99a1a88,OCI_HTYPE_ENV,7c,0,31,99d5c94)=SUCCESS
> >> OCIAttrGet(99a1a88,OCI_HTYPE_ENV,7e,0,262,99d5c94)=SUCCESS
> >> charset id=1, name=US7ASCII, ncharset id=1, name=US7ASCII
> >> (csid: utf8=871 al32utf8=873)
> >> OCIHandleAlloc(99a1a88,9935a04,OCI_HTYPE_SERVER,0,0)=SUCCESS
> >> OCIHandleAlloc(99a1a88,9935a08,OCI_HTYPE_SVCCTX,0,0)=SUCCESS
> >> OCIServerAttach(99d6438, 99d5c94, "uiis01", 6, mode=DEFAULT,0)=SUCCESS
> >> OCIAttrSet(99d5c18,OCI_HTYPE_SVCCTX,
> >> 99d6438,0,Attr=OCI_ATTR_SERVER,99d5c94)=SUCCESS
> >> OCIHandleAlloc(99a1a88,9935a0c,OCI_HTYPE_SESSION,0,0)=SUCCESS
> >> OCIAttrSet(9a017b0,OCI_HTYPE_SESSION,
> >> 98505d0,8,Attr=OCI_ATTR_USERNAME,99d5c94)=SUCCESS
> >> OCIAttrSet(9a017b0,OCI_HTYPE_SESSION,
> >> 99357a0,7,Attr=OCI_ATTR_PASSWORD,99d5c94)=SUCCESS
> >> OCISessionBegin(99d5c18,99d5c94,9a017b0,1,mode=DEFAULT 0)=SUCCESS
> >> OCIAttrSet(99d5c18,OCI_HTYPE_SVCCTX,
> >> 9a017b0,0,Attr=OCI_ATTR_SESSION,99d5c94)=SUCCESS
> >> OCIHandleAlloc(99a1a88,9a13b38,OCI_HTYPE_STMT,0,0)=SUCCESS
> >> OCIStmtPrepare(99e8914,99d5c94,'alter session set
> >> NLS_DATE_FORMAT = 'DD-MON- HH24:MI:SS'',60,1,0)=SUCCESS
> >>
> >> OCIAttrGet(99e8914,OCI_HTYPE_STMT,9a13b44,0,OCI_ATTR_STMT_TYPE,99d5c94)=SUCCESS
> >> dbd_st_prepare'd sql ALTER (pl1, auto_lob1, check_sql1)
> >> dbd_describe skipped for ALTER
> >> dbd_st_execute ALTER (out0, lob0)...
> >> Statement Execute Mode is 0 (DEFAULT)
> >> OCIStmtExecute(99d5c18,99e8914,99d5c94,1,0,0,0,mode=DEFAULT,0)=SUCCESS
>

RE: DBD::Oracle 1.25 and DRCP

[John Scoles]

Your connection style is not setting up DRCP.
 
Consult the DBD::Oracle docs to try another way to connect using DRCP
 
I would use something like this
 
$dbh = DBI->connect('dbi:Oracle:DB','username','password',{ora_drcp=>1})

 
set the verbose to 3 and it should (if it can) show you some place in the trace 
 
Useing DRCP Connection
 
just after it reports on your NLS env
 
Just need to connect no need for any qurreries etc
 
cheers
John Scoles
 

> Date: Fri, 14 Oct 2011 18:53:09 -0400
> Subject: Re: DBD::Oracle 1.25 and DRCP
> From: frie...@gmail.com
> To: byter...@hotmail.com
> CC: dbi-users@perl.org
> 
> Hey John,
> 
> I had to trim out some data ( mostly just Environment Variables ). let
> me know if there are any specific you would like to know the value of
> if I did not provide below. here is the rest of the output:
> 
> ORACLE_HOME=/app/oracle/product/current
> /app/oracle/product/current -> 11.2.0.2
> 
> OCINlsEnvironmentVariableGet(1,0,93,0,2)=SUCCESS
> OCINlsEnvironmentVariableGet(1,0,94,0,2)=SUCCESS
> OCIEnvNlsEnvCreate(99359fc,THREADED | OBJECT,3,0,0,0,0,0,0,1,1)=SUCCESS
> OCIHandleAlloc(99a1a88,9935a00,OCI_HTYPE_ERROR,0,0)=SUCCESS
> OCIAttrGet(99a1a88,OCI_HTYPE_ENV,7c,0,31,99d5c94)=SUCCESS
> OCIAttrGet(99a1a88,OCI_HTYPE_ENV,7e,0,262,99d5c94)=SUCCESS
> charset id=1, name=US7ASCII, ncharset id=1, name=US7ASCII
> (csid: utf8=871 al32utf8=873)
> OCIHandleAlloc(99a1a88,9935a04,OCI_HTYPE_SERVER,0,0)=SUCCESS
> OCIHandleAlloc(99a1a88,9935a08,OCI_HTYPE_SVCCTX,0,0)=SUCCESS
> OCIServerAttach(99d6438, 99d5c94, "uiis01", 6, mode=DEFAULT,0)=SUCCESS
> OCIAttrSet(99d5c18,OCI_HTYPE_SVCCTX,
> 99d6438,0,Attr=OCI_ATTR_SERVER,99d5c94)=SUCCESS
> OCIHandleAlloc(99a1a88,9935a0c,OCI_HTYPE_SESSION,0,0)=SUCCESS
> OCIAttrSet(9a017b0,OCI_HTYPE_SESSION,
> 98505d0,8,Attr=OCI_ATTR_USERNAME,99d5c94)=SUCCESS
> OCIAttrSet(9a017b0,OCI_HTYPE_SESSION,
> 99357a0,7,Attr=OCI_ATTR_PASSWORD,99d5c94)=SUCCESS
> OCISessionBegin(99d5c18,99d5c94,9a017b0,1,mode=DEFAULT 0)=SUCCESS
> OCIAttrSet(99d5c18,OCI_HTYPE_SVCCTX,
> 9a017b0,0,Attr=OCI_ATTR_SESSION,99d5c94)=SUCCESS
> OCIHandleAlloc(99a1a88,9a13b38,OCI_HTYPE_STMT,0,0)=SUCCESS
> OCIStmtPrepare(99e8914,99d5c94,'alter session set
> NLS_DATE_FORMAT = 'DD-MON- HH24:MI:SS'',60,1,0)=SUCCESS
> OCIAttrGet(99e8914,OCI_HTYPE_STMT,9a13b44,0,OCI_ATTR_STMT_TYPE,99d5c94)=SUCCESS
> dbd_st_prepare'd sql ALTER (pl1, auto_lob1, check_sql1)
> dbd_describe skipped for ALTER
> dbd_st_execute ALTER (out0, lob0)...
> Statement Execute Mode is 0 (DEFAULT)
> OCIStmtExecute(99d5c18,99e8914,99d5c94,1,0,0,0,mode=DEFAULT,0)=SUCCESS
> OCIAttrGet(99e8914,OCI_HTYPE_STMT,bfd81d48,0,OCI_ATTR_ROW_COUNT,99d5c94)=SUCCESS
> OCIAttrGet(99e8914,OCI_HTYPE_STMT,bfd81d4e,0,OCI_ATTR_SQLFNCODE,99d5c94)=SUCCESS
> dbd_st_execute ALTER returned (SUCCESS, rpc0, fn52, out0)
> OCIAttrGet(99e8914,OCI_HTYPE_STMT,bfd81d58,0,OCI_ATTR_ROW_COUNT,99d5c94)=SUCCESS
> dbd_st_destroy
> OCIHandleFree(99e8914,OCI_HTYPE_STMT)=SUCCESS
> OCITransRollback(99d5c18,99d5c94,mode=DEFAULT 0)=SUCCESS
> OCISessionEnd(99d5c18,99d5c94,9a017b0,mode=DEFAULT 0)=SUCCESS
> OCIServerDetach(99d6438,99d5c94,mode=DEFAULT,0)=SUCCESS
> OCIHandleFree(9a017b0,OCI_HTYPE_SESSION)=SUCCESS
> OCIHandleFree(99d5c18,OCI_HTYPE_SVCCTX)=SUCCESS
> OCIHandleFree(99d6438,OCI_HTYPE_SERVER)=SUCCESS
> OCIHandleFree(99d5c94,OCI_HTYPE_ERROR)=SUCCESS
> 
> 
> Also, passing the Sid this way works perfectly fine for connecting to
> the DB. it's just not sending through the Connection Class and I saw
> no way of just sending PURITY = SELF which is another way to do this
> per the OCI:
> 
> http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci09adv.htm#autoId34
> 
> thanks!
> -Rob
> 
> On Fri, Oct 14, 2011 at 5:52 PM, John Scoles  wrote:
> > Hard to say.
> >
> > Not sureif the way you are pasing in the sid will work.
> >
> > add dbd_verbose=>15
> >
> > to the conection options hash
> > Run the perl and post the output on this thread
> > so I can have a look at what is going on.
> >
> > Just do a simple connect no need for any other DBI stuff.
> >
> > I would also give the other flavours of connecting a try as well
> >
> > Cheers
> > John
> >
> >> Date: Fri, 14 Oct 2011 15:06:48 -0400
> >> Subject: Re: DBD::Oracle 1.25 and DRCP
> >> From: frie...@gmail.com
> >> To: dbi-users@perl.org
> >>
> >> Hey Cliff and John,
> >>
> >> on Sept 22, 2010 you posted about issues you were having with getting
> >> Oracle DRCP working using the ora_drcp_class. I am running into
> >> similar issues and was wond

RE: DBD::Oracle 1.25 and DRCP

[John Scoles]

Hard to say. 
 
Not sureif the way you are pasing in the sid will work.
 
add dbd_verbose=>15
 
to the conection options hash 
Run the perl and post the output on this thread
so I can have a look at what is going on.
 
Just do a simple connect no need for any other DBI stuff.
 
I would also give the other flavours of connecting a try as well
 
Cheers
John
 

> Date: Fri, 14 Oct 2011 15:06:48 -0400
> Subject: Re: DBD::Oracle 1.25 and DRCP
> From: frie...@gmail.com
> To: dbi-users@perl.org
> 
> Hey Cliff and John,
> 
> on Sept 22, 2010 you posted about issues you were having with getting
> Oracle DRCP working using the ora_drcp_class. I am running into
> similar issues and was wondering if you got DRCP to work and have it
> share the connection. We are using oracle 11.2.0.2 and I have perl
> v5.8.8, DBI 1.602 and DBD::Oracle 1.28.
> 
> here is my Tnsnames and basic connect string(DRCP is setup at the Listener):
> 
> $sid = (DESCRIPTION = (ADDRESS_LIST =
> (ADDRESS = (PROTOCOL = TCP)(HOST = $host)(PORT = 1521)))
> (CONNECT_DATA = (SERVICE_NAME = $service)(SERVER=POOLED)))
> 
> 
> $self->{dbh} = DBI->connect("dbi:Oracle:$config->{sid}",
> $config->{user}, $config->{pass},
> { AutoCommit => 0, ora_drcp_class =>
> "feedAutomation" } );
> 
> yet I am not seeing the $user.feedAutomation CClass and I see no
> increase in Num_hits for any class that is there:
> 
> 1* select * from v$cpool_cc_stats
> 
> CCLASS_NAME
> 
> NUM_REQUESTS NUM_HITS NUM_MISSES NUM_WAITS WAIT_TIME CLIENT_REQ_TIMEOUTS
>  -- -- -- -- ---
> NUM_AUTHENTICATIONS
> ---
> 
> $user.SHARED
> 1346245 0 1346245 61582 0 0
> 1346245
> 
> Everything runs fine, it just doesn't share the connections and
> increase Num_hits.
> 
> any thoughts?
> 
> thanks!
> -Rob
  

RE: DBD::ODBC fails, SQL*Plus works

[John Scoles]

 Why even use DBD::ODBC?
 
Why not use DBD::Oracle?
 
Cheers
John
 

> Subject: Re: DBD::ODBC fails, SQL*Plus works
> From: john...@pharmacy.arizona.edu
> Date: Wed, 5 Oct 2011 10:53:48 -0700
> CC: dbi-users@perl.org
> 
> 
> On Oct 5, 2011, at 9:09 AM, Scott Stansbury wrote:
> 
> > 
> > It returns (after a few seconds) with an ORA-12154 error: TNS:could not 
> > resolve the connect identifier specified ( SQL-08004).
> 
> 
> Basic questions: the script is running in an environment where the env 
> variables $ORACLE_HOME and $TNS_ADMIN are available? Your tnsnames.ora file 
> is present and correct?
> 
> (if not, the those vars and put this:
> 
> PROD77 = 
> (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.15.200)(PORT=1535)))(CONNECT_DATA=(SID=PROD77)))
> 
> in a text file, save it as tnsnames.ora in your $ORACLE_HOME directory and 
> see if it works now)
> 
> -- 
> Bruce Johnson
> University of Arizona
> College of Pharmacy
> Information Technology Group
> 
> Institutions do not have opinions, merely customs
> 
> 
  

RE: DBI Proxy + transactions

[John Scoles]

I would hope it would depend on which type of DB you are trying to proxy to. 
 
If the DB at the other end of the proxy does not support 'begin_work' and 
'commit' or 'transactions'  then DBI Proxy will not magically enable it.
 
What flavour of DB is behind the proxy??
 
I have never used it for this just for cache of selects but the above would be 
one place to start.
 
Cheers
John 

 

> Subject: DBI Proxy + transactions
> From: bori...@fides.com
> To: dbi-users@perl.org
> Date: Tue, 4 Oct 2011 19:58:59 +0400
> 
> Hi!
> 
> Tell me, please, how can I use db transactions ( $dbh->begin_work() ...
> $dbh->commit() ) with DBI Proxy ?
> 
> --
> With regards,
> Borissov Pavel
> 
> 
  

RE: Connecting to Oracle 11g with perl 5.6.1

[John Scoles]

 Well you DBI is about 55+ updates behind and your DBD::Oracle is about 13 
behind.
 
I would say update both.
 
The error below is telling my you are still using a very old way to connect to 
Oracle which I think has been dropped in 11+ and dropped from DBD::Oracle in I 
think 1.11
 
hope this helps
 
Cheers
John Scoles
 

> Subject: Connecting to Oracle 11g with perl 5.6.1
> Date: Tue, 4 Oct 2011 21:04:16 +0530
> From: s...@cisco.com
> To: dbi-users@perl.org
> 
> Hi,
> 
> 
> 
> I have a perl program that is using Perl 5.6.1 and Oracle 10g. We have
> migrated the database from 10g to 11g. I modified ORACLE_HOME to use 11g
> database. However, now the program fails with,
> 
> 
> 
> ORA-06401: NETCMN: invalid driver designator (DBD ERROR:
> OCIServerAttach)
> 
> 
> 
> Anything else that I need to take care of when moving from 10g to 11g?
> Should I updated DBI or DBD::Oracle modules? These are the current
> versions that am using,
> 
> 
> 
> DBI: 1.18
> 
> DBD::Oracle - 1.07
> 
> 
> 
> Thanks,
> 
> Shobha Deepthi V
> 
> 
> 
  

RE: Tail Module + DBI Module, can\'t keep up!

[John Scoles]

 

> Date: Thu, 15 Sep 2011 09:26:41 -0700
> From: tigerpeng2...@yahoo.com
> Subject: Re: Tail Module + DBI Module, can\'t keep up!
> To: bphe...@gls.com
> CC: dbi-users@perl.org
> 
> Separate the process into two steps and figure out which step should be fixed 
> first.
> 
> 1. Parse the log with Tail and dump the data to plain file.
> 2. Load the plain file with DBI (are you using batch insert?)

 
This would be my stratigy as well.  you could also give the insert_array at try 
but I do not think that will give you much as you are useing MySQL but at lease 
you could use one script that
 
1) Bufferes  up X-n records to insert in an array/arrays
2) at buffer X do an insert with  execute_array
3) carry on burrering up the array.
 
one other thing to look out for is to make sure you are not 'prepareing' the 
same SQL over and over agian.  If you have only 1 query just prepare it once 
and reuse tha handle.  Also make sure you are not trying to reconnect each time 
as both of these actions are rather heavy on resources.
 
Cheers
John  

RE: Need help with DBI connect

[John Scoles]

You will most likely have to reinstall DBD::Oracle and the Oracle client one 
your new target linux box
 
try
 
Perl -MDBD::Oracle -e 'print DBD::Oracle::VERSION'
 
To see if it is installed on your new box.
 
If not you will have to get it from CPAN as well as an Oracle Client 
 
I would use the instant client which you can get here
 
http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html
 CheersJohn

> Subject: Need help with DBI connect
> Date: Mon, 12 Sep 2011 10:18:05 -0500
> From: khushboo.chokh...@bestbuy.com
> To: dbi-users@perl.org
> 
> Hi,
> 
> 
> 
> I have been stuck with this error since long now, and have tried almost
> everything available on web but no luckL
> 
> Any help would be greatly appreciated.
> 
> 
> 
> When I try to execute a PERL scripts I am getting an error:
> 
> 
> 
> ORACLE_HOME=/u01/app/oracle/product/10.2.0
> 
> TNS_ADMIN=/usr/local/tns
> 
> Can't locate object method "connect" via package "DBI" at
> /opt/mabl/agg/dgt/batch-proc/contentdownload/PROD-BBY/bin/DeltaFlag.pm
> line 67.
> 
> 
> 
> Before getting this error, I was getting an error where the script was
> not able to locate the DBI.pm module, hence I pointed my script to use
> the below path to locate DBI.pm:
> 
> 
> 
> /u01/app/oracle/product/10.2.0/perl/lib/site_perl/5.8.3/Apache
> 
> 
> 
> We are migrating from HPUX system to Linux, hence the scripts which we
> have been using since long are not working as is and they require some
> changes.
> 
> 
> 
> Pls help!
> 
> 
> 
> Thanks!
> 
> 
> 
> Khushboo Chokhani
> 
> Wipro Technologies
> Mobile : +1 (612)-354-1243
> 
> 
> 
> 
> 
  

RE: Turn off "Issuing rollback..." warning for AutoCommit.

[John Scoles]

I think you can turn that one off by using WARN
 
http://search.cpan.org/~timb/DBI-1.616/DBI.pm#Warn
 
if memory serves me correctly it is a true 'warn()'  and not a PrintWarn.
 
It is very deep in the code.  I think in Driver.xst.
 
It is at the DBI side of things and has nothing to to with DBD::Oracle
 
Not sure if this will work in  DBI 1.30 though as I do not have that code base 
arount to look at.
 
Hope this helps
 
cheers
John
 

> Subject: Re: Turn off "Issuing rollback..." warning for AutoCommit.
> From: da...@kineticode.com
> Date: Wed, 24 Aug 2011 09:52:22 -0700
> CC: dbi-users@perl.org
> To: tigerpeng2...@yahoo.com
> 
> On Aug 24, 2011, at 7:51 AM, tiger peng wrote:
> 
> > I am subclassing DBI for authenticating purpose by overwriting connection.
> > 
> > I try to turn off warning message "Issuing rollback() for database handle 
> > being DESTROY'd without explicit disconnect()" by explicitly issuing 
> > rollback, disconnect and set AutoCommit to 0 without success. Could you 
> > please provide any solution and/or suggestion? My environment is quite old 
> > (Perl/5.80; DBI/1.30; DBD::Oracle/1.12).
> 
> Well first of all, upgrade Perl and those modules, if at all possible. That 
> DBI is NINE YEARS OLD!
> 
> As for the warning, what I generally do is disconnect in an END block right 
> after I connect, like so:
> 
> my $dbh = DBI->connect('dbi:Oracle:...');
> 
> END { $dbh->disconnect if $dbh }
> 
> I also recommend against having AutoCommit set to 0, as that means you have a 
> transaction open all the time. You should just use transactions when you have 
> reason to use them, that is for database writes.
> 
> Best,
> 
> David
> 
  

RE: Perl to connect Netezza

[John Scoles]

Doesn't seem to be a DBD for Netezza  but you can connect though 'ODBC'  so you 
will be able to use DBI.  
 
Perhaps in the long run you might want to write a DBD yourself as long as there 
is some sort of interface from IBM.
 
Doesn't seem to be much of anything on Netezza  on CPAN yet.
 
Cheers
 

 

> Date: Mon, 8 Aug 2011 14:58:58 +0530
> Subject: Perl to connect Netezza
> From: chote2cha...@gmail.com
> To: dbi-users@perl.org
> 
> Hi,
> 
> I'm working in an MNC. I have a new requirement where I have to connect to
> Netezza using perl. I would like to know whether I can use DBI module to
> connect to Netezza using perl. I would also like to know whether any special
> modules need to be installed for this purpose or is there any other better
> procedure?
> 
> Please provide your valuable inputs.
> 
> Thanks & Regards,
> Gauz.
  

RE: Reading hebrew from oracle - get ??????

[John Scoles]

Check the NLS_LANG and other local ENV setting such as Country etc. setting on 
the box where your client resides. 
 
 You might have to change it to one that can display.
 
Make sure the data is going in correctly first and that your display can 
display it.
 
Hope this helps.
 
Cheers
John
 

> From: shlomit.af...@weizmann.ac.il
> To: dbi-users@perl.org
> CC: shlomit.af...@weizmann.ac.il
> Subject: Reading hebrew from oracle - get ??
> Date: Mon, 18 Jul 2011 09:38:20 +
> 
> 
> 
> Hi,
> 
> I'm trying to connect to oracle server by oracle client with DBD.
> When I read Hebrew information, I get it as a lot of questions mark. 
> ().
> The information in the oracle is UTF8 and I build the xml file that hold of 
> the information I read with UTF8.
> 
> Is someone know why? What I'm doing wrong?
> 
> Shlomit.
  

RE: Segmentation fault

[John Scoles]

We will need a little more to go on than that.  At a min we need
 
1) DBI version
2) DBD driver name and version
3) Database system name and version
4) OS
 
What would be perfect is a perl script that recreates the error.
 
 
Cheers
DBI users
 
> Subject: Segmentation fault
> Date: Mon, 6 Jun 2011 20:01:32 +0530
> From: venkateswarara...@cognizant.com
> To: dbi-users@perl.org
> 
> Hi,
> 
> 
> 
> I am getting error like the follows.
> 
> 
> 
> server bbmkscretl01 gave "1709 Segmentation Fault(core dump)" error when
> tried to execute a script which calls truncate query inside the 
> 
> script.
> 
> 
> 
> Can you please help me out.
> 
> 
> 
> 
> 
> 
> 
> 
> This e-mail and any files transmitted with it are for the sole use of the 
> intended recipient(s) and may contain confidential and privileged information.
> If you are not the intended recipient, please contact the sender by reply 
> e-mail and destroy all copies of the original message.
> Any unauthorized review, use, disclosure, dissemination, forwarding, printing 
> or copying of this email or any action taken in reliance on this e-mail is 
> strictly prohibited and may be unlawful.
  

RE: perl DBI Oracle NCLOB fetching

[John Scoles]

Well if you can't change you DBD there may not be any other 'Majick'  that you 
will be able to do to fix this.
 
You might was to install one of the 'instantclients' and see what you get the 
same error.
 
the dbd_verbose was for 22 or later for dbi so that would be normal.
 
Try a trace=>10 but you will get a whold lot more tracing
 
 
 
Cheers
John 
> Date: Mon, 6 Jun 2011 10:57:24 +0200
> From: y...@mailueberfall.de
> Subject: Re: RE: perl DBI Oracle NCLOB fetching
> To: byter...@hotmail.com; dbi-users@perl.org
> 
> Hello,
> 
> setting dbd_verbose leads to no additional output. It's only:
> 
> DBD::Oracle::st fetchrow_arrayref failed: ORA-24806: LOB form mismatch (DBD 
> ERROR: OCILobRead) [for Statement "select * from ttt where rownum <2"] at 
> s.pl line 15.
> record couldn't be fetched!! at s.pl line 15.
> 
> It seems that I can't install a newer DBI or DBD version. The Perlscipt has 
> to run on this (our productive) environment.
> 
> Here my script:
> 
> #!/usr/local/bin/perl
> 
> use DBI;
> use strict;
> 
> my $dbh = DBI->connect('DBI:Oracle:db','u','p',{dbd_verbose => 9}) or die "No 
> database connection!";
> $dbh->{LongReadLen} = 16384; # set buffer length for blobs
> # session settings
> my $sth = $dbh->prepare("alter session set 
> NLS_DATE_FORMAT='-MM-DD_hh24:mi:ss'") or die "No prepare: ".DBI->errstr;
> $sth->execute or die "No exec".$sth->errstr;
> $sth->finish();
> 
> my $sthRow = $dbh->prepare("select * from ttt where rownum <2") or die 
> "Prepare of Database query failed!";
> $sthRow->execute() or die "Execution of database query failed!";
> $sthRow->fetchrow_arrayref or die "record couldn't be fetched!!";
> ---
> 
> 
> DBD Version:
> $Revision: 11.21 $
> 
> SQL> show parameter nls
> 
> NAME TYPE VALUE
>  --- 
> --
> nls_calendar string
> nls_comp string
> nls_currency string
> nls_date_format string
> nls_date_language string
> nls_dual_currency string
> nls_iso_currency string
> nls_language string AMERICAN
> nls_length_semantics string CHAR
> nls_nchar_conv_excp string FALSE
> nls_numeric_characters string
> 
> NAME TYPE VALUE
>  --- 
> --
> nls_sort string
> nls_territory string AMERICA
> nls_time_format string
> nls_time_tz_format string
> nls_timestamp_format string
> nls_timestamp_tz_format string
> SQL>
> 
> yoyo
> 
> 
>  Original-Nachricht 
> > Datum: Fri, 3 Jun 2011 13:27:54 -0400
> > Von: John Scoles 
> > An: y...@mailueberfall.de, dbi-users@perl.org
> > Betreff: RE: perl DBI Oracle NCLOB fetching
> 
> > 
> > That only ocures when the nclob going in is not compatiable with the nclob
> > field you are trying to stuff it into.
> > 
> > one thing that wil give us a little more info is to connect with
> > dbd_verbose=9 on the attributes and that will tell us you NSL setting.
> > 
> > also get your DBA to check 
> > 
> > NLS_CHARACTERSET
> > NLS_NCHAR_CHARACTERSET
> > NLS_LANGUAGE
> > NLS_TERRITORY
> > 
> > 
> > These should all match up.
> > 
> > Your DBI is rather old what is you version of DBD::Oracle
> > 
> > you might want to upgrade both
> > 
> > Cheers
> > John
> > 
> > 
> > > Date: Fri, 3 Jun 2011 19:03:46 +0200
> > > From: y...@mailueberfall.de
> > > To: dbi-users@perl.org
> > > Subject: perl DBI Oracle NCLOB fetching
> > > 
> > > Hello,
> > > 
> > > my Perl script uses uses the DBI interface to connect to Oracle and runs
> > > a select statement. But if one column is of type NCLOB it fails with:
> > > 
> > > DBD::Oracle::st fetchrow_hashref failed: ORA-24806: LOB form mismatch
> > > (DBD ERROR: OCILobRead) [for Statement "SELECT * FROM ttt WHERE
> > ROWNUM=1"]
> > > 
> > > I googled a lot and didn't found any solution for it. According to the
> > > used versions of Perl, DBI and Oracle and the NLS settings it should
> > work.
> > > 
> > > Any idea how to get it working?
> > > 
> > > Here are my used versions:
> > > 
> > > DBI::VERSION = "1.41"
> > > perl, v5.8.0
> > > 
> > > SQL> desc ttt
> > > Name Null? Type
> > > 
> > > T1 NCLOB
> > > UMSISDN VARCHAR2(200 CHAR)
> > > SPARTID NUMBER(2)
> > > 
> > > bash-3.00$ env | grep -i nls
> > > NLS_LANG=AMERICAN_AMERICA.UTF8
> > >
> > NLSPATH=:/export/home/omni/locale/%L/%N.cat:/export/home/omni/locale/%L/%N
> > > 
> > > Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit
> > Production
> > > 
> > > much thanks,
> > > yoyo
> > > 
> > 
> 
> -- 
> NEU: FreePhone - kostenlos mobil telefonieren! 
> Jetzt informieren: http://www.gmx.net/de/go/freephone
  

RE: perl DBI Oracle NCLOB fetching

[John Scoles]

That only ocures when the nclob going in is not compatiable with the nclob 
field you are trying to stuff it into.
 
one thing that wil give us a little more info is to connect with dbd_verbose=9 
on the attributes and that will tell us you NSL setting.
 
also get your DBA to check 
 
NLS_CHARACTERSET
NLS_NCHAR_CHARACTERSET
NLS_LANGUAGE
NLS_TERRITORY
 
 
These should all match up.
 
Your DBI is rather old what is you version of DBD::Oracle
 
you might want to upgrade both
 
Cheers
John

 
> Date: Fri, 3 Jun 2011 19:03:46 +0200
> From: y...@mailueberfall.de
> To: dbi-users@perl.org
> Subject: perl DBI Oracle NCLOB fetching
> 
> Hello,
> 
> my Perl script uses uses the DBI interface to connect to Oracle and runs
> a select statement. But if one column is of type NCLOB it fails with:
> 
> DBD::Oracle::st fetchrow_hashref failed: ORA-24806: LOB form mismatch
> (DBD ERROR: OCILobRead) [for Statement "SELECT * FROM ttt WHERE ROWNUM=1"]
> 
> I googled a lot and didn't found any solution for it. According to the
> used versions of Perl, DBI and Oracle and the NLS settings it should work.
> 
> Any idea how to get it working?
> 
> Here are my used versions:
> 
> DBI::VERSION = "1.41"
> perl, v5.8.0
> 
> SQL> desc ttt
> Name Null? Type
> 
> T1 NCLOB
> UMSISDN VARCHAR2(200 CHAR)
> SPARTID NUMBER(2)
> 
> bash-3.00$ env | grep -i nls
> NLS_LANG=AMERICAN_AMERICA.UTF8
> NLSPATH=:/export/home/omni/locale/%L/%N.cat:/export/home/omni/locale/%L/%N
> 
> Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
> 
> much thanks,
> yoyo
> 
  

RE: DBD::Sybase and DBI->get_info()

[John Scoles]

Well looking at the code there does not seem to be any get_info in DBD::Sybase  
so I think you are out of luck
 
Cheers
John
 
> From: eric.b...@barclayscapital.com
> To: dbi-users@perl.org
> Date: Fri, 3 Jun 2011 11:38:59 -0400
> Subject: DBD::Sybase and DBI->get_info()
> 
> As we migrate our codebase from Sybase (DBD::Sybase) to MS SQL (DBD::ODBC), 
> it would be helpful to have low-level info about the drivers available, and 
> it seems that the DBI->get_info() method is the place to go for that. It is 
> supported adequately in DBD::ODBC, but it appears that DBD::Sybase doesn't 
> support get_info().
> 
> Am I missing something about using get_info(), or does DBD::Sybase provide 
> low-level driver info another way?
> 
> Any idea how to get info out of DBD::Sybase?
> 
> Thanks.
> 
> Eric
> 
> ___
> 
> This e-mail may contain information that is confidential, privileged or 
> otherwise protected from disclosure. If you are not an intended recipient of 
> this e-mail, do not duplicate or redistribute it by any means. Please delete 
> it and any attachments and notify the sender that you have received it in 
> error. Unless specifically indicated, this e-mail is not an offer to buy or 
> sell or a solicitation to buy or sell any securities, investment products or 
> other financial product or service, an official confirmation of any 
> transaction, or an official statement of Barclays. Any views or opinions 
> presented are solely those of the author and do not necessarily represent 
> those of Barclays. This e-mail is subject to terms available at the following 
> link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent 
> to the foregoing. Barclays Capital is the investment banking division of 
> Barclays Bank PLC, a company registered in England (number 1026167) with its 
> registered office at 1 Churchill Place, London, E14 5HP. This email may 
> relate to or be sent from other members of the Barclays Group.
> ___
  

RE: Need Help with DBI for oracle

[John Scoles]

Simple connection problem.
 
Try to connect SQLPlus if you can do that then you can use DBD::Oracel
 
Try the same connection string in DBD:Oracle
 
Hope this helps
 
cheers
John 
> CC: dbi-users@perl.org
> From: jona...@gmail.com
> Subject: Re: Need Help with DBI for oracle
> Date: Fri, 3 Jun 2011 16:05:23 +0200
> To: ganesh.b.ben...@gmail.com
> 
> As you can read from the error message is not interpolated, exchange the 
> single quotes for double quotes. Sorry for the abrupt response, but I am in 
> transit
> 
> jonasbn
> 
> Sent from my iPhone
> 
> On 02/06/2011, at 15.47, Ganesh Bendre  wrote:
> 
> > Hi,
> > 
> > I am using the following code for fetching some data.
> > but not able to connect
> > 
> > *CODE:*
> > #!C:/Perl/bin/perl.exe
> > 
> > use DBI;
> > use DBD::Oracle;
> > 
> > print "Content-type: text/html \n\n";
> > 
> > $platform = "ORACLE";
> > $database = "I8Q.GRP.COM";
> > $tablename = "COUNTY_ADD";
> > $user = "dba";
> > $pw = "dbapass";
> > 
> > $dsn = 'dbi:Oracle:$database:in-gh01:1521';
> > 
> > $connect = DBI->connect($dsn, $user, $pw);
> > 
> > $query = "select ctycode,ctydesc from county_add";
> > $query_handle = $connect->prepare($query);
> > 
> > $query_handle->execute();
> > 
> > $query_handle->bind_columns(undef, \$ctycode, \$ctydesc);
> > 
> > while($query_handle->fetch()) {
> > print "$ctycode, $ctydesc ";
> > }
> > *CODE END*
> > **
> > **
> > I am getting the following error when i try to run the above code
> > **
> > *Error:*
> > DBI connect('$database:in-gh01:1521','dba',...) failed: ORA-06401: NETCMN:
> > id driver designator (DBD ERROR: OCIServerAttach) at exequery2.pl line 21
> > Can't call method "prepare" on an undefined value at exequery2.pl line 25.
> > *Error END*
> > 
> > *I have installed *
> > *DBD::Oracle*
> > *DBI*
> > **
> > **
> > *i am stuck with this for almost one week
> > Please help me out*
> > **
> > *Ganesh.*
> > **
  

RE: AIX 5.3 DBD::Oracle issues

[John Scoles]

Well in that case bounce back to 1.25 which does not use OCIPing and you should 
be ok.
 
Also check which oracle client versions are on both boxes Credits to Navy Beans 
that they are different.
 
Cheers
John
> From: stephen.willi...@twcable.com
> To: dbi-users@perl.org
> Date: Wed, 25 May 2011 17:05:19 -0400
> Subject: RE: AIX 5.3 DBD::Oracle issues
> 
> Sorry I did forget to include that I am working with 1.27. I checked the 
> oci.def and OCIPing is in it. I am very perplexed as this same install worked 
> fine on another node.
> 
> From: John Scoles [mailto:byter...@hotmail.com]
> Sent: Wednesday, May 25, 2011 4:57 PM
> To: Williams, Stephen; dbi-usin...@perl.org
> Subject: RE: AIX 5.3 DBD::Oracle issues
> 
> Like the error message says "OCIPing" is not present in you Oracle.so file.
> 
> Can be cured a number of ways.
> 
> 1) check and see if OCIPing is in the OCI.def file of the version of 
> DBD::Oracel you have installed.
> 2) If it is not there add it and reinstall
> 
> If the above does not work try a version of DBD::Oracle lower than 1.25 or a 
> newer version like 1.27+
> 
> You did not say which version of DBD::oracle you were using.
> 
> cheers
> John
> 
> > From: stephen.willi...@twcable.com
> > To: dbi-usin...@perl.org<mailto:dbi-usin...@perl.org>
> > Date: Wed, 25 May 2011 16:04:37 -0400
> > Subject: AIX 5.3 DBD::Oracle issues
> >
> > Afternoon all! I have installed a standalone install of Perl and 
> > DBI/DBD::Oracle on my AIX 5.3 TL9 SP7 I have this working fine on two boxes 
> > but on one I keep getting the below error when I try a simple test 
> > connection. Has anyone seen this or know what may be wrong? I have been 
> > searching for an answer but have yet to turn anything up.
> >
> > ./foo
> > install_driver(Oracle) failed: Can't load 
> > '/product/cvc/perl5.12.3_64bit/lib/site_perl/5.12.3/aix-thread-multi-64all/auto/DBD/Oracle/Oracle.so'
> >  for module DBD::Oracle: rtld: 0712-001 Symbol OCIPing was referenced
> > from module 
> > /product/cvc/perl5.12.3_64bit/lib/site_perl/5.12.3/aix-thread-multi-64all/auto/DBD/Oracle/Oracle.so(),
> >  but a runtime definition
> > of the symbol was not found.
> > rtld: 0712-002 fatal error: exiting. at 
> > /product/cvc/perl5.12.3_64bit/lib/5.12.3/aix-thread-multi-64all/DynaLoader.pm
> >  line 200.
> > at (eval 3) line 3
> > Compilation failed in require at (eval 3) line 3.
> > Perhaps a required shared library or dll isn't installed where expected
> > at ./foo line 10
> >
> > Perl configuration
> >
> > /product/cvc/perl/bin/perl -V
> > Summary of my perl5 (revision 5 version 12 subversion 3) configuration:
> >
> > Platform:
> > osname=aix, osvers=5.3.0.0, archname=aix-thread-multi-64all
> > uname='aix cvcpstg01 3 5 00c510fc4c00 '
> > config_args='-d -Dcc=gcc -Duseshrplib -Dusethreads -Duse64bitall 
> > -Dprefix=/product/cvc/perl5.12.3_64bit -s'
> > hint=recommended, useposix=true, d_sigaction=define
> > useithreads=define, usemultiplicity=define
> > useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
> > use64bitint=define, use64bitall=define, uselongdouble=undef
> > usemymalloc=n, bincompat5005=undef
> > Compiler:
> > cc='gcc -maix64', ccflags ='-D_THREAD_SAFE -D_ALL_SOURCE -D_ANSI_C_SOURCE 
> > -D_POSIX_SOURCE -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT 
> > -fno-strict-aliasing -pipe -maix64 -DUSE_64_BIT_ALL',
> > optimize='-O',
> > cppflags='-D_THREAD_SAFE -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE 
> > -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -fno-strict-aliasing -pipe'
> > ccversion='', gccversion='4.2.0', gccosandvers=''
> > intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
> > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
> > ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
> > lseeksize=8
> > alignbytes=8, prototype=define
> > Linker and Libraries:
> > ld='gcc -maix64', ldflags =' -Wl,-brtl -Wl,-bdynamic -L/usr/local/lib 
> > -Wl,-b64'
> > libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
> > libs=-lbind -lnsl -ldbm -ldl -lld -lm -lcrypt -lpthreads -lc
> > perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc
> > libc=/lib/libc.a, so=a, useshrplib=true, libperl=libperl.a
> > gnulibc_version=''
> > Dynamic Linking:
> > dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Xlinker 
> &g

RE: (Fwd) Question about DBD::Oracle

[John Scoles]

Hmm talk about ancient history.
 
Not a but in either me thinks
 
I believe this is the default behaviour of early  OCI clients like OCI 7 to 
trim all varchars.  This changed for some reason by Oracle in 
OCI 8 and then changed again by Oracle in 9 and later clients.  There are 
different ways the various clients handle null terminated strings as well which 
is another kettle of fish.
 
The short of it is since 9 there has been no changes but eailer version there 
where a number of different ways of handling trailing spaces.
 
Correct me if I am wrong Tim but I do not think it is a bug in DBD::Oracle just 
different implementations on OCI clients.
 
Hope this helps
 
cheers
John
 
> Date: Tue, 24 May 2011 14:40:54 +0100
> From: tim.bu...@pobox.com
> To: dbi-users@perl.org
> CC: sumiy...@tradewintech.co.jp
> Subject: (Fwd) Question about DBD::Oracle
> 
> - Forwarded message from Sumiya  -
> 
> Date: Wed, 16 Mar 2011 09:19:15 +0900
> From: Sumiya 
> To: tim.bu...@pobox.com
> Subject: Question about DBD::Oracle
> 
> Dear Mr. Tim Bunce,
> 
> I would like to ask you about DBD::Oracle.
> Would you tell me what makes difference behaviourbetween
> OCI 8 and OCI 9.2 on ORA_VARCHAR2?
> Is is a bug of DBD or OCI?
> Please explain more detail.
> 
> 
> http://search.cpan.org/~pythian/DBD-Oracle-1.27/Oracle.pm#Connect_Attributes
> 
> ORA_VARCHAR2
> Oracle clients using OCI 8 will strip trailing spaces and allow embedded
> \0 bytes. Oracle clients using OCI 9.2 do not strip trailing spaces and
> allow embedded \0 bytes. This is the normal default placeholder type.
> 
> 
> Yours faithfully,
> 
> Kiyoshi Sumiya,
> 
> 
> 
> 
> 
> 
> 
> - End forwarded message -
  

RE: (Fwd) Re: DBD::Oracle Slow cursors

[John Scoles]

Why are you asking for help on a Perl Mailing list then???
 
There is nothing we can do for you here it is PLSQL problem.
 
I have some expreriance in PLSQL and all I can know is that sys_refcursors are 
allways going to be slower than direct calls with SQLPlus.
 
Not sure how we can help you here.
 

 Perhaps you should rethink the refcursor idea or try spliting it up into two 
or more calls
 
Cheers


From: jaha...@idexcel.com
To: byter...@hotmail.com; martin.ev...@easysoft.com; dbi-users@perl.org; 
carlso...@llnl.gov; tim.bu...@pobox.com
Subject: RE: (Fwd) Re: DBD::Oracle Slow cursors
Date: Wed, 18 May 2011 13:03:34 +0100










John,
 
Irrespective of I calling in Java or executing it on the SQL developer or in 
TOAD, I am getting the same response time when compared to executing the SQL’s 
separately
 
Regards
P S Jameel Ahamed 
 




From: John Scoles [mailto:byter...@hotmail.com] 
Sent: 18 May 2011 12:21
To: jaha...@idexcel.com; Martin Evans; dbi-users@perl.org; carlso...@llnl.gov; 
Tim Bunce
Subject: RE: (Fwd) Re: DBD::Oracle Slow cursors
 
Does this have anything to do at all with DBD::Oracle???
You mentioned you are calling this with JAVA??
 
Where is the Perl code??
 
> From: jaha...@idexcel.com
> To: martin.ev...@easysoft.com; dbi-users@perl.org; byter...@hotmail.com; 
> carlso...@llnl.gov; tim.bu...@pobox.com
> Subject: RE: (Fwd) Re: DBD::Oracle Slow cursors
> Date: Wed, 18 May 2011 11:07:56 +0100
> 
> Hi All,
> 
> First of all I thank you all in replying to my email. Below are details of
> one of the SP which we are having issues with.
> 
> In the below SP we are passing in a Username and then for that user are
> fetching his counts and other information. The output parameter is a
> sys_refcursur.
> 
> The problem is that when I fire each and every insert and select statement,
> Its firing in 0.2 seconds. But when retrieving these details in the java
> code when it come to the line to loop the cursor then it gets struck for
> about 2 to 3 mins and the response is coming back.
> 
> We have seen this behavior in most of the places where we used this
> sys_refcursur. 
> 
> The table circuit is a huge table of million records and it has all the
> indexces in place and other tables as well.
> 
> I have been googleing for a long time for a solution for this sys-refcursor
> issue and I am not sure why its going back to the DB after executing the SP
> while looping through the cursor.
> 
> We have Oracle 10G 10.1.0.4.
> 
> I have also tried to combain all the select statements into one using the
> UNION command and insert into the tbl_qm_dashboard. The insert fires in 1.12
> seconds, but again the cursuor looping is the issue.
> 
> Note : tbl_qm_dashboard is a temp table.
> 
> Hope I will get an break through with all your expertise.
> 
> PROCEDURE sp_select_dashboard(strUser IN VARCHAR2,
> rcSelectDashboard OUT SYS_REFCURSOR) IS
> 
> BEGIN
> 
> EXECUTE IMMEDIATE 'ALTER SESSION SET
> NLS_COMP=LINGUISTIC';
> EXECUTE IMMEDIATE 'ALTER SESSION SET
> NLS_SORT=BINARY_CI';
> 
> 
> INSERT INTO tbl_qm_dashboard
> SELECT
> dashboard_type,NVL(active_cnt,0),NVL((age/DECODE(active_cnt,0,1,active_cnt))
> ,0)avg_age,NVL(active_old_5days,0),NVL(closed_old_5days,0),NVL((response_old
> _5days/DECODE(closed_old_5days,0,1,closed_old_5days)),0)
> avg_response_old5days
> FROM
> (
> SELECT 'AccessCircuit' dashboard_type,
> SUM(case when (A.ot_queue_status_id IN(1,2) AND
> ((C.status_id <> 3) OR (C.status_id = 3 AND C.circuit_current_stage = 3)))
> then 1 else 0 END ) active_cnt,
> SUM(case when (A.ot_queue_status_id IN(1,2) AND
> ((C.status_id <> 3) OR (C.status_id = 3 AND C.circuit_current_stage = 3)))
> then (SYSDATE - c.created_on) else 0 END ) age,
> SUM(case when (c.created_on <= (sysdate - 5) AND
> A.ot_queue_status_id IN(1,2) AND ((C.status_id <> 3) OR (C.status_id = 3
> AND C.circuit_current_stage = 3))) then 1 else 0 END )active_old_5days,
> SUM(case when (A.LAST_UPDATED_ON >= (sysdate - 5) AND
> A.ot_queue_status_id = 3 ) then 1 else 0 END )closed_old_5days,
> SUM(case when (A.LAST_UPDATED_ON >= (sysdate - 5) AND
> A.ot_queue_status_id = 3 ) then (A.LAST_UPDATED_ON - c.created_on) else 0
> END ) response_old_5days
> FROM tbl_ot_queue A, tbl_circuit C, tbl_opportunity D
> WHERE A.assigned_to = struser
> AND C.opportunity_id = D.opportunity_id
> -- AND (D.key_bid = 'N' OR (D.key_bid = 'Y' AND
> C.release_to_region_on IS NOT NULL))
> AND A.circuit_id = C.circuit_id
> AND A.circuit_current_stage = C.Circuit_Current_Stage
> AND EXISTS (SELECT M.country_code FROM tbl_user_region_country
> M, tbl_user N
> WHERE N.login_id = struser
> AND M.user_id = N.user_id
> AND M.active = 

RE: (Fwd) Re: DBD::Oracle Slow cursors

[John Scoles]

Does this have anything to do at all with DBD::Oracle???
You mentioned you are calling this with JAVA??
 
Where is the Perl code??
 
> From: jaha...@idexcel.com
> To: martin.ev...@easysoft.com; dbi-users@perl.org; byter...@hotmail.com; 
> carlso...@llnl.gov; tim.bu...@pobox.com
> Subject: RE: (Fwd) Re: DBD::Oracle Slow cursors
> Date: Wed, 18 May 2011 11:07:56 +0100
> 
> Hi All,
> 
> First of all I thank you all in replying to my email. Below are details of
> one of the SP which we are having issues with.
> 
> In the below SP we are passing in a Username and then for that user are
> fetching his counts and other information. The output parameter is a
> sys_refcursur.
> 
> The problem is that when I fire each and every insert and select statement,
> Its firing in 0.2 seconds. But when retrieving these details in the java
> code when it come to the line to loop the cursor then it gets struck for
> about 2 to 3 mins and the response is coming back.
> 
> We have seen this behavior in most of the places where we used this
> sys_refcursur. 
> 
> The table circuit is a huge table of million records and it has all the
> indexces in place and other tables as well.
> 
> I have been googleing for a long time for a solution for this sys-refcursor
> issue and I am not sure why its going back to the DB after executing the SP
> while looping through the cursor.
> 
> We have Oracle 10G 10.1.0.4.
> 
> I have also tried to combain all the select statements into one using the
> UNION command and insert into the tbl_qm_dashboard. The insert fires in 1.12
> seconds, but again the cursuor looping is the issue.
> 
> Note : tbl_qm_dashboard is a temp table.
> 
> Hope I will get an break through with all your expertise.
> 
> PROCEDURE sp_select_dashboard(strUser IN VARCHAR2,
> rcSelectDashboard OUT SYS_REFCURSOR) IS
> 
> BEGIN
> 
> EXECUTE IMMEDIATE 'ALTER SESSION SET
> NLS_COMP=LINGUISTIC';
> EXECUTE IMMEDIATE 'ALTER SESSION SET
> NLS_SORT=BINARY_CI';
> 
> 
> INSERT INTO tbl_qm_dashboard
> SELECT
> dashboard_type,NVL(active_cnt,0),NVL((age/DECODE(active_cnt,0,1,active_cnt))
> ,0)avg_age,NVL(active_old_5days,0),NVL(closed_old_5days,0),NVL((response_old
> _5days/DECODE(closed_old_5days,0,1,closed_old_5days)),0)
> avg_response_old5days
> FROM
> (
> SELECT 'AccessCircuit' dashboard_type,
> SUM(case when (A.ot_queue_status_id IN(1,2) AND
> ((C.status_id <> 3) OR (C.status_id = 3 AND C.circuit_current_stage = 3)))
> then 1 else 0 END ) active_cnt,
> SUM(case when (A.ot_queue_status_id IN(1,2) AND
> ((C.status_id <> 3) OR (C.status_id = 3 AND C.circuit_current_stage = 3)))
> then (SYSDATE - c.created_on) else 0 END ) age,
> SUM(case when (c.created_on <= (sysdate - 5) AND
> A.ot_queue_status_id IN(1,2) AND ((C.status_id <> 3) OR (C.status_id = 3
> AND C.circuit_current_stage = 3))) then 1 else 0 END )active_old_5days,
> SUM(case when (A.LAST_UPDATED_ON >= (sysdate - 5) AND
> A.ot_queue_status_id = 3 ) then 1 else 0 END )closed_old_5days,
> SUM(case when (A.LAST_UPDATED_ON >= (sysdate - 5) AND
> A.ot_queue_status_id = 3 ) then (A.LAST_UPDATED_ON - c.created_on) else 0
> END ) response_old_5days
> FROM tbl_ot_queue A, tbl_circuit C, tbl_opportunity D
> WHERE A.assigned_to = struser
> AND C.opportunity_id = D.opportunity_id
> -- AND (D.key_bid = 'N' OR (D.key_bid = 'Y' AND
> C.release_to_region_on IS NOT NULL))
> AND A.circuit_id = C.circuit_id
> AND A.circuit_current_stage = C.Circuit_Current_Stage
> AND EXISTS (SELECT M.country_code FROM tbl_user_region_country
> M, tbl_user N
> WHERE N.login_id = struser
> AND M.user_id = N.user_id
> AND M.active = 'Y'
> AND M.country_code = C.country_code)
> );
> 
> INSERT INTO tbl_qm_dashboard
> SELECT
> dashboard_type,NVL(active_cnt,0),NVL((age/DECODE(active_cnt,0,1,active_cnt))
> ,0)
> avg_age,NVL(active_old_5days,0),NVL(closed_old_5days,0),NVL((response_old_5d
> ays/DECODE(closed_old_5days,0,1,closed_old_5days)),0) avg_response_old5days
> FROM
> (
> SELECT 'AccessRFQSentSupplier' dashboard_type,
> SUM(case when (A.ot_queue_status_id IN(1,2) AND
> ((C.status_id <> 3) OR (C.status_id = 3 AND C.circuit_current_stage = 3)))
> then 1 else 0 END ) active_cnt,
> SUM(case when (A.ot_queue_status_id IN(1,2) AND
> ((C.status_id <> 3) OR (C.status_id = 3 AND C.circuit_current_stage = 3)))
> then (SYSDATE - c.created_on) else 0 END ) age,
> SUM(case when (c.created_on <= (sysdate - 5) AND
> A.ot_queue_status_id IN(1,2) AND ((C.status_id <> 3) OR (C.status_id = 3 AND
> C.circuit_current_stage = 3))) then 1 else 0 END )active_old_5days,
> SUM(case when (A.LAST_UPDATED_ON >= (sysdate - 5) AND
> A.ot_queue_status_id = 3 ) then 1 else 0 END )closed_old_5days,
> SUM(case when (A.LAST_UPDATED_ON >= (sysdate - 5) AND
> A.ot_queue_status_id = 3 ) then (A.LAST_UPDATED_ON - c.created_on) else 0
> END ) response_old_5days
> FROM tbl_ot_queue A, tbl_circuit C, tbl_opportunity E
> WHERE A.assigned_to = struser
> AND A.circuit_id = C.circuit_id
> AND A.circuit_current_stage = C.Circuit_Current_Stage
> AND C.opportunity_id =

RE: (Fwd) Re: DBD::Oracle Slow cursors

[John Scoles]

What is the issue exatly?
 
It is just slow??
 
Can you give us some examples code to play with.
 
Slowness can be caused by anything from low-ban width, poor SQL, a badly 
partiioned DB or just too much data??
 

We need to know the version of DBD::Oracle you are using as well
 
Cheers
John
 
 
> Date: Tue, 17 May 2011 22:18:22 +0100
> From: tim.bu...@pobox.com
> To: dbi-users@perl.org
> CC: jaha...@idexcel.com
> Subject: (Fwd) Re: DBD::Oracle Slow cursors
> 
> - Forwarded message from P S Jameel Ahamed  -
> 
> Date: Tue, 17 May 2011 16:11:04 +0100
> From: P S Jameel Ahamed 
> To: tim.bu...@pobox.com
> Subject: Re: DBD::Oracle Slow cursors
> X-Mailer: Microsoft Office Outlook 11
> 
> HI Tim,
> 
> 
> 
> We are facing huge issues with the SYS_refcurors of oracle 10G when returning 
> from Stored procedure. Is
> there any solution you found for the issue?
> 
> 
> 
> Many Thanks in Advance
> 
> 
> 
> Regards
> 
> P S Jameel Ahamed
> 
> Confidentiality Notice: This e-mail message, including any attachments, is 
> for the sole use of the
> intended recipient(s) and may contain confidential and privileged 
> information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended 
> recipient, please contact the
> sender by reply e-mail and destroy all copies of the original message
> 
> - End forwarded message -
  

RE: What's the relationship between LongReadLen and TEXTSIZE?

[John Scoles]

Martin Evans would be the expert on that.  But it does sound funny that 
TEXTSIZE is working and LongReadLen is not??  LongReadLen should work no matter 
the driver.
Perhaps you should try DBD::ADO


 
> From: eric.b...@barclayscapital.com
> To: dbi-users@perl.org
> Date: Tue, 17 May 2011 12:11:55 -0400
> Subject: What's the relationship between LongReadLen and TEXTSIZE?
> 
> I'm setting up to use DBD::ODBC with the FreeTDS driver to go against a MS 
> SQL server and am hoping to nail down the specifics of the relationship 
> between setting $dbh->{LongReadLen} and TEXTSIZE.
> 
> So far, LongReadLen has had exactly no impact on retrieval of long data from 
> my MS sql server. Regardless of to what LongReadLen is set, the data that I 
> retrieve is complete beyond the LongReadLeng setting as long as TEXTSIZE is 
> adequately large.
> 
> Setting TEXTSIZE to a value that is less than the length of the data, 
> however, does result in truncated data returned from the dataserver.
> 
> Additionally, truncated values end with an extended ascii char...probably a 
> null...I have to admit I haven't looked yet.
> 
> So, can we just ignore LongReadLen? We're migrating from Sybase, and have 
> been using LongReadLen as a connection parameter in Sybase for years to set 
> the size of long data returned by the dataserver.
> 
> Any light you can shed on this is appreciated.
> 
> Eric
> 
> ___
> 
> This e-mail may contain information that is confidential, privileged or 
> otherwise protected from disclosure. If you are not an intended recipient of 
> this e-mail, do not duplicate or redistribute it by any means. Please delete 
> it and any attachments and notify the sender that you have received it in 
> error. Unless specifically indicated, this e-mail is not an offer to buy or 
> sell or a solicitation to buy or sell any securities, investment products or 
> other financial product or service, an official confirmation of any 
> transaction, or an official statement of Barclays. Any views or opinions 
> presented are solely those of the author and do not necessarily represent 
> those of Barclays. This e-mail is subject to terms available at the following 
> link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent 
> to the foregoing. Barclays Capital is the investment banking division of 
> Barclays Bank PLC, a company registered in England (number 1026167) with its 
> registered office at 1 Churchill Place, London, E14 5HP. This email may 
> relate to or be sent from other members of the Barclays Group.
> ___
  

RE: Help Needed for DBI

[John Scoles]

Are you uisng activestate Perl?
 
You will also have to insall DBD::Oracle and an instantclient as well.
 
If not you will have to compile DBD::Oracle yourself (takes a little while but 
it can be done) see the windows readmes to find instrunctions
 
Cheers
John Scoles
 

 
> Date: Fri, 29 Apr 2011 20:38:12 +1000
> Subject: Re: Help Needed for DBI
> From: rc...@pcug.org.au
> To: vikrant@rbs.co.uk
> CC: dbi-users@perl.org
> 
> > Hello,
> > I am really struggling to connect to database, I am not sure how to
> > ensure that I HAVE DBI sintalled and if not then how to make it
> > activate
> > it on my machine, I have perl installed but when I give the following
> > command on my command prompt then
> >
> > perl -e 'use DBI; print $DBI::VERSION,"\n";' it gives following
> > errorcd c\
> > Can't find string terminator "'" anywhere before EOF at -e line 1.
> 
> It works for me!
> owen@owen-desktop:~$ perl -e 'use DBI; print $DBI::VERSION,"\n";'
> 1.607
> owen@owen-desktop:~$
> 
> But you are on Windows, and there is always some problem with single
> and double quotes.
> 
> I think windows does not allow single quotes, so try that with double
> quotes, eg # perl -e "use DBI; print $DBI::VERSION,"\n";"
> 
> 
> 
> 
> 
> 
> 
> > Also when I am exccuting a database program it gives the following
> > highlighted error, any help on this will be higly appreciated...
> > #!/usr/bin/perl -w
> > use strict;
> > use dbi();
> > use lib;
> >
> >
> > my $dbh = dbi->connect('dbi:Oracle:',
> > '',
> > '',
> > {
> > RaiseError => 1,
> > AutoCommit => 0
> > }
> > )|| die "Database connection not made:
> > $dbi::errstr";
> > my $sql = qq{ SELECT * FROM tab where rownum<3 };
> > my $sth = $dbh->prepare( $sql );
> > $sth->execute();
> > $dbh->disconnect();
> > Name "dbi::errstr" used only once: possible typo at C:\seven.pl line
> > 14.
> > Can't locate object method "connect" via package "dbi" at C:\seven.pl
> > line 7.
> 
> 
> Again, my lack of windows knowledge fails me, and maybe capitalization
> doesn't matter, but the package is DBI, so I would have written,
> 
> use DBI;
> ...
> my $dbh = DBI->connect('dbi:Oracle:', ...
> 
> Again, perhaps the single quotes may cause a problem, try double
> quotes if need be
> 
> 
> 
> Owen
> 
> 
> 
> 
  

Re: General DBI spec Question?

[John Scoles]

 On 18/04/2011 3:29 PM, Tim Bunce wrote:

[redirected to dbi-users list]

On Fri, Apr 15, 2011 at 03:05:59PM -0400, John Scoles wrote:

I was given a patch for DBD::Oracle today the just of it was to open
up the OCI commands for starting up and shuting down the DB.

So the question is would this be out of the DBI spec to allow direct
control of the DB like this or does this fall under the custom
function  category.

The general approach is for drivers to add such things as private
methods. If several drivers have implemented similar functionality
then, and only then, would it be safe to consider extending the DBI to
cover that kind of functionality.


That's what I figured.

Tim.

p.s. In this case I'd like to see the Oracle::OCI module revived.
It could handle this requirement and much else besides.

No movement on that mod in what 10 years

Cheers
John

Re: Need Perl DBI and DBD modules for Perl 5.8.8

[John Scoles]

 On 13/04/2011 5:19 PM, mmilli...@fruit.com wrote:
Well nothing special

The latest DBI and DBD::Oracle and I would go with the latest version of 
the Oracle instant client 11g.


Compiling for AIX is always a bit problematic depending on how the 
system is set up, how the Perl was compiled and which C compiler you have.


DBI should install no problem you will most likely hit a snag when it 
comes to DBD::Oracle.


Once you give that a try post the results of the Perl Makefile.PL and 
the nmake and we will see what we can come up with.


Cheers
John



Hello Experts,

Need to recompile the DBI and DBD modules for perl 5.8.8 and the server
uses Oracle 11g on AIX 6.1.5 If anyone has done this or know which module
we need to download your help is reall appreciated, we need to response as
quick as possible. Thanks


Have a great Day!
Senior Unix Technical Support
Michael Milliner
Ph. 270.781.6400 Ext: 2108
**
This communication contains information which is confidential and
may also be privileged. It is for the exclusive use of the intended
recipient(s). If you are not the intended recipient(s), please note
that any distribution, copying or use of this communication or the
information in it is strictly prohibited. If you have received this
communication in error, please notify the sender immediately and
then destroy any copies of it.
**

RE: DBD::Oracle 1.27 and bind_col()

[John Scoles]

I will have to look into this one in detail later next week as I am off at a 
conferace this week. Seems like something got in there.
 
can you send me run with DBD_Verbose=7
 
Cheers
John
 
> Date: Thu, 24 Mar 2011 16:26:00 +0100
> From: alexan...@foken.de
> To: dbi-users@perl.org
> Subject: DBD::Oracle 1.27 and bind_col()
> 
> Hello List,
> 
> could someone with a working DBD::Oracle 1.28 please verify that the 
> tests 2 and 4 in the attached test script fail?
> 
> All test pass with DBD::Oracle 1.23, tests 2 and 4 fail with DBD::Oracle 
> 1.27.
> 
> Background information: I use Perl to provide access to an ancient 
> legacy system, that system sends strings to a Perl server, the server 
> invokes DBI methods and passes those strings as parameters. The call to 
> $sth->bind_col() worked fine with DBD::Oracle 1.23, it crashes with 
> "Invalid column number" on DBD::Oracle 1.27. I think DBD::Oracle broke 
> somewhere between 1.23 and 1.27.
> 
> In dbdim.c of DBD::Oracle 1.27, dbd_st_bind_col() tests SvIOK(col), but 
> makes no attempts to convert col to a number first. Older versions seem 
> to use a default implementation of bind_col provided by DBI in DBI.xs. 
> In that file, dbih_sth_bind_col() fetches the column number by calling 
> SvIV(col).
> 
> Thanks,
> Alexander
  

RE: Error 'making DBD:Oracle 1.28 on Cygwin W

[John Scoles]

Ok I think I know what it is looks like I forgot to put
 
OCIServerRelease
 
in the 
 
oci.def
 
Add the word in there and see what happens
 
Silly mistake really but hard to catch  unless you have the right test system 
handy
 
We would of caught this if we had a broader test page for the Release 
Cadidates, hint hint nudge nudge ;) ;)
 
Cheers
John Scoles
 
> Date: Thu, 24 Mar 2011 13:27:20 +0100
> From: alexan...@foken.de
> To: dbi-users@perl.org
> CC: jason.thurs...@gmail.com
> Subject: Re: Fwd: Error 'making DBD:Oracle 1.28 on Cygwin W
> 
> DBD::Oracle 1.27 compiled, tested and installed without any problems. 
> The changes in 
> http://search.cpan.org/~pythian/DBD-Oracle-1.28/Changes#Changes_in_DBD-Oracle_1.28_%28svn_rev_14765%29>
>  
> don't look relevant to my environment. I can live with that.
> 
> Now it is clear that some change from 1.27 to 1.28 broke compatibilty 
> with Oracle 10.2g.
> 
> Alexander
> 
> On 03/24/2011 12:18 PM, Alexander Foken wrote:
> > Hmmm, on my other system, DBD::Oracle 1.23 and Oracle 10.2g work 
> > perfectly. So, what's the difference?
> >
> > XP vs. 2000 -- unlikely
> > Much older DBD::Oracle
> >
> > Looking at the DBD::Oracle diffs available at search.cpan.org, I see 
> > that OCIServerRelease exists in the diffs from 1.27 to 1.28 (in 
> > Oracle.xs, condition added to avoid calling OCIServerVersion on 
> > servers < 10.2), and in the diffs from 1.24b to 1.25 (don't quite 
> > understand what happens there). But I see no change containing 
> > OCIServerVersion in the diffs from 1.24b to 1.25.
> >
> > I will try compiling 1.27, then 1.23 after lunch ...
> >
> > Alexander
> >
> > On 03/24/2011 11:59 AM, Alexander Foken wrote:
> >> Hello,
> >>
> >> sorry, just a "me too" posting. I was just about to ask for nearly(?) 
> >> the same problem.
> >>
> >> I'm trying with Strawberry Perl 5.12.2.0 and 5.10.0.4, Oracle 10g, 
> >> DBD::Oracle 1.28, Windows 2000 Professional.
> >>
> >> Final problem after tons of warnings: oci8.o: oci8.c: undefined 
> >> reference to 'OCIServerRelease'
> >>
> >> See attached logfile of running perl Makefile.PL and dmake (with Perl 
> >> 5.12, same messages with 5.10).
> >>
> >> I would guess that there is a problem with DBD::Oracle, because we 
> >> get the same missing symbol for different OS versions, different 
> >> Perl ports, different Perl versions, different DBI versions, 
> >> different Oracle versions.
> >>
> >> Alexander
> >>
> >> On 03/24/2011 12:15 AM, Jason Thurston wrote:
> >>> Hello,
> >>>
> >>> Does anyone have any ideas where to go from here?
> >>>
> >>> I think "perl Makefile.PL" is successful but I get an error when
> >>> trying the next step "make".
> >>> The Error I get when trying to "make" is
> >>> "/home/foo/DBD-Oracle-1.28/oci8.c:4619: undefined reference to
> >>> `_OCIServerRelease'". See Below for details.
> >>>
> >>> I originally tried with the cygwin cpan tool but then downloaded the
> >>> packaged and tried manually but got the exact same error.
> >>>
> >>>
> >>> DETAILS:
> >>>
> >>> OS:
> >>> Windows 2003 Enterprise X64 Edition
> >>>
> >>> $ uname -a
> >>> CYGWIN_NT-5.2-WOW64 mck-rnmwv4-ip42 1.7.8(0.236/5/3) 2011-03-01 09:36
> >>> i686 Cygwin
> >>>
> >>> $ env|grep -i ora|two
> >>> ORACLE_USER=foo1/foo1@foo
> >>> ORACLE_SID=foo
> >>> ORACLE_USERID=foo1/foo1@foo
> >>> TWO_TASK=foo
> >>> TNS_ADMIN=E:\oracle\instantclient_11_2
> >>> PATH=/usr/local/bin:/usr/bin:/cygdrive/e/oracle/instantclient_11_2:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/cygdrive/e/PROGRA~1/BMCSOF~1/Patrol3/bin:/cygdrive/e/PROGRA~1/BMCSOF~1/MASTER~1/server/bin:/cygdrive/c/WINDOWS/system32/WindowsPowerShell/v1.0:/opt/java/bin
> >>>  
> >>>
> >>> CLASSPATH=.;E:\oracle\instantclient_11_2/ojdbc6.jar
> >>> ORACLE_HOME=E:\oracle\instantclient_11_2
> >>>
> >>> $ pwd
> >>> /home/foo/DBD-Oracle-1.28
> >>>
> >>>
> >>> $ perl -v
> >>>
> >>> This is perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int
> >&

Re: (Fwd) Re: DBD::Oracle: table_info, PUBLIC schema

[John Scoles]

 On 21/03/2011 2:49 PM, Tim Bunce wrote:

- Forwarded message from Satish Patil  -

Date: Mon, 21 Mar 2011 07:37:45 -0700 (PDT)
From: Satish Patil
To: tim.bu...@pobox.com, s.goeld...@eurodata.de
Subject: Re: DBD::Oracle: table_info, PUBLIC schema
X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.295617

Hi Tim and Steffen,

How can I get the sample schema for DBD or scripts for DBD. Any URL.

Not sure what you mean by schema?

Do you want a schema to play with or to find out info on a schema or a 
tutorial for DBI/DBD


Either way use this
http://search.cpan.org/~pythian/DBD-Oracle-1.28/Oracle.pm#Metadata
to look up the info on about a schema

and this one for a tutorial

http://www.pythian.com/news/wp-content/uploads/introduction-dbd-oracle.html

cheers
John


Please send it to me asap.

Thanks,

Satish Patil

- End forwarded message -

Re: Understanding trace output

[John Scoles]

Well you are getting a ORA-24812 error so that tells me it is some
sort of Pass through error.

Where this error is taking place is anyone's guess.  It could be bad
data in the table or a misconfiguration in the TNS entry or your local
ENV.

You might want to set the ora_charset, or  ora_ncharset on your
connection string with DBIx

cheers
John


On Thu, Mar 10, 2011 at 4:01 PM, Ivan Wills  wrote:
> On 10 March 2011 10:09, John Scoles  wrote:
>
>>  CSID in this case is the the national character set in the first
>> environemtn it is 873 in the second it is 1 so it cannot traslate betwwen
>> one and another.
>>
>> As well it is the csform =0 that worries me more as that should come out as
>> the  as one of the allowable something like SQLCS_NCHAR or SQLCS_EXPLICIT
>>
>> Can we see more of the trace??
>>
>> cheers
>> John
>>
>> > Date: Thu, 10 Mar 2011 09:19:11 +1100
>> > Subject: Understanding trace output
>> > From: ivan.wi...@gmail.com
>> > To: dbi-users@perl.org
>>
>> >
>> > Hi,
>> >
>> > I'm trying to debug a problem with some code that is erroring when trying
>> > read a CLOB field from an oracle 10g database through DBIx::Class and
>> direct
>> > DBI calls in Catalyst. I can get the code to work when I am not trying to
>> do
>> > through Catalyst.
>> >
>> > I have noticed the following trace line from the Catalyst call
>> > dbd_rebind_ph(): bind :p1 <== '152756' (in, not-utf8, csid 873->0->873,
>> > ftype 1 (VARCHAR), csform 0->0, maxlen 8, maxdata_size 0)
>> > when I run the code the out side catalyst the line changes to
>> > dbd_rebind_ph(): bind :p1 <== '152756' (in, not-utf8, csid 1->0->1, ftype
>> > 1 (VARCHAR), csform 0->0, maxlen 8, maxdata_size 0)
>> >
>> > It looks like something is changing/setting some value to cause the
>> change
>> > but I can't work out what would be doing it or how to reset the value.
>> >
>> > Any suggestions on where to look or how to set the csid value?
>> >
>> > Thanks,
>> > Ivan
>> >
>> > --
>> > email/jabber: ivan.wi...@gmail.com
>> > /
>> > / _ _
>> > / \ / | | | |
>> > / \/ \_| | |
>>
>
> Hi John,
> Here is the rest of the trace:
>
>    DBI 1.609-ithread default trace level set to 0x0/4 (pid 4122) at
> Inbox.pm line 386 via Inbox.pm line 346
>    -> prepare_cached for DBD::Oracle::db (DBI::db=HASH(0x???)~0x???
> 'SELECT me.id, me.part_ref, me.image_id, me.text_id, me.binary_id, me.name,
> me.bin_mimetype, md_mms_repos_text.text, md_mms_repos_text.text_mime FROM
> md_mms_repos_part me LEFT JOIN md_mms_repos_text md_mms_repos_text ON
> md_mms_repos_text.text_id = me.text_>
> 1   -> prepare for DBD::Oracle::db (DBI::db=HASH(0x???)~INNER 'SELECT
> me.id, me.part_ref, me.image_id, me.text_id, me.binary_id, me.name,
> me.bin_mimetype, md_mms_repos_text.text, md_mms_repos_text.text_mime FROM
> md_mms_repos_part me LEFT JOIN md_mms_repos_text md_mms_repos_text ON
> md_mms_repos_text.text_id = me.text_id WHERE ( >
>    dbd_preparse scanned 1 distinct placeholders
>    dbd_st_prepare'd sql SELECT (pl1, auto_lob1, check_sql1)
>    dbd_describe SELECT (EXPLICIT, lb 200)...
> Describe col #1 type=2(NVARCHAR2)
> Described col  1: dbtype 2(NVARCHAR2), scale -127, prec 0, nullok 0, name ID
>          : dbsize 22, char_used 0, char_size 0, csid 0, csform 0, disize
> 171
>    fbh 1: 'ID'»NO null , otype   2->  5, dbsize 22/172, p0.s-127
> Describe col #2 type=2(NVARCHAR2)
> Described col  2: dbtype 2(NVARCHAR2), scale -127, prec 0, nullok 0, name
> PART_REF
>          : dbsize 22, char_used 0, char_size 0, csid 0, csform 0, disize
> 171
>    fbh 2: 'PART_REF'»··NO null , otype   2->  5, dbsize 22/172, p0.s-127
> Describe col #3 type=2(NVARCHAR2)
> Described col  3: dbtype 2(NVARCHAR2), scale -127, prec 0, nullok 1, name
> IMAGE_ID
>          : dbsize 22, char_used 0, char_size 0, csid 0, csform 0, disize
> 171
>    fbh 3: 'IMAGE_ID'»··NULLable, otype   2->  5, dbsize 22/172, p0.s-127
> Describe col #4 type=2(NVARCHAR2)
> Described col  4: dbtype 2(NVARCHAR2), scale -127, prec 0, nullok 1, name
> TEXT_ID
>          : dbsize 22, char_used 0, char_size 0, csid 0, csform 0, disize
> 171
>    fbh 4: 'TEXT_ID'»···NULLable, otype   2->  5, dbsize 22/172, p0.s-127
> Describe col #5 type=2(NVARCHAR2)
> Described col  5: dbtype 2(NVARCHAR2), scale -127, prec 0, nullok 1, name
> BINARY_ID
>          :

RE: Understanding trace output

[John Scoles]

CSID in this case is the the national character set in the first environemtn it 
is 873 in the second it is 1 so it cannot traslate betwwen one and another.
 
As well it is the csform =0 that worries me more as that should come out as the 
 as one of the allowable something like SQLCS_NCHAR or SQLCS_EXPLICIT
 
Can we see more of the trace??
 
cheers
John
 
> Date: Thu, 10 Mar 2011 09:19:11 +1100
> Subject: Understanding trace output
> From: ivan.wi...@gmail.com
> To: dbi-users@perl.org
> 
> Hi,
> 
> I'm trying to debug a problem with some code that is erroring when trying
> read a CLOB field from an oracle 10g database through DBIx::Class and direct
> DBI calls in Catalyst. I can get the code to work when I am not trying to do
> through Catalyst.
> 
> I have noticed the following trace line from the Catalyst call
> dbd_rebind_ph(): bind :p1 <== '152756' (in, not-utf8, csid 873->0->873,
> ftype 1 (VARCHAR), csform 0->0, maxlen 8, maxdata_size 0)
> when I run the code the out side catalyst the line changes to
> dbd_rebind_ph(): bind :p1 <== '152756' (in, not-utf8, csid 1->0->1, ftype
> 1 (VARCHAR), csform 0->0, maxlen 8, maxdata_size 0)
> 
> It looks like something is changing/setting some value to cause the change
> but I can't work out what would be doing it or how to reset the value.
> 
> Any suggestions on where to look or how to set the csid value?
> 
> Thanks,
> Ivan
> 
> -- 
> email/jabber: ivan.wi...@gmail.com
> /
> / _ _
> / \ / | | | |
> / \/ \_| | |
  

RE: Numeric and string columns.

[John Scoles]

Common to all DBD me thinks.  Me thinks you only get in or out scalars (ie 
strings) unless you tell your DBD differently
 
I think you have to use  $sth->bind_co
 
 
to get your int back as an int try something like this
 $sth->bind_col(1, undef, { TYPE => SQL_INTEGER });
hope this helps
 
> From: b...@wards.net
> Date: Fri, 25 Feb 2011 17:56:59 -0800
> Subject: Re: Numeric and string columns.
> To: mose...@hank.org
> CC: dbi-users@perl.org
> 
> Sounds like DBD::Pg should know better than to do that!
> But then, DBD::mysql has the same problem. So maybe it is at the DBI level?
> 
> On Fri, Feb 25, 2011 at 5:50 PM, Bill Moseley  wrote:
> 
> > Columns coming from DBD::Pg seems to all be Perl strings and then when I
> > encode to json then end up quoted:
> >
> > music=# \d cd;
> > Table "public.cd"
> > Column | Type | Modifiers
> > -+-+-
> > id | integer | not null default nextval('cd_id_seq'::regclass)
> > year | integer |
> > name | text |
> > artist | integer | not null
> > deleted | boolean | not null default false
> > Indexes:
> > "cd_pkey" PRIMARY KEY, btree (id)
> >
> >
> > my $x = $dbh->selectrow_hashref( "select * from cd where id = 1" );
> > $x->{foo} = 0;
> >
> > print Dumper $x;
> > print encode_json( $x );
> >
> > Results in:
> >
> > $VAR1 = {
> > 'artist' => '1',
> > 'name' => 'One first CD',
> > 'foo' => 0,
> > 'deleted' => '0',
> > 'id' => '1',
> > 'year' => '2010'
> > };
> > {"artist":"1","name":"One first
> > CD","foo":0,"deleted":"0","id":"1","year":"2010"}
> >
> > Notice how the deleted boolean and integer columns are quoted, but the
> > "foo"
> > I injected is not quoted?
> >
> > In a javascript library we are using it's seeing the deleted value as true.
> > So, I'm curious if I can make DBI (or DBD::Pg) return the non-text columns
> > looking like numbers to Perl.
> >
> > I suppose I could do something silly like:
> >
> > /^\d+$/ && ($_ += 0) for values %{$x};
> >
> >
> > which then returns:
> >
> > {"artist":1,"name":"One first CD","foo":0,"deleted":0,"id":1,"year":2010}
> >
> > --
> > Bill Moseley
> > mose...@hank.org
> >
> 
> 
> 
> -- 
> Check out my LEGO blog at http://www.brickpile.com/
> View my photos at http://flickr.com/photos/billward/
> Follow me at http://twitter.com/williamward
  

Re: Problem with UTF8 and array binding....

[John Scoles]

 On 17/02/2011 4:38 PM, Bobak, Mark wrote:
Sorry Mark I saw that

PI_CIBD_CODE_TAB was a clob so that is where I though you where having your 
problem. There is such a thing
as a nvarchar never used it myself perhaps that will help.





Sorry, but I'm not sure I understand the suggestion.  NCLOB is (as far as I can 
see), not in the picture...

Datatype of table is VARCHAR2(255 CHAR)

The PL/SQL table type is table of table_name.column_name%type indexed by 
binary_integer

IN TYPE is named type defined as the table type mentioned above...

I don't see how/where NCLOB fits into the picture?

-Mark

-Original Message-----
From: John Scoles [mailto:sco...@pythian.com]
Sent: Thursday, February 17, 2011 4:10 PM
To: dbi-users@perl.org
Subject: Re: Problem with UTF8 and array binding

   On 17/02/2011 3:05 PM, Bobak, Mark wrote:

Perhaps you have to declare you in type as a NCLOB??

Cheers
John

Hi all,

I'm running into a 'PLS-00418: array bind type must match PL/SQL table row 
type' error, but only when passing UTF8 data.

The details are as follows.  I have a PL/SQL packaged function that looks like 
this:
FUNCTION MSTInsUpdCIT(
PI_CGP_ID   IN  VARCHAR2
,PI_CBL_ID   IN  VARCHAR2
,PI_VCL_ID   IN  VARCHAR2
,PI_CIL_LOCATOR  IN  VARCHAR2
,PI_VCL_ID_TAB   IN  vcl_id_tab_type
,PI_CIL_LOCATOR_TAB  IN  cil_locator_tab_type
,PI_CIT_HITLISTLINE  IN  VARCHAR2
,PI_CIT_ALPHA_DATE   IN  VARCHAR2
,PI_CIT_START_DATE   IN  VARCHAR2
,PI_CIT_END_DATE IN  VARCHAR2
,PI_CIT_SORT_DATEIN  VARCHAR2
,PI_CIT_NUMERIC_DATE IN  VARCHAR2
,PI_VIBC_ID_TAB  IN  VARCHAR2
,PI_CIBD_CODE_TABIN  CLOB
,PI_CIT_ABS_WORD_CNT IN  NUMBER
,PI_CIT_TXT_WORD_CNT IN  NUMBER
,PI_CIT_TYPE IN  VARCHAR2
,PI_CIT_UNDATED_FLAG IN  VARCHAR2
,PI_CIT_DELETE_FLAG  IN  VARCHAR2
,PI_ROUTER_PRIORITY  IN  NUMBER
,PI_CIT_COVERIN  VARCHAR2
,PO_VCS_IDOUT NUMBER
,PO_DELETE_FLAG  OUT  varchar2
,PO_HOLD_STATUS  OUT  varchar2
,PO_CIT_EXISTS   OUT NUMBER
,po_cit_id   OUT VARCHAR2
,PO_MESSAGE_GROUP_ID OUT VARCHAR2) RETURN NUMBER;

The 'cil_locator_tab_type' is defined as:
TYPE cil_locator_TAB_TYPE is table of cnt_item_locators.cil_locator%type index 
by binary_integer;

And cnt_item_locators.cil_locator is VARCHAR2(255 CHAR).

Database characterset is AL32UTF8.

In Perl, I'm defining an array reference as:
my $cil_locator_tab = ['2004322656 Vädskulturmuseet i Göorg',
 '9789187484124 (Vädskulturmuseet i Göorg)',
 '2004322656 Vädskulturmuseet i Göorg'];

which has UTF8 characters in it.

Next, I'm setting the multibyte flag via:
Encode::_utf8_on(@{$cil_locator_tab}[0]);
Encode::_utf8_on(@{$cil_locator_tab}[1]);
Encode::_utf8_on(@{$cil_locator_tab}[2]);

Finally, I define a param_hash as:
my $paramHash = {cbl_id   =>   '23481',
   vcl_id   =>   '15',
   cil_locator  =>   '2004322656  Vädskulturmuseet i Göorg',
   vcl_id_tab   =>   $vcl_id_tab,
   cil_locator_tab  =>   $cil_locator_tab,
   hitlistline  =>   'Viñ cielo, luna y arena. El espacio 
Calchaquín el folclore argentino moderno~~~2003~Book Chapter',
   alphadate=>   '2003',
   startdate=>   '20030101',
   sortdate =>   '20030101',
   numdate  =>   '20030101',
   vibc_id_tab  =>   '1',
   cibd_code_tab=>   'MLA',
   cit_abs_word_cnt =>   '0',
   cit_txt_word_cnt =>   '0',
   cit_undated_flag =>   'N',
   cit_delete_flag  =>   'N',
   router_priority  =>   '5',
   cover_flag   =>   'N',
  };
And the binding of the datatype is here:
  $sth->bind_param(':PI_CIL_LOCATOR_TAB', $paramHash->{cil_locator_tab},
  {ora_type =>   ORA_VARCHAR2_TABLE, ora_maxarray_numentries =>   
$maxrows});

Now, I call my PL/SQL, passing the paramHash, and I'm getting the PLS-00418 
error described above.

So, I guess I need to understand how to map my bind variable to match my PL/SQL 
table type.

This seems to work for non-UTF8 data, so, I'm not sure if this is a coding 
error in my code, or some DBD/DBI bug?

Can anyone offer any insights?

Thanks,

-Mark

Re: Problem with UTF8 and array binding....

[John Scoles]

 On 17/02/2011 3:05 PM, Bobak, Mark wrote:

Perhaps you have to declare you in type as a NCLOB??

Cheers
John

Hi all,

I'm running into a 'PLS-00418: array bind type must match PL/SQL table row 
type' error, but only when passing UTF8 data.

The details are as follows.  I have a PL/SQL packaged function that looks like 
this:
FUNCTION MSTInsUpdCIT(
   PI_CGP_ID   IN  VARCHAR2
,PI_CBL_ID   IN  VARCHAR2
,PI_VCL_ID   IN  VARCHAR2
,PI_CIL_LOCATOR  IN  VARCHAR2
,PI_VCL_ID_TAB   IN  vcl_id_tab_type
,PI_CIL_LOCATOR_TAB  IN  cil_locator_tab_type
,PI_CIT_HITLISTLINE  IN  VARCHAR2
,PI_CIT_ALPHA_DATE   IN  VARCHAR2
,PI_CIT_START_DATE   IN  VARCHAR2
,PI_CIT_END_DATE IN  VARCHAR2
,PI_CIT_SORT_DATEIN  VARCHAR2
   ,PI_CIT_NUMERIC_DATE IN  VARCHAR2
,PI_VIBC_ID_TAB  IN  VARCHAR2
,PI_CIBD_CODE_TABIN  CLOB
,PI_CIT_ABS_WORD_CNT IN  NUMBER
,PI_CIT_TXT_WORD_CNT IN  NUMBER
,PI_CIT_TYPE IN  VARCHAR2
,PI_CIT_UNDATED_FLAG IN  VARCHAR2
,PI_CIT_DELETE_FLAG  IN  VARCHAR2
,PI_ROUTER_PRIORITY  IN  NUMBER
,PI_CIT_COVERIN  VARCHAR2
,PO_VCS_IDOUT NUMBER
,PO_DELETE_FLAG  OUT  varchar2
,PO_HOLD_STATUS  OUT  varchar2
,PO_CIT_EXISTS   OUT NUMBER
,po_cit_id   OUT VARCHAR2
,PO_MESSAGE_GROUP_ID OUT VARCHAR2) RETURN NUMBER;

The 'cil_locator_tab_type' is defined as:
TYPE cil_locator_TAB_TYPE is table of cnt_item_locators.cil_locator%type index 
by binary_integer;

And cnt_item_locators.cil_locator is VARCHAR2(255 CHAR).

Database characterset is AL32UTF8.

In Perl, I'm defining an array reference as:
my $cil_locator_tab = ['2004322656 Vädskulturmuseet i Göorg',
'9789187484124 (Vädskulturmuseet i Göorg)',
'2004322656 Vädskulturmuseet i Göorg'];

which has UTF8 characters in it.

Next, I'm setting the multibyte flag via:
Encode::_utf8_on(@{$cil_locator_tab}[0]);
Encode::_utf8_on(@{$cil_locator_tab}[1]);
Encode::_utf8_on(@{$cil_locator_tab}[2]);

Finally, I define a param_hash as:
my $paramHash = {cbl_id   =>  '23481',
  vcl_id   =>  '15',
  cil_locator  =>  '2004322656  Vädskulturmuseet i Göorg',
  vcl_id_tab   =>  $vcl_id_tab,
  cil_locator_tab  =>  $cil_locator_tab,
  hitlistline  =>  'Viñ cielo, luna y arena. El espacio 
Calchaquín el folclore argentino moderno~~~2003~Book Chapter',
  alphadate=>  '2003',
  startdate=>  '20030101',
  sortdate =>  '20030101',
  numdate  =>  '20030101',
  vibc_id_tab  =>  '1',
  cibd_code_tab=>  'MLA',
  cit_abs_word_cnt =>  '0',
  cit_txt_word_cnt =>  '0',
  cit_undated_flag =>  'N',
  cit_delete_flag  =>  'N',
  router_priority  =>  '5',
  cover_flag   =>  'N',
 };
And the binding of the datatype is here:
 $sth->bind_param(':PI_CIL_LOCATOR_TAB', $paramHash->{cil_locator_tab},
 {ora_type =>  ORA_VARCHAR2_TABLE, ora_maxarray_numentries =>  
$maxrows});

Now, I call my PL/SQL, passing the paramHash, and I'm getting the PLS-00418 
error described above.

So, I guess I need to understand how to map my bind variable to match my PL/SQL 
table type.

This seems to work for non-UTF8 data, so, I'm not sure if this is a coding 
error in my code, or some DBD/DBI bug?

Can anyone offer any insights?

Thanks,

-Mark

Re: BCP for passing $password to a command-line Perl script?

[John Scoles]

 On 16/02/2011 2:45 AM, Ivan Shmakov wrote:
Well if you are using DBD::Oracle I would just use an Oracle Wallet to 
do that for you.


I am sure there are other solutions as well.

Cheers

BTW, what is the best current practice to pass ->connect ()
$password to a command-line Perl script?

Both specifying it via a command-line argument or via an
environment variable (DBI_PASS) is insecure, as on some systems
this information could easily be seen by the other users on the
same host.

Perhaps, some variation on Net::Netrc should be used instead?

My primary interests currently are PostgreSQL, which can use
Kerberos, and SQLite, which uses filesystem access rights
instead, but just for the case…

DBD-Oracle-1.28 Release Candidate 1

[John Scoles]

Here is the latest and greatest DBD::Oracle for your programming pleasure.

You can find the Zip file here

href="http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.28_RC_1.zip";>DBD-Oracle-1.28-RC1.zip


This is a long overdue maintenance release  that fixes a large number of 
bug and issues which are detailed below in the Changes.


Don't worry there are some new goodies in this release namely I have 
added in 4 new

server side tracing/debugging attributes

ora_driver_name
For 11g and later you can now set the name of the driver layer using OCI.
PERL, PERL5, ApachePerl so on. Names starting with "ORA" are reserved. You
can enter up to 8 characters.  If none is enter then this will default to
DBDO where  is the current version number. This value can be
retrieved on the server side using V$SESSION_CONNECT_INFO or
GV$SESSION_CONNECT_INFO

ora_client_info
When passed in on the connection attributes it can specify any info you want
onto the session up t0 64 bytes. This value can be
retrieved on the server side using V$SESSION view.

ora_client_identifier
When passed in on the connection attributes it specifies the user 
identifier

in the session handle. Most useful for web app as it can pass in the session
user name which might be different than the connection user name. Can be up
to 64 bytes long do not to include the password for security reasons and the
first character of the identifier should not be ':'. This value can be
retrieved on the server side using V$SESSION view.

ora_action
You can set this value to anything you want up to 32byes.This value can be
retrieved on the server side using V$SESSION view.

We have also added in the connection attribute

ora_connect_with_default_signals

Whit this attribute you can localize the $SIG{} so this should solve the
problems with  $SIG{} events that sometimes occur when using DBD::Oracle


Finally I would like to thank Martin Evans for volunteering to be 
another co-maintainer of DBD::Oracle




Cheers
John Scoles


Changes
  Added connection attribute 'ora_connect_with_default_signals' that 
will localize Perl's $SIG{INT} handler from Brian Phillips and T. Bunce
  Fix in execute_array to stop possible endless loop when using a fetch 
sub by Martin J. Evans
  Adapted Martin J. Evans' ODBC 70execute_array.t into t/26exe_array.t 
by John Scoles
  Fix for execute_array to bring it up to spec. by Martin J. Evans and 
John Scoles
  Marked ProC, Oraperl.pm, ora_explain.pl, ora_context, 
ora_use_proc_connection and ora_parse_lang as deprecated  to be removed 
in 1.29
  Added in 4 new server side debug/trace attributes, ora_driver_name, 
ora_client_info, ora_session_user and ora_action on the connection 
handle from John Scoles

  Cleaned up the pod a little by John Scoles
  Fix for function name length, Some function names are over 31char 
long which may cause problems for some OS/Compilers (VMS IA64 box.) from 
Jakob Snoer
  Fix for OCIPing in case where a 10 client tries to ping a <10 DB 
from Tim Oertel
  Fix for DBD-Oracle stored proc with array bug where second call array 
size is unchanged from Tim Oertel

  Fix for rt.cpan.org Ticket #=63332: Spelling error in POD from jonasbn
  Fix for rt.cpan.org Ticket #=62152: t/28array_bind.t and t/31lob.t 
may call plan() twice and others do not fail on not connect from John Scoles
  Fix for rt.cpan.org Ticket #=61511 ORA-00942 when inserting into a 
table with a LOB column over a synonym on HP-UX from Kris Lemaire
  Fix for rt.cpan.org Ticket #=42842 Test 31lob fails with 64-bit 
Instant Client by John Scoles
  Fix for support for objects on big endian platforms from Charles 
Jardine, John R Pierce
  Fix for rt.cpan.org Ticket #=61225 Windows install (Stawberry Perl) 
fails on long path names from David Tulloh
  Fix for rt.cpan.org Ticket #=rt64524 Memory Leak when Oracle 
connection fails by Martin J. Evans
  Added all the missing ora_drcp values to dbh private_attribute_info 
by Martin J. Evans
  Removed a load of attributes from sth private_attribute_info which 
are not handle attributes but attributes to bind_param/prepare by Martin 
J. Evans
  Fix for rt.cpan.org Ticket #=64244 - don't bail out, skip tests 
when we cannot connect by Martin J. Evans and John Scoles

  Added DBI to PREREQ_PM in Makefile.PL by Martin J. Evans
  Added build_requires in Makefile.PL by Martin J. Evans
  Added workaround for ExtUtils::MakeMaker problems by Martin J. Evans
  Added LICENSE to Makefile.PL by Martin J. Evans

Cheers John Scoles

Re: Errors with installing DBD-Oracle-1.27

[John Scoles]

 On 11/02/2011 1:16 AM, Jayadevan M wrote:

Hmm looking at the env and the MakeFile.pl output perhaps your 
ORACLE_HOME is not correct


I would give /u01/app/oracle/product/10.2.0/ a try rather than

/u01/app/oracle/product/10.2.0/db_1

just a suggestion

Cheers
John

Hi,
I am tying to install DBD-Oracle-1.27 on CentOS (32 bit). Details of 
path, version etc are all available in the log files attached as per 
instructions in README.


1) perl Makefile.PL - Output is in perlMake.log

2) make - Output  is in make.log

3) make test - Output is in maketest.log

4)Environment variables are there in env.log

The issue seems to be that it is trying to get files from lib32 when 
my libraries are there in lib. For example, perl Makefile.PL says
cat: /u01/app/oracle/product/10.2.0/db_1/lib32/sysliblist: No such 
file or directory


I have

-bash-3.2# ls -al /u01/app/oracle/product/10.2.0/db_1/*lib32*/sysliblist
ls: /u01/app/oracle/product/10.2.0/db_1/lib32/sysliblist: No such file 
or directory


-bash-3.2# ls -al /u01/app/oracle/product/10.2.0/db_1/lib/sysliblist
-rw-rw-rw- 1 oracle oinstall 31 Jun 22  2005 
/u01/app/oracle/product/10.2.0/db_1/*lib*/sysliblist



How can I fix this?

Thanks and Regards,
Jayadevan M







DISCLAIMER:

"The information in this e-mail and any attachment is intended only 
for the person to whom it is addressed and may contain confidential 
and/or privileged material. If you have received this e-mail in error, 
kindly contact the sender and destroy all copies of the original 
communication. IBS makes no warranty, express or implied, nor 
guarantees the accuracy, adequacy or completeness of the information 
contained in this email or any attachment and is not liable for any 
errors, defects, omissions, viruses or for resultant loss or damage, 
if any, direct or indirect."

Re: AIX DBD::Oracle perl Makefile.PL core dumps

[John Scoles]

On Fri, Jan 28, 2011 at 4:01 PM, Williams, Stephen <
stephen.willi...@twcable.com> wrote:

> root@nimdinf01:/var/tmp/DBD-Oracle-1.27 ] perl Makefile.PL
> Illegal instruction (core dumped)
>
> Here is a truss
>
> statx("/usr/opt/perl5/lib/5.8.8/aix-thread-multi/auto/DBI", 0x20008CB8,
> 128, 010) Err#2  ENOENT
> statx("/usr/opt/perl5/lib/5.8.8/auto/DBI", 0x20008CB8, 128, 010) Err#2
>  ENOENT
> statx("/usr/opt/perl5/lib/site_perl/5.8.8/aix-thread-multi/auto/DBI",
> 0x20008CB8, 128, 010) = 0
> statx("/usr/opt/perl5/lib/site_perl/5.8.8/aix-thread-multi/auto/DBI/DBI.so",
> 0x20008CB8, 128, 010) = 0
> statx("/usr/opt/perl5/lib/site_perl/5.8.8/aix-thread-multi/auto/DBI/DBI.bs",
> 0x20008CB8, 128, 010) = 0
> __loadx(0x014D0080, 0x2FF205C0, 0x0960, 0x2043E708, 0x) =
> 0xF21CDE80
> loadquery(2, 0x20146158, 0x1000)= 0
> __loadx(0x02000200, 0xF2136400, 0x3E80, 0xF21CDE80, 0x204451C0) =
> 0x
> __loadx(0x0700, 0x2043D5C8, 0x0017, 0xF21CDE80, 0x0197) =
> 0xF21D2588
>Received signal #4, SIGILL [default]
> *** process killed ***
>
> Also on a side note I am usingo compile since it was used by IBM to compile
> Perl.
>
>
> I see from the perl -v

Compiler:
   cc='cc_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -


the compiler was cc_r

is that the same as xlC?

and even if it is it has to be the exact same version of xlC

Hope this helps/

If all else fails rebuild your perl from scratch with xlC t if you have a
few hours to wast;)

Cheers
John

>
> -Original Message-
> From: John Scoles [mailto:sco...@pythian.com]
> Sent: Friday, January 28, 2011 3:59 PM
> To: Williams, Stephen
> Cc: dbi-users@perl.org
> Subject: Re: AIX DBD::Oracle perl Makefile.PL core dumps
>
>  Installing dbd oracle on any version AIX has always been problematic.
> Usually you have to rebuild your perl with the exact same version of
> compiler that compiled the perl.
>
> If you are using the Perl that comes with AIX that may be hard to do.
>
> As well there are always 64-32 bit issues.
>
> Can you post what happens on the perl Makefile.PL
>
> Cheers
> John
>
> On Fri, Jan 28, 2011 at 3:22 PM, Williams, Stephen <
> stephen.willi...@twcable.com> wrote:
>
> > Afternoon all,
> >
> > I am having trouble with trying to compile the DBD drive for Oracle on my
> > AIX 5.3 TL11 host. I have DBI-1.616 installed on the node fine, but when
> I
> > go to run the perl Makefile.PL I keep getting a core dump. The perl
> > installation is the OS supplied perl (information below).
> >
> > root@testnode:/var/tmp/AIX/DBD-Oracle-1.27<mailto:root@testnode
> :/var/tmp/AIX/DBD-Oracle-1.27>
> > ] perl Makefile.PL
> > Illegal instruction (core dumped)
> >
> > root@testnode:/var/tmp/AIX/DBD-Oracle-1.27<mailto:root@testnode
> :/var/tmp/AIX/DBD-Oracle-1.27>
> > ] perl -V
> > Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
> >  Platform:
> >osname=aix, osvers=5.3.0.0, archname=aix-thread-multi
> >uname='aix akash79 3 5 00011a85d600 '
> >config_args='-desr -Dinstallprefix=/usr/opt/perl5
> > -Dprefix=/usr/opt/perl5 -Dcc=xlc_r -Duseshrplib -Dusethreads'
> >hint=recommended, useposix=true, d_sigaction=define
> >usethreads=define use5005threads=undef useithreads=define
> > usemultiplicity=define
> >useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
> >use64bitint=undef use64bitall=undef uselongdouble=undef
> >usemymalloc=n, bincompat5005=undef
> >  Compiler:
> >cc='cc_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
> > -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q32
> > -D_LARGE_FILES -qlonglong',
> >optimize='-O',
> >cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1
> > -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT'
> >ccversion='9.0.0.2', gccversion='', gccosandvers=''
> >intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
> >d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
> >ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> > lseeksize=8
> >alignbytes=8, prototype=define
> >  Linker and Libraries:
> >ld='ld', ldflags =' -brtl -bdynamic -b32'
> >libpth=/lib /usr/lib /usr/ccs/lib
> >libs=-lbind -lnsl -lgdbm -ldbm -ldb -ldl -lld -lm -lc

Re: AIX DBD::Oracle perl Makefile.PL core dumps

[John Scoles]

 Installing dbd oracle on any version AIX has always been problematic.
Usually you have to rebuild your perl with the exact same version of
compiler that compiled the perl.

If you are using the Perl that comes with AIX that may be hard to do.

As well there are always 64-32 bit issues.

Can you post what happens on the perl Makefile.PL

Cheers
John

On Fri, Jan 28, 2011 at 3:22 PM, Williams, Stephen <
stephen.willi...@twcable.com> wrote:

> Afternoon all,
>
> I am having trouble with trying to compile the DBD drive for Oracle on my
> AIX 5.3 TL11 host. I have DBI-1.616 installed on the node fine, but when I
> go to run the perl Makefile.PL I keep getting a core dump. The perl
> installation is the OS supplied perl (information below).
>
> root@testnode:/var/tmp/AIX/DBD-Oracle-1.27
> ] perl Makefile.PL
> Illegal instruction (core dumped)
>
> root@testnode:/var/tmp/AIX/DBD-Oracle-1.27
> ] perl -V
> Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
>  Platform:
>osname=aix, osvers=5.3.0.0, archname=aix-thread-multi
>uname='aix akash79 3 5 00011a85d600 '
>config_args='-desr -Dinstallprefix=/usr/opt/perl5
> -Dprefix=/usr/opt/perl5 -Dcc=xlc_r -Duseshrplib -Dusethreads'
>hint=recommended, useposix=true, d_sigaction=define
>usethreads=define use5005threads=undef useithreads=define
> usemultiplicity=define
>useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
>use64bitint=undef use64bitall=undef uselongdouble=undef
>usemymalloc=n, bincompat5005=undef
>  Compiler:
>cc='cc_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE
> -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q32
> -D_LARGE_FILES -qlonglong',
>optimize='-O',
>cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1
> -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT'
>ccversion='9.0.0.2', gccversion='', gccosandvers=''
>intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
>d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
>ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
> lseeksize=8
>alignbytes=8, prototype=define
>  Linker and Libraries:
>ld='ld', ldflags =' -brtl -bdynamic -b32'
>libpth=/lib /usr/lib /usr/ccs/lib
>libs=-lbind -lnsl -lgdbm -ldbm -ldb -ldl -lld -lm -lcrypt -lpthreads -lc
> -lbsd
>perllibs=-lbind -lnsl -ldl -lld -lm -lcrypt -lpthreads -lc -lbsd
>libc=, so=a, useshrplib=true, libperl=libperl.a
>gnulibc_version=''
>  Dynamic Linking:
>dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='
>  -bE:/usr/opt/perl5/lib/5.8.8/aix-thread-multi/CORE/perl.exp'
>cccdlflags=' ', lddlflags='-bhalt:4 -bexpall -G -bnoentry -lpthreads
> -lc'
>
>
> Characteristics of this binary (from libperl):
>  Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
>PERL_MALLOC_WRAP USE_ITHREADS USE_LARGE_FILES
>USE_PERLIO USE_REENTRANT_API
>  Built under aix
>  Compiled at Jun  2 2009 16:11:40
>  @INC:
>/usr/opt/perl5/lib/5.8.8/aix-thread-multi
>/usr/opt/perl5/lib/5.8.8
>/usr/opt/perl5/lib/site_perl/5.8.8/aix-thread-multi
>/usr/opt/perl5/lib/site_perl/5.8.8
>/usr/opt/perl5/lib/site_perl
>.
>
> Thanks,
> -Stephen
>
>
>
> 
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and any copy of this
> E-mail and any printout.
>

--
The best compliment you could give Pythian for our service is a referral.

Re: DBD::Oracle: Object support on sparc platforms

[John Scoles]

Yeah that has been around for a long time

I will put that into trunk so it will get into 1.28 which should be out next
week sometime.

Thanks allot Charles

Cheers
John

On Fri, Jan 28, 2011 at 10:25 AM, Charles Jardine  wrote:

> Attached is a patch against DBD::Oracle version 1.27 which corrects
> some type mismatches which prevent the support for objects working
> on big-endian platforms such as Sun-sparc.
>
> There was a thread on this topic in this mail list last April.
> See http://www.mail-archive.com/dbi-users@perl.org/msg32902.html
>
> The original poster reported that tests in t/58object.t in
> version 1.24a did not work on his sparc platform. I posted a patch.
> the OP tested it, and found that my patch allowed him to get further,
> but later tests still failed. I posted a second patch and asked the OP
> to test it. I never got a reply.
>
> The first patch got into DBD::Oracle-1.27, but the second patch,
> being untested, did not.
>
> I have now managed to borrow some sparc hardware. I have re-worked
> the second patch for 1.27, and tested it. With the patch applied,
> DBD::Oracle passes all its tests on a 64-bit sparc running
> Solaris 10. I can now run some of my production scripts, which
> use objects, on the sparc.
>
> I recommend that this patch be incorporated into version 1.28.
>
> --
> Charles Jardine - Computing Service, University of Cambridge
> c...@cam.ac.ukTel: +44 1223 334506, Fax: +44 1223 334679
>

--
The best compliment you could give Pythian for our service is a referral.

Re: Downside to ora_envhp=>0 to fix OCIHandleAlloc(OCI_HTYPE_ERROR) problem

[John Scoles]

I would say simply convert over to Apache::DBI you would not have to change
any of your code except

use DBI;  to

use Apache::DBI


Will most likely solve any problems you are having
cheers


On Thu, Jan 27, 2011 at 4:26 PM, Bill Ward  wrote:

>
>
> On Thu, Jan 27, 2011 at 4:04 AM, John Scoles  wrote:
>
>>  On 26/01/2011 3:35 PM, Bill Ward wrote:
>>
>>> On Wed, Jan 26, 2011 at 12:27 PM, John Scoles
>>>  wrote:
>>>
>>>> Or, is there some way to verify the OCI environment and reset it when
>>>>> it is found to be unusable - in other words, trap the
>>>>> "OCIHandleAlloc(OCI_HTYPE_ERROR)" error and reconnect?
>>>>>
>>>>>  Well normally an environment will not die unless you loose
>>>> connectivity.  If
>>>> you have lost connectivity then there would not be much point in trying
>>>> to
>>>> reconnect automatically your network or DB is Down??
>>>>
>>> Databases go down sometimes.  There could be a power failure or
>>> hardware crash, or maybe the DB is just being bounced by the DBAs
>>> after making a configuration change or upgrade.  The problem is even
>>> if the database comes back up, it still keeps generating the same
>>> error.  Why should I also have to manually restart the Apache server
>>> just because the database has come back online?
>>>
>> That's odd, Are you using Apache::DBI ??? Which version of DBD::Oracle and
>> OCI are you using?
>>
>>
> Nope.  These apps were written long before Apache::DBI was a twinkle in
> Edmund's eye.
>
> We're using DBI 1.607, DBD::Oracle 1.22, and Apache 2.2.9 with mod_perl
> 2.04
>
> I don't know about OCI in particular but we're using Oracle database
> version 10.2.0.4.0.
>
> <#12dc95fa6bae3667_>
> <#12dc95fa6bae3667_> <#12dc95fa6bae3667_>   
> <#12dc95fa6bae3667_>
>

--
The best compliment you could give Pythian for our service is a referral.

Re: Downside to ora_envhp=>0 to fix OCIHandleAlloc(OCI_HTYPE_ERROR) problem

[John Scoles]

 On 26/01/2011 3:35 PM, Bill Ward wrote:

On Wed, Jan 26, 2011 at 12:27 PM, John Scoles  wrote:

Or, is there some way to verify the OCI environment and reset it when
it is found to be unusable - in other words, trap the
"OCIHandleAlloc(OCI_HTYPE_ERROR)" error and reconnect?


Well normally an environment will not die unless you loose connectivity.  If
you have lost connectivity then there would not be much point in trying to
reconnect automatically your network or DB is Down??

Databases go down sometimes.  There could be a power failure or
hardware crash, or maybe the DB is just being bounced by the DBAs
after making a configuration change or upgrade.  The problem is even
if the database comes back up, it still keeps generating the same
error.  Why should I also have to manually restart the Apache server
just because the database has come back online?
That's odd, Are you using Apache::DBI ??? Which version of DBD::Oracle 
and OCI are you using?


cheers
John


  dbi->connect() should
just start working once the DB is back online.  Once that error occurs
once, how about deleting the OCI environment so that the next
->connect after that will succeed?

Re: Downside to ora_envhp=>0 to fix OCIHandleAlloc(OCI_HTYPE_ERROR) problem

[John Scoles]

On 25/01/2011 8:21 PM, William Ward gmail wrote:

In regards to this thread:
http://www.mail-archive.com/dbi-users@perl.org/msg32115.html
(found via google)

I'm having the same problem at $JOB and before we throw ora_envhp=>0
into our connect attribute, we were wondering if this will cause
performance issues?  Is there a downside to ora_envhp that isn't
described in the thread?
Yes that will case some performance slow downs as it will have to 
connect and recreate the environment(connection) for each dbi->connect().
Normally it will reuse the environment(connection) and just create a new 
session for each dbi->connect().


Or, is there some way to verify the OCI environment and reset it when
it is found to be unusable - in other words, trap the
"OCIHandleAlloc(OCI_HTYPE_ERROR)" error and reconnect?



Well normally an environment will not die unless you loose connectivity. 
 If you have lost connectivity then there would not be much point in 
trying to reconnect automatically your network or DB is Down??


Who knows how long it will take to come back up?

I have seen people use Ping to keep the session alive which does test 
the connection each time (does only a single a round trip, in later 
DBD::ORacle versions) if this fails then their programs tries to create 
a new environment(connection) x number of times and eventually fails.



I think there way too many variables here for DBD::Oracle to take care 
of me thinks, there are so many ways to disconnect/loose a session or 
loose connectivity to get them all covered.


Just off the top of my head there are 3 ways to loose a session and at 
least that many for a connection that can be started on the server end 
of things. At this point in time there is no way in DBD::Oracle to tell 
how you lost connectivity, connection or session



What I am working on now for 1.29 (March) is User callback and TAF 
(http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/ocitaf.htm) which 
should address some of these issues


Though TAF is rather obsolete now so I do not see many people using it.

Once that is in there you will at least be able to know how you lost 
connectivity and then program for that.


cheers John

Re: When might DBI v2 be released

[John Scoles]

 On 25/01/2011 10:40 AM, Jonathan Leffler wrote:


On Tue, Jan 25, 2011 at 07:28, John Scoles <mailto:sco...@pythian.com>> wrote:


 On 25/01/2011 10:25 AM, Jonathan Leffler wrote:

Please change the subject line to match the content of the
question!
(Old subject: "DBI 1.611 + DBD::mysql 4.016 = segfaults on
Ubuntu 10.10
amd64 ?"

On Tue, Jan 25, 2011 at 06:54, Tony
Espositomailto:tony1234567...@yahoo.co.uk>>wrote:

Hello Tim,
  Just curious, Tim, when is DBI 2.0 to be released?
 Thanks for all your
hard
work, by the way.  DBI->great_stuff()!

IIRC, the plan (if the term is justified for it) is for DBI v2
to be
released some time (shortly) after Perl 6 is released.


Ah sometime before Easter then;)


Is Perl 6 at that stage, or was there no year specified with that 
Easter (like there hasn't been a year specified for Perl 6 for a 
while).  I gave up tracking Perl 6 a few years ago.  I know that 
Parrot and Rakudo are around and related, but ...


Sorry to get your hopes up Jonathan it is sort of an 'in' joke from one 
of the YAPCes so no year is specified.


I just replaces the 'Perl 6 will be out by Christmas' line.

I guess the idea is now that there is 'a working beta' the first 
production release would be earlier in the year than 'Christmas'.


Cheers
John
(http://dev.perl.org/perl6/faq.html doesn't give any indication of 
which Easter - and previous announcements from 2009 about 2010 show up 
with a Google search for 'perl6 release date').


There was (is?) a DBI v2 mailing list - I don't think I've
seen any messages
on it for about 5 years, and there never were more than a very
few.


--
Jonathan Leffler <mailto:jonathan.leff...@gmail.com>>  #include 

Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease 
to be amused."

Re: When might DBI v2 be released

[John Scoles]

 On 25/01/2011 10:25 AM, Jonathan Leffler wrote:

Please change the subject line to match the content of the question!
(Old subject: "DBI 1.611 + DBD::mysql 4.016 = segfaults on Ubuntu 10.10
amd64 ?"

On Tue, Jan 25, 2011 at 06:54, Tony Espositowrote:


Hello Tim,
   Just curious, Tim, when is DBI 2.0 to be released?  Thanks for all your
hard
work, by the way.  DBI->great_stuff()!


IIRC, the plan (if the term is justified for it) is for DBI v2 to be
released some time (shortly) after Perl 6 is released.


Ah sometime before Easter then;)

There was (is?) a DBI v2 mailing list - I don't think I've seen any messages
on it for about 5 years, and there never were more than a very few.

Re: make test failed with DBD::Oracle 1.27

[John Scoles]

 On 05/01/2011 4:31 AM, ZHANG Jiaqiang A wrote:

Yep those are two known bugs with 64bit system.

Still working on getting rid of them.  It is hard to reproduce  but one 
of the ones we will be fixing soon


The good news is unless you are using embedded objects like VARRY, 
OBJECT or TABLE you can ignore the 58object tests


On 31lob front the test that fails is a rater obscure OCI check dealing 
with the length of a returned lob.  I doubt it will give you a problem


cheers
John

Hello All,

I need your help, now I am trying to use DBD::Oracle on Oracle 11g on Solaris 
10.

I am blocked with two test files: t/31lob.t and t/58object.t:

1)There are some garbled characters when I executed the 31lob.t alone.
2)When I executed the 58object.t alone, it quits without any error msg.


~/DBD-Oracle-1.27$make test
PERL_DL_NONLAZY=1 /home/tester/perl/bin/perl "-MExtUtils::Command::MM" "-e" 
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/01base.t .. # Test loading DBI, DBD::Oracle and version
t/01base.t .. ok
t/10general.t ... ok
t/12impdata.t ... ok
t/14threads.t ... ok
t/15nls.t ... ok
t/20select.t  ok
t/21nchar.t . ok
t/22nchar_al32utf8.t  ok
t/22nchar_utf8.t  ok
t/23wide_db.t ... ok
t/23wide_db_8bit.t .. ok
t/23wide_db_al32utf8.t .. ok
t/24implicit_utf8.t . ok
t/25plsql.t . ok
t/26exe_array.t . ok
t/28array_bind.t  ok
t/30long.t .. ok
t/31lob.t ... Dubious, test returned 1 (wstat 256, 0x100)
Failed 4/12 subtests
t/31lob_extended.t .. ok
t/32xmltype.t ... ok
t/34pres_lobs.t . ok
t/40ph_type.t ... 1/19  Placeholder behaviour for ora_type=1 
VARCHAR2 (the default) varies with Oracle version.
 Oracle 7 didn't strip trailing spaces, Oracle 8 did, until 9.2.x
 Your system doesn't. If that seems odd, let us know.
t/40ph_type.t ... ok
t/50cursor.t  ok
t/51scroll.t  ok
t/55nested.t  ok
t/56embbeded.t .. ok
t/58object.t  Dubious, test returned 1 (wstat 256, 0x100)
Failed 28/51 subtests
t/60reauth.t  skipped: ORACLE_USERID_2 not defined.
t/70meta.t .. ok
t/80ora_charset.t ... ok


Test Summary Report
---
t/31lob.t (Wstat: 256 Tests: 8 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 12 tests but ran 8.
t/58object.t  (Wstat: 256 Tests: 23 Failed: 0)
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 51 tests but ran 23.
Files=30, Tests=2254, 85 wallclock secs ( 2.34 usr  0.72 sys + 44.29 
cusr  4.22 csys = 51.57 CPU)
Result: FAIL
Failed 2/30 test programs. 0/2254 subtests failed.
*** Error code 255
make: Fatal error: Command failed for target `test_dynamic'


~/DBD-Oracle-1.27$perl -Mlib=./lib,./blib/lib,./blib/arch t/31lob.t
1..12
ok 1 - returned valid locator
ok 2 - inserted into BLOB successfully
ok 3 - got back what we put in
ok 4 - returned valid locator
ok 5 - returned valid locator
ok 6 - returned initialized locator
ok 7 - returned length
ok 8 - returned written value
Errors in file :
OCI-21500: internal error code, arguments: [kpullas-1], [], [], [], [], 
[], [], []

}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`Errors
 in file :
OCI-21500: internal error code, arguments: [kpullas-1], [], [], [], [], 
[], [], []

}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`}ãØ¿yÍßsl`~/DBD-Oracle-1.27$

~/DBD-Oracle-1.27$perl -Mlib=./lib,./blib/lib,./blib/arch t/58object.t
1..51
ok 1 - use DBI;
ok 2 - ora_objects flag is set to 1
ok 3 - ora_objects flag is set to 0
ok 4 - The object isa DBI::db
ok 5 - Fetch current schema name
ok 6 - old: Prepare select
ok 7 - old: Execute select
ok 8 - old: Fetch first row
ok 9 - old: Row 1 column 2 is an ARRAY
ok 10 - old: Row 1 column 2 is has 2 elements
ok 11 - old: Fetch second row
ok 12 - old: Row 2 column 2 is an ARRAY
ok 13 - old: Row 2 column 2 is has 2 elements
ok 14 - old: Fetch third row
ok 15 - old: Row 3 column 2 is an ARRAY
ok 16 - old: Row 3 column 

Re: DBD::Oracle, 10g Lob Refetch problem

[John Scoles]

 On 21/12/2010 10:48 AM, Furst, Carl wrote:

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.


If the above is the case then I think I know what your problems int

In later release of 10 and 11 they have removes some permissions by 
default.  One of them is the create session


Check with your DBA that the use that is connection has the create 
session privilege.  Usually this get turned off with an upgrade to 10 or 11.


The root cause is DBD::Oracle will want to create a new session for your 
ORA_CLOB to use to insert all of your clob no matter how big.


I works without the ORA_CLOB because it is just a straight insert up to 
a set value ,the value of 'LongReadLen' me thinks?


Hope this helps.

Cheers
John Scoles


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








**

MLB.com: Where Baseball is Always On

Re: DBD::Oracle, 10g Lob Refetch problem

[John Scoles]

 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

Re: DBD-Oracle Compilation error on OpenVMS

[John Scoles]

Thanks for that

However I an not sure what you did

 dbd_phs_ora_varchar2_table_
>
> fixup_after_execute
>
> with
>
>dbd_phs_ora_varchar2_table_fea
> in
>

does not make any sense to me.  I thinks your email was cut off somehow

can you attach a copy of your DBDIMP.C file so I can have a look at it.

Cheers
John


On Thu, Dec 16, 2010 at 12:50 PM, Jakob noer  wrote:

> I have installed DBD-Oracle on an OpenVMS IA64 box.
>
> Versions:
>
> oracle 10.2.0.4 (Client - Db is 11.1.0.7 on solaris)
> DBI 1.615
> DBD 1.26
> Perl 5.8.6
>
>
> It is as such completed, but I got this error on the way:
>
>
> CC/DECC
> /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/List/Machine/Show=Expan
> /NOANSI_ALIAS/float=ieee/ieee=denorm_results/D
>
> efine=(UTF8_SUPPORT,"ORA_OCI_VERSION=""10.2.0.4""",ORA_OCI_102,"VERSION=""1.26""","XS_VERSION=""1.26""")/Include=(perl_root:[lib.VMS
>
> _IA64.5_8_6.CORE],GLO120:[ORACLE.ORACLE102.oracli.rdbms],GLO120:[ORACLE.ORACLE102.oracli.rdbms.public],GLO120:[ORACLE.ORACLE102.orac
>
> li.rdbms.demo],GLO120:[ORACLE.ORACLE102.oracli.rdbms.demo.oci_demo],GLO120:[ORACLE.ORACLE102.oracli.netconfig.demo],perl_root:[lib.s
> ite_perl.VMS_IA64.auto.DBI])/List/Machine/Show=Expan  DBDIMP.c
>
>if(exe_count <= 0)
> ...^
> %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "exe_count"
> is being compared with a relational operator to a constant whose value is
> not greater than zero.  This might not be what you intended.
> at line number 3564 in file USR:[PERLMOD.DBD-ORACLE-1_26]DBDIMP.C;1
>
> int dbd_phs_ora_varchar2_table_fixup_after_execute(phs_t *phs){
> ^
> %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters;
> truncated to "DBD_PHS_ORA_VARCHAR2_TABLE_FIXU".
> at line number 1897 in file USR:[PERLMOD.DBD-ORACLE-1_26]DBDIMP.C;1
>
> int dbd_phs_ora_number_table_fixup_after_execute(phs_t *phs){
> ^
> %CC-W-LONGEXTERN, The external identifier name exceeds 31 characters;
> truncated to "DBD_PHS_ORA_NUMBER_TABLE_FIXUP_".
> at line number 2263 in file USR:[PERLMOD.DBD-ORACLE-1_26]DBDIMP.C;1
> %MMK-F-ERRUPD, error status %X10B91260 occurred when updating target
> DBDIMP.OBJ
>
> This may well be an OpenVMS problem, that an external identifier name must
> not exceed 31 charachters ?
>
> What I did was replace all occurrencies of
>
>dbd_phs_ora_varchar2_table_fixup_after_execute
>
> with
>
>dbd_phs_ora_varchar2_table_fea
> in
>
>DBDIMP.C
>
> which helped a lot.
>
> Is this a known problem? or a serious one ?
> Venlig hilsen/Regards
>
> Jakob Snoer
>

--
>From the Pythian family to yours, Happy Holidays and all the best in 2011!

Re: DBD-Oracle on AIX

[John Scoles]

I went through this  and checked the patch and it was not fully applied

I have patched trunk and your can find it here

http://svn.perl.org/modules/dbd-oracle/trunk

Please note It will be release in 1.28 not 1.27

Cheers
John Scoles

On Tue, Sep 14, 2010 at 6:48 PM, John R Pierce  wrote:

>  On 09/14/10 6:58 AM, John Scoles wrote:
>
>>  On 9/14/2010 9:17 AM, John R Pierce wrote:
>>
>>> Sorry,  I meant, the make test problems with t/58object on big endian
>>> machines like Sparc, IBM Power
>>>
>>
>> Ok that clears it up a little.
>>
>> I am not sure if it was  fixed yet.
>>
>> Give the latest trunk version a try and see what happens.  Just a side
>> note if you are not using VARRY, TABLE or OBJECT in your tables you can
>> ignore this failure as you will never hit it.
>>
>
> yup, aware thats the case, and yes, we've been ignoring the failure as the
> perl programs in question are truly ancient and wouldn't know what these
> things are if they bit them :)
>
> I'll try and find the time to get around to building this again from trunk
> and seeing whether or not it recurs.
>
>
>

--
>From the Pythian family to yours, Happy Holidays and all the best in 2011!

Re: oracle multiple cursor sub query in different DBI versions

[John Scoles]

A little slow on this one and I apologize for that.

Just closing things out for 1.28 version of DBD::Oracle and noticed this one
hanging about.

So I though I would give it a few tests

I checked 1.24 and it fails but it seems to be fixed in 1.62 and in trunk

So I will check this one off my list for 1.28

Cheers
John Scoles



On Wed, Aug 4, 2010 at 2:27 PM, LK  wrote:

> In the process of moving from centos 4 to a centos 5 machine one
> script stopped working. I distilled it down to this problem :
>
>
> #! /usr/bin/perl -w
> use strict;
> use DBI;
>
> my $dbh = DBI->connect("dbi:Oracle:host=;sid=", '',
> '',
>   {RaiseError => 1,
>AutoCommit => 0,
>LongReadLen => 5000
>}
>   ) || die "Database connection not made:
> $DBI::errstr";
>
> my $q = qq/
>  SELECT
>(2+3),
>cursor(select 2+3 from dual),
>cursor(select 3+3 from dual)
>FROM table where rownum < 10
> /;
>
> my $sth = $dbh->prepare($q);
> $sth->execute();
> while ( my @d = $sth->fetchrow_array ) {
>  print join(" " , @d) . "\t";
>  while ( my @g = $d[1]->fetchrow_array ) {
>  print join(" " ,@g) . "\t";
>  }
>   while ( my @g = $d[2]->fetchrow_array ) {
>  print join(" " ,@g ). "\t";
>  }
>  print "\n";
> }
>
> no problem in sqlplus for this query in either machine.
>
> On the server with DBI 1.58 , DBD::Oracle 1.19 and oracle instant
> client 10.1 it works fine.
>
> On the server with DBI 1.611 , DBD::Oracle 1.24b and oracle instant
> client 11.1 it returns nothing, with no errors.
>
> Use  of DBI_TRACE returns nothing I can work with, it just stops on
> the newer server:
>
>-> prepare for DBD::Oracle::db
> (DBI::db=HASH(0x1be48c80)~0x1be48c40 '
>  SELECT
>(2+3),
>cursor(select 2+3 from dual),
>cursor(select 3+3 from dual)
>FROM table where rownum < 10
> ') thr#1bb1a010
>dbd_st_prepare'd sql SELECT (pl1, auto_lob1, check_sql1)
>dbd_describe SELECT (EXPLICIT, lb 5000)...
> Described col  1: dbtype 2(NVARCHAR2), scale 0, prec 0, nullok 1, name
> (2+3)
>  : dbsize 2, char_used 0, char_size 0, csid 0, csform
> 0(0), disize 171
>fbh 1: '(2+3)'  NULLable, otype   2->  5, dbsize 2/172, p0.s0
> Described col  2: dbtype 116(SQLT_RSET  OCI 8 cursor variable), scale
> 0, prec 0, nullok 1, name CURSOR(SELECT2+3FROMDUAL)
>  : dbsize 8, char_used 0, char_size 0, csid 0, csform
> 0(0), disize 8
>fbh 2: 'CURSOR(SELECT2+3FROMDUAL)'  NULLable, otype 116-
> >116, dbsize 8/8, p0.s0
> Described col  3: dbtype 116(SQLT_RSET  OCI 8 cursor variable), scale
> 0, prec 0, nullok 1, name CURSOR(SELECT3+3FROMDUAL)
>  : dbsize 8, char_used 0, char_size 0, csid 0, csform
> 0(0), disize 8
>fbh 3: 'CURSOR(SELECT3+3FROMDUAL)'  NULLable, otype 116-
> >116, dbsize 8/8, p0.s0
>cache settings DB Handle RowCacheSize=0,Statement Handle
> RowCacheSize=0, OCI_ATTR_PREFETCH_ROWS=339,
> OCI_ATTR_PREFETCH_MEMORY=0, Rows per Fetch=339, Multiple Row Fetch=On
>dbd_describe'd 3 columns (row bytes: 18 max, 20 est avg,
> cache: 0)
><- prepare= DBI::st=HASH(0x1be48ee0) at trek_cursor_query.pl line
> 33
>-> execute for DBD::Oracle::st
> (DBI::st=HASH(0x1be48ee0)~0x1be48e20) thr#1bb1a010
>   dbd_st_execute SELECT (out0, lob0)...
> Statement Execute Mode is 0 (DEFAULT)
>rs_array_init:imp_sth->rs_array_size=2, rs_array_idx=0,
> prefetch_rows=0, rs_array_status=SUCCESS
>dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0)
><- execute= '0E0' at trek_cursor_query.pl line 34
>-> fetchrow_array for DBD::Oracle::st
> (DBI::st=HASH(0x1be48ee0)~0x1be48e20) thr#1bb1a010
>dbd_st_fetch 3 fields...
>
>
>
> Removing one of the cursor statements makes it work on both machines!
> I am out of ideas.
>
> Any ideas are most appreciated!
>
> Thanks,
> LK
>
>
>
>
>
>
>
>

--
>From the Pythian family to yours, Happy Holidays and all the best in 2011!

Re: DBD::Oracle dbd_st_execute slow speed

[John Scoles]

 On 16/12/2010 10:08 AM, ericbamba...@discover.com wrote:

something for 1.29 I guess I am fully booked for 1.28:(

BTW Peat are you able to give the release 1.27 candidate a quick spin??


http://www.pythian.com/news/wp-content/uploads/DBD-Oracle-1.27-RC1.zip


cheers
John



I won't be getting a 10046 trace as it took me several days just to
truncate the table. Yes, in dev. Yay for the paperwork of large
corporations. However, if you're curious, you might be able to recreate
this by having 2 tables related by a FK, insert a few million junk rows
into one then use DELETE FROM $TABLE. Then try to insert in the other.

Multiple versions of perl using multiple versions of DBI and DBD::Oracle
exhibited the problem while sqlplus and sql developer did not so it might
be easy to hit this issue.




"Peter J. Holzer"
12/16/2010 07:29 AM

To

cc

Subject
Re: DBD::Oracle dbd_st_execute slow speed






On 2010-12-16 07:15:02 -0500, John Scoles wrote:

  On 16/12/2010 7:06 AM, Ludwig, Michael wrote:

-Original Message-----
From: John Scoles
More likely SQLplus is spawning a thread while DBD::Oracle does not.

You mean performing the actual work in the background while making
the prompt available for the user to enter the next command?

yep It might I could ask an oracle buddy of mine who works on it if
you want?

Its been a while since the last time I tried to get OCI treads to
work but in the case of an update statement it would make perfect
sense to use them for that as there is no 'return' from the DB like
'select' statement.

Sqlplus does display the result of the insert (either "1 row created."
or a suitable error message (like "ORA-1: unique constraint
(FIWPROD.SYS_C0028271) violated") before the next prompt, so I doubt
very much that it does anything in the background.


SQLplus might also be using the array interface under the hood for
all inserts which could be faster.

It might, but for a single row that shouldn't make much difference.

The 10046 trace will be interesting ...

My guess is that oracle uses an index when the query comes from sqlplus,
but doesn't when the query comes from perl. It is sometimes hard to
determine why Oracle chooses a specific plan.

Oh, and I think it hasn't been mentioned that you can display plans for
queries which have already been executed.

First find the query:

sys...@dbi:Oracle:fiw>  select sql_id, child_number from v$sql
where sql_text= 'select * from setcoords sc where sc.base_set=:p1';
+-++
|SQL_ID   |CHILD_NUMBER|
+-++
|9bvzsg998zgy5|0   |
|9bvzsg998zgy5|1   |
|9bvzsg998zgy5|2   |
+-++
[3 rows of 2 fields returned]


then get the plan for the query:

sys...@dbi:Oracle:fiw>  SELECT * FROM
table(DBMS_XPLAN.DISPLAY_CURSOR('9bvzsg998zgy5', 2));
+---+
|PLAN_TABLE_OUTPUT  |
+---+
|SQL_ID  9bvzsg998zgy5, child number 2  |
|-  |
|select * from setcoords sc where sc.base_set=:p1  |
|  |
|Plan hash value: 1863347061  |
|  |
|---|
|| Id  | Operation | Name  | Rows  | Bytes | Cost (%CPU)| Time
 ||
|---|
||   0 | SELECT STATEMENT  |   |   |   |  7529 (100)|  ||
||*  1 |  TABLE ACCESS FULL| SETCOORDS | 87312 |  1961K|  7529   (2)|
00:01:31 ||
|---|
|  |
|Predicate Information (identified by operation id):  |
|---  |
|  |
|   1 - filter("SC"."BASE_SET"=TO_NUMBER(:P1))  |
|  |
+---+
[18 rows of 1 fields returned]

You need special privileges for that, though. I don't think a normal
user can do it even for their own queries.

 hp