Re: Perl and Oracle using DBI on HP/UX with perl compiled using HP POSIX C compiler
On Wed, Mar 25, 2009 at 1:18 PM, McCoy, Dennis wrote: > > I am using perl on a HP/UX system which is managed by another group who > has root access. I have no such access on this server. > > I tried compling DBD::Oracle on HP/UX, but the POSIX compliant C > compiler on that system complained that the command line options were > for ANSI C. I requested the group which manages the What system was perl compiled on? And what compiler did they use? You normally want aCC (my perl -V says CC='cc' but cc is the same as the softbench aCC compiler on my system). Your perl was likely not compiled with the bundled compiler, and you need a different compiler (or get someone with a compiler to compile for you). Or there are HP binaries available here (compiled w/gcc): http://mirrors.develooper.com/hpux/ Also I documented my HP compiling adventures here: http://use.perl.org/~runrig/journal/35908 HTH, Douglas Wilson
Perl and Oracle using DBI on HP/UX with perl compiled using HP POSIX C compiler
Folks: I am using perl on a HP/UX system which is managed by another group who has root access. I have no such access on this server. I tried compling DBD::Oracle on HP/UX, but the POSIX compliant C compiler on that system complained that the command line options were for ANSI C. I requested the group which manages the HP/UX system to install DBI and DBD::Oracle. They too had the same issue with the POSIX C compiler fussing. After a few back and forth emails about the necessity for an ANSI compliant C compiler, it looked like they would have to re-build perl and they have no love for that. I would rather not resort to using system calls to SQL*Plus from my perl scripts if at all possible. Is there another option available for my situation which you could recommend? Thanks, Dennis McCoy E-Commerce Analyst Delphi, Vega Team (248) 808-4347 Cell dennis.mc...@delphi.com
RE: DBD::Oracle on Oracle 11g 64 bit fedora 10
from what i've seen if ANY 32bit library found in the path
(LD_LIBRARY_PATH/LIB) causes
the process fails back to 32 bit behaviour
Just as a test I have a processor which is 64bit and when I load in 64bit
(Oracle Type 2 Oracle Call Interface) libraries the performance more than
doubles
My 2 cents
Martin
__
Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
This message is confidential and may be privileged. If you are not the intended
recipient, we kindly ask you to please inform the sender. Any unauthorised
dissemination or copying hereof is prohibited. This message serves for
information purposes only and shall not have any legally binding effect. Given
that e-mails can easily be subject to manipulation, we can not accept any
liability for the content provided.
> From: g.russ...@napier.ac.uk
> To: shild...@scotth.emsphone.com
> CC: dbi-users@perl.org
> Date: Wed, 25 Mar 2009 21:07:53 +
> Subject: RE: DBD::Oracle on Oracle 11g 64 bit fedora 10
>
>
> Hi.
> No still no good solution. However it doesnt seem to make any difference.
> I have been running this in a production server without error for 2 months
> now.
> I downloaded the development version directly, and I couldnt see any real
> difference in the messages, and thus I stuck with the released version.
>
> Let me know if you many any discoveries.
> Gordon.
>
>
> From: Scott T. Hildreth [shild...@scotth.emsphone.com]
> Sent: 25 March 2009 19:44
> To: Russell, Gordon
> Cc: dbi-users@perl.org
> Subject: Re: DBD::Oracle on Oracle 11g 64 bit fedora 10
>
> On Mon, 2009-01-19 at 20:26 +, Russell, Gordon wrote:
> >
> > Hi. I am hoping someone can look over this install info and tell me if it
> > is all ok?
> >
> > I am having some worries with a new install of fedora 10.
> > I also installed oracle 11.1.0.7.
> > I have the latest DBI and am installing DBD Oracle 1.22. Note I have used
> > DBD and Oracle for many many years.
> > I have a 64 bit environment, UTF8 database and linux, with 32 bit
> > compatibility libraries installed only to make the oracle installer tests
> > happy.
> >
>
> Gordon,
>
> Did you ever resolve this? We are moving to 11g now and I am having
> the same issue. I originally thought it was a 11g client => 10g db
> problem, but I can reproduce it trying to compile DBD::Oracle using a
> 11g db. Oracle 11.1.0.7.0 is installed on SUSE Linux Enterprise Server
> 10 (x86_64).
>
> Thanks,
> Scott.
>
> > In short, it works but produces some test errors. Not sure if I should just
> > ignore them!
> > Plenty of information follows... any suggestions appreciated.
> >
> > When building DBD Oracle, the tests come up with 3 fails:
> > Test Summary Report
> > ---
> > t/26exe_array (Wstat: 512 Tests: 14 Failed: 2)
> > Failed tests: 11, 14
> > Non-zero exit status: 2
> > t/30long(Wstat: 512 Tests: 30 Failed: 0)
> > Non-zero exit status: 2
> > Parse errors: Bad plan. You planned 479 tests but ran 30.
> > t/31lob (Wstat: 256 Tests: 6 Failed: 1)
> > Failed test: 6
> > Non-zero exit status: 1
> > Parse errors: Bad plan. You planned 9 tests but ran 6.
> >
> > The actual errors are:
> > t/26exe_array...
> > Dubious, test returned 2 (wstat 512, 0x200)
> > Failed 2/14 subtests
> > t/30longpanic: sv_len_utf8 cache 10240 real 81920 for
> > 1234
> > t/31lob.DBD::Oracle::st execute failed: ORA-24813: cannot
> > send or receive an unsupported LOB (DBD ERROR: OCIStmtExecute) [for
> > Statement "BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;" with ParamValues:
> > :p1=undef, :p2=OCILobLocatorPtr=SCALAR(0x19cb018)] at t/31lob.t line 108.
> >
> > Installing it anyway seems ok, but running:
> > my $dbh = DBI->connect_cached('dbi:Oracle:sid',username,password,{
> > RaiseError=> 1,
> > PrintError=> 0,
> > ShowErrorStatement=> 1,
> > AutoCommit=> 0,
> > ora_verbose=>6
> >
> > })
> > Produces:
> > OCINlsEnvironmentVariableGet(871,0,93,0,2)=SUCCESS
> > OCINlsEnvironmentVariableGet(871,0,94,0,2)=SUCCESS
> > OCINlsEnvCreate(1b8c5d0,THREADED |
> > OBJECT,3,0,0,0,0,0,0,871,871)=SUCCESS
> > OCIHandleAlloc(1c06220,1b8c5d8,OCI_HTYPE_ERROR,0,0)=SUCCESS
> >charset id=871, name=UTF8, ncharset id=871, name=UTF8 (csid:
> > utf8=871 al32utf8=873)
> > OCIHandleAlloc(1c06220,1b8c5e0,OCI_HTYPE_SERVER
RE: DBD::Oracle on Oracle 11g 64 bit fedora 10
Hi.
No still no good solution. However it doesnt seem to make any difference.
I have been running this in a production server without error for 2 months now.
I downloaded the development version directly, and I couldnt see any real
difference in the messages, and thus I stuck with the released version.
Let me know if you many any discoveries.
Gordon.
From: Scott T. Hildreth [shild...@scotth.emsphone.com]
Sent: 25 March 2009 19:44
To: Russell, Gordon
Cc: dbi-users@perl.org
Subject: Re: DBD::Oracle on Oracle 11g 64 bit fedora 10
On Mon, 2009-01-19 at 20:26 +, Russell, Gordon wrote:
>
> Hi. I am hoping someone can look over this install info and tell me if it is
> all ok?
>
> I am having some worries with a new install of fedora 10.
> I also installed oracle 11.1.0.7.
> I have the latest DBI and am installing DBD Oracle 1.22. Note I have used DBD
> and Oracle for many many years.
> I have a 64 bit environment, UTF8 database and linux, with 32 bit
> compatibility libraries installed only to make the oracle installer tests
> happy.
>
Gordon,
Did you ever resolve this? We are moving to 11g now and I am having
the same issue. I originally thought it was a 11g client => 10g db
problem, but I can reproduce it trying to compile DBD::Oracle using a
11g db. Oracle 11.1.0.7.0 is installed on SUSE Linux Enterprise Server
10 (x86_64).
Thanks,
Scott.
> In short, it works but produces some test errors. Not sure if I should just
> ignore them!
> Plenty of information follows... any suggestions appreciated.
>
> When building DBD Oracle, the tests come up with 3 fails:
> Test Summary Report
> ---
> t/26exe_array (Wstat: 512 Tests: 14 Failed: 2)
> Failed tests: 11, 14
> Non-zero exit status: 2
> t/30long(Wstat: 512 Tests: 30 Failed: 0)
> Non-zero exit status: 2
> Parse errors: Bad plan. You planned 479 tests but ran 30.
> t/31lob (Wstat: 256 Tests: 6 Failed: 1)
> Failed test: 6
> Non-zero exit status: 1
> Parse errors: Bad plan. You planned 9 tests but ran 6.
>
> The actual errors are:
> t/26exe_array...
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/14 subtests
> t/30longpanic: sv_len_utf8 cache 10240 real 81920 for 1234
> t/31lob.DBD::Oracle::st execute failed: ORA-24813: cannot
> send or receive an unsupported LOB (DBD ERROR: OCIStmtExecute) [for Statement
> "BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;" with ParamValues: :p1=undef,
> :p2=OCILobLocatorPtr=SCALAR(0x19cb018)] at t/31lob.t line 108.
>
> Installing it anyway seems ok, but running:
> my $dbh = DBI->connect_cached('dbi:Oracle:sid',username,password,{
> RaiseError=> 1,
> PrintError=> 0,
> ShowErrorStatement=> 1,
> AutoCommit=> 0,
> ora_verbose=>6
>
> })
> Produces:
> OCINlsEnvironmentVariableGet(871,0,93,0,2)=SUCCESS
> OCINlsEnvironmentVariableGet(871,0,94,0,2)=SUCCESS
> OCINlsEnvCreate(1b8c5d0,THREADED |
> OBJECT,3,0,0,0,0,0,0,871,871)=SUCCESS
> OCIHandleAlloc(1c06220,1b8c5d8,OCI_HTYPE_ERROR,0,0)=SUCCESS
>charset id=871, name=UTF8, ncharset id=871, name=UTF8 (csid: utf8=871
> al32utf8=873)
> OCIHandleAlloc(1c06220,1b8c5e0,OCI_HTYPE_SERVER,0,0)=SUCCESS
> OCIHandleAlloc(1c06220,1b8c5e8,OCI_HTYPE_SVCCTX,0,0)=SUCCESS
> OCIServerAttach(1c45608, 1c44e68, "sid", 3, mode=DEFAULT,0)=SUCCESS
> OCIAttrSet(1c44d90,OCI_HTYPE_SVCCTX,1c45608,0,6,1c44e68)=SUCCESS
> OCIHandleAlloc(1c06220,1b8c5f0,OCI_HTYPE_SESSION,0,0)=SUCCESS
> OCIAttrSet(1c81838,OCI_HTYPE_SESSION,1a1d348,8,22,1c44e68)=SUCCESS
> OCIAttrSet(1c81838,OCI_HTYPE_SESSION,1917d08,6,23,1c44e68)=SUCCESS
> OCISessionBegin(1c44d90,1c44e68,1c81838,1,mode=DEFAULT 0)=SUCCESS
> OCIAttrSet(1c44d90,OCI_HTYPE_SVCCTX,1c81838,0,7,1c44e68)=SUCCESS
> "DBI::db=HASH(0x1919710)" is not exported by the DBD::Oracle module
> Can't continue after import errors at ./demo.pl line 7
> BEGIN failed--compilation aborted at ./demo.pl line 15.
> OCITransRollback(1c44d90,1c44e68,mode=DEFAULT 0)=SUCCESS
> OCISessionEnd(1c44d90,1c44e68,1c81838,mode=DEFAULT 0)=SUCCESS
> OCIServerDetach(1c45608,1c44e68,mode=DEFAULT,0)=SUCCESS
> OCIHandleFree(1c81838,OCI_HTYPE_SESSION)=SUCCESS
> OCIHandleFree(1c45608,OCI_HTYPE_SERVER)=SUCCESS
> OCIHandleFree(1c44d90,OCI_HTYPE_SVCCTX)=SUCCESS
> OCIHandleFree(1c44e68,OCI_HTYPE_ERROR)=SUCCESS
>
> Looking through the makefile and running ldd on the .so file it seems to have
> only used the 64 bit oracle libraries
> Let me know if I can add anything.
>
> Thanks
> Gordon.
>
>
> Napier University is the best modern university in Scotland* and number one
> in Scotland for graduate employability**
> (*Guardian University Guide 2009)
> (**HESA 2008)
>
> This message is intended for the addressee(s) only and shoul
Re: DBD::Oracle on Oracle 11g 64 bit fedora 10
On Mon, 2009-01-19 at 20:26 +, Russell, Gordon wrote:
>
> Hi. I am hoping someone can look over this install info and tell me if it is
> all ok?
>
> I am having some worries with a new install of fedora 10.
> I also installed oracle 11.1.0.7.
> I have the latest DBI and am installing DBD Oracle 1.22. Note I have used DBD
> and Oracle for many many years.
> I have a 64 bit environment, UTF8 database and linux, with 32 bit
> compatibility libraries installed only to make the oracle installer tests
> happy.
>
Gordon,
Did you ever resolve this? We are moving to 11g now and I am having
the same issue. I originally thought it was a 11g client => 10g db
problem, but I can reproduce it trying to compile DBD::Oracle using a
11g db. Oracle 11.1.0.7.0 is installed on SUSE Linux Enterprise Server
10 (x86_64).
Thanks,
Scott.
> In short, it works but produces some test errors. Not sure if I should just
> ignore them!
> Plenty of information follows... any suggestions appreciated.
>
> When building DBD Oracle, the tests come up with 3 fails:
> Test Summary Report
> ---
> t/26exe_array (Wstat: 512 Tests: 14 Failed: 2)
> Failed tests: 11, 14
> Non-zero exit status: 2
> t/30long(Wstat: 512 Tests: 30 Failed: 0)
> Non-zero exit status: 2
> Parse errors: Bad plan. You planned 479 tests but ran 30.
> t/31lob (Wstat: 256 Tests: 6 Failed: 1)
> Failed test: 6
> Non-zero exit status: 1
> Parse errors: Bad plan. You planned 9 tests but ran 6.
>
> The actual errors are:
> t/26exe_array...
> Dubious, test returned 2 (wstat 512, 0x200)
> Failed 2/14 subtests
> t/30longpanic: sv_len_utf8 cache 10240 real 81920 for 1234
> t/31lob.DBD::Oracle::st execute failed: ORA-24813: cannot
> send or receive an unsupported LOB (DBD ERROR: OCIStmtExecute) [for Statement
> "BEGIN ? := DBMS_LOB.GETLENGTH( ? ); END;" with ParamValues: :p1=undef,
> :p2=OCILobLocatorPtr=SCALAR(0x19cb018)] at t/31lob.t line 108.
>
> Installing it anyway seems ok, but running:
> my $dbh = DBI->connect_cached('dbi:Oracle:sid',username,password,{
> RaiseError=> 1,
> PrintError=> 0,
> ShowErrorStatement=> 1,
> AutoCommit=> 0,
> ora_verbose=>6
>
> })
> Produces:
> OCINlsEnvironmentVariableGet(871,0,93,0,2)=SUCCESS
> OCINlsEnvironmentVariableGet(871,0,94,0,2)=SUCCESS
> OCINlsEnvCreate(1b8c5d0,THREADED |
> OBJECT,3,0,0,0,0,0,0,871,871)=SUCCESS
> OCIHandleAlloc(1c06220,1b8c5d8,OCI_HTYPE_ERROR,0,0)=SUCCESS
>charset id=871, name=UTF8, ncharset id=871, name=UTF8 (csid: utf8=871
> al32utf8=873)
> OCIHandleAlloc(1c06220,1b8c5e0,OCI_HTYPE_SERVER,0,0)=SUCCESS
> OCIHandleAlloc(1c06220,1b8c5e8,OCI_HTYPE_SVCCTX,0,0)=SUCCESS
> OCIServerAttach(1c45608, 1c44e68, "sid", 3, mode=DEFAULT,0)=SUCCESS
> OCIAttrSet(1c44d90,OCI_HTYPE_SVCCTX,1c45608,0,6,1c44e68)=SUCCESS
> OCIHandleAlloc(1c06220,1b8c5f0,OCI_HTYPE_SESSION,0,0)=SUCCESS
> OCIAttrSet(1c81838,OCI_HTYPE_SESSION,1a1d348,8,22,1c44e68)=SUCCESS
> OCIAttrSet(1c81838,OCI_HTYPE_SESSION,1917d08,6,23,1c44e68)=SUCCESS
> OCISessionBegin(1c44d90,1c44e68,1c81838,1,mode=DEFAULT 0)=SUCCESS
> OCIAttrSet(1c44d90,OCI_HTYPE_SVCCTX,1c81838,0,7,1c44e68)=SUCCESS
> "DBI::db=HASH(0x1919710)" is not exported by the DBD::Oracle module
> Can't continue after import errors at ./demo.pl line 7
> BEGIN failed--compilation aborted at ./demo.pl line 15.
> OCITransRollback(1c44d90,1c44e68,mode=DEFAULT 0)=SUCCESS
> OCISessionEnd(1c44d90,1c44e68,1c81838,mode=DEFAULT 0)=SUCCESS
> OCIServerDetach(1c45608,1c44e68,mode=DEFAULT,0)=SUCCESS
> OCIHandleFree(1c81838,OCI_HTYPE_SESSION)=SUCCESS
> OCIHandleFree(1c45608,OCI_HTYPE_SERVER)=SUCCESS
> OCIHandleFree(1c44d90,OCI_HTYPE_SVCCTX)=SUCCESS
> OCIHandleFree(1c44e68,OCI_HTYPE_ERROR)=SUCCESS
>
> Looking through the makefile and running ldd on the .so file it seems to have
> only used the 64 bit oracle libraries
> Let me know if I can add anything.
>
> Thanks
> Gordon.
>
>
> Napier University is the best modern university in Scotland* and number one
> in Scotland for graduate employability**
> (*Guardian University Guide 2009)
> (**HESA 2008)
>
> This message is intended for the addressee(s) only and should not be read,
> copied or disclosed to anyone else outwith the University without the
> permission of the sender.
> It is your responsibility to ensure that this message and any attachments are
> scanned for viruses or other defects. Napier University does not accept
> liability for any loss or damage which may result from this email or any
> attachment, or for errors or omissions arising after it was sent. Email is
> not a secure medium. Email entering the University's system is subject to
> routine monitoring and filtering by the University.
> Napi
ANNOUNCE - Set::Relation versions 0.8.0 and 0.9.0 for Perl 5
All, I am pleased to announce that Set::Relation (relational types and operators for Perl) versions 0.8.0 and 0.9.0 for Perl 5 have been released on CPAN. http://search.cpan.org/dist/Set-Relation/ First, to briefly repeat the change information for last month's release 0.7.0 (from 0.6.0 which was the first initial-feature-complete release): Set::Relation is now a role (or actually 2 roles, one immutable, one mutable), so it is easier for user code to just say they accept any objects doing that role, and the initial implementation was separated into another file called V1. It is now also easier for third parties to make distinct implementations if they wish. And yes, this role is in terms of an actual Moose role. Now the main change in version 0.8.0 from version 0.7.0 is the addition of a second bundled implementation of the Set::Relation role, called V2. Feature-wise, V2 should have considerably better performance than V1 in general, and especially for some use cases. V2 also does strictly immutable objects while V1 does mutable objects. Design-wise, both V1 and V2 are similar in many respects, including the use of a Perl Hash internally to represent each relation tuple. How they differ mainly is that V1 does eager tuple hashing and duplicate elimination while V2 does lazy tuple hashing and duplicate elimination. Another feature change in 0.8.0 from 0.7.0 is that users have the option on some Set::Relation method calls to say they accept less accuracy in results, so for example they give permission for duplicate elimination to be skipped entirely, and what they gain from this conceptually is an even greater speed increase. Now the kind of operations where you would likely see the greatest speed increase with V2 automatically, are for [new(), union(), insertion()] as they are done with zero hashing or elimination; and to a lesser extent join() etc since it only indexes the common attributes on the join; and optionally on cardinality() and members extraction, as they also avoid all hashing/etc when explicitly asked to, thereby the class sort-of doing multisets rather than sets as normal. In contrast with V2, operations like [intersection(), difference(), deletion()] still incur indexing / duplicate elimination in order to make sure all copies of a filtered-out tuple are eliminated. Version 0.8.0 does not introduce any major API changes or capability features. Note that I recommend V2 over V1 for actual use, where either would be useful; I don't consider them on equal footing. And the main change in version 0.9.0 from version 0.8.0 is the addition of support for specifying candidate keys or (unique) key constraints on Set::Relation objects at object creation time, and introspecting for candidate keys on the objects after creation. Version 0.9.0 was just a first draft of the 'keys' feature and it isn't very well integrated. What is stated above is about as far as it goes. Still TODO is to actually exploit knowledge of keys to speed up the relational operators, since you can do indexing or duplicate elimination much less expensively if you know you only have to examine a subset of the attributes' values. On a related matter, today I updated http://www.perlfoundation.org/perl5/index.cgi?gsoc_2009_projects to add a student project idea to implement Perl 6 savvy relational types and operators, starting with porting Set::Relation to Perl 6. Now said port was something I otherwise would have done within the next few months, and the Perl 5 module was designed from day one that this would happen in mind, but I figured this was something it would be nice to have a fresh outlook on, since someone else say a student may come up with the functionality in much more idiomatic Perl 6 than I would have. And its not like any prerequisites they might need from me aren't already done now; the existing Perl 5 version already illustrates the desired features and behavior, which they are of course free to improve on. Now in the likely event that no student picks this up, I welcome input from you / the community on how to do better than a straight port and provide better Perl 6 savvyness. Thank you and have a good day. -- Darren Duncan
