perl.dbi.users

perl.dbi.users http://www.nntp.perl.org/group/perl.dbi.users/ ... Copyright 1998-2013 perl.org Tue, 18 Jun 2013 04:36:17 +0000 ask@perl.org Re: (Fwd) Quick Perl Questions - DBI and DBD by Martin J. Evans On 10/06/2013 19:14, Prindle, Douglas E wrote: > Hi John. > > Thanks a bunch for responding. > > Yes we had a new oracle 11 client installed as well. > > So with that in mind should I recompile or not ? > > *Thank You,* > *Douglas E. Prindle*| Credit Decisioning Systems | Apollo Infrastructure > ((904) 954-2472 |6(904) 954-6305 |*douglas.e.prindle@citi.com > <mailto:douglas.e.prindle@citi.com> When you upgrade your Oracle client libs you should generally rebuild DBD::Oracle. Some features in DBD::Oracle depend on the version of Oracle client libs you build against. Also, there is nothing I'm aware from Oracle that says they cannot change the Oracle client libs so you could hit some incompatibility if you don't recompile. Martin -- Martin J. Evans Wetherby, UK http://www.nntp.perl.org/group/perl.dbi.users/2013/06/msg36628.html Wed, 12 Jun 2013 20:14:25 +0000 RE: (Fwd) Quick Perl Questions - DBI and DBD by Prindle, Douglas E Hi John. Thanks a bunch for responding. Yes we had a new oracle 11 client installed as well. So with that in mind should I recompile or not ? Thank You, Douglas E. Prindle | Credit Decisioning Systems | Apollo Infrastructure *(904) 954-2472 | 6(904) 954-6305 | * douglas.e.prindle@citi.com<mailto:douglas.e.prindle@citi.com> ________________________________ From: John Scoles [mailto:byterock@hotmail.com] Sent: Monday, June 10, 2013 1:58 PM To: Prindle, Douglas E [GCG-NAOT]; dbi-users@perl.org Subject: RE: (Fwd) Quick Perl Questions - DBI and DBD 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.Bunce@pobox.com > To: dbi-users@perl.org > CC: douglas.e.prindle@citi.com > Subject: (Fwd) Quick Perl Questions - DBI and DBD > > ----- Forwarded message from "Prindle, Douglas E " <douglas.e.prindle@citi.com> ----- > > Date: Mon, 10 Jun 2013 15:11:26 +0000 > From: "Prindle, Douglas E " <douglas.e.prindle@citi.com> > To: "Tim.Bunce@pobox.com" <Tim.Bunce@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.prindle@citi.com > > > ----- End forwarded message ----- http://www.nntp.perl.org/group/perl.dbi.users/2013/06/msg36627.html Mon, 10 Jun 2013 21:20:40 +0000 RE: (Fwd) Quick Perl Questions - DBI and DBD by 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.Bunce@pobox.com > To: dbi-users@perl.org > CC: douglas.e.prindle@citi.com > Subject: (Fwd) Quick Perl Questions - DBI and DBD > > ----- Forwarded message from "Prindle, Douglas E " <douglas.e.prindle@citi.com> ----- > > Date: Mon, 10 Jun 2013 15:11:26 +0000 > From: "Prindle, Douglas E " <douglas.e.prindle@citi.com> > To: "Tim.Bunce@pobox.com" <Tim.Bunce@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.prindle@citi.com > > > ----- End forwarded message ----- http://www.nntp.perl.org/group/perl.dbi.users/2013/06/msg36626.html Mon, 10 Jun 2013 17:58:26 +0000 (Fwd) Quick Perl Questions - DBI and DBD by Tim.Bunce@pobox.com ----- Forwarded message from "Prindle, Douglas E " <douglas.e.prindle@citi.com> ----- Date: Mon, 10 Jun 2013 15:11:26 +0000 From: "Prindle, Douglas E " <douglas.e.prindle@citi.com> To: "Tim.Bunce@pobox.com" <Tim.Bunce@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.prindle@citi.com ----- End forwarded message ----- http://www.nntp.perl.org/group/perl.dbi.users/2013/06/msg36625.html Mon, 10 Jun 2013 16:55:18 +0000 Re: DBI Driver.xst and DBD::cego by Jonathan Leffler Since the only place 'plural' is used is the statement immediately after the assignment, it is much simpler and perfectly safe to use const char *plural = ... than to futz around with the myp array as in the second patch (or to cast away constness as in the first patch). On Mon, May 27, 2013 at 8:16 AM, Kurt Jaeger <dbi-users@opsec.eu> wrote: > Hi! > > Tim wrote: > > On Sun, May 26, 2013 at 08:13:58PM +0200, Kurt Jaeger wrote: > > > https://rt.cpan.org/Ticket/Display.html?id=84285 > > > > error: invalid conversion from 'const char*' to 'char*' > > > > I'm surprised the compiler treats this as an error, it's normally a > warning. > > > - char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; > > + char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? (char*)"" : > (char*)"s"; > > clang++ is more strict 8-} > > > > Can someone have a look at it ? Is that patch the right way to do it ? > > > > It would be better to put the const on the declaration in this case. > I.e.: > > > > - char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; > > + const char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; > > > > but that may trigger other errors/warnings in later code which will need > > attending to. (Same goes for the other hunk in the patch.) > > > > Could you give that a go? > > Have you seen my second attempt ? It's going along the clang line > and seems much cleaner. > > -- > pi@opsec.eu +49 171 3101372 7 years to > go ! > -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36624.html Mon, 27 May 2013 18:19:26 +0000 Re: DBI Driver.xst and DBD::cego by Kurt Jaeger Hi! Tim wrote: > On Sun, May 26, 2013 at 08:13:58PM +0200, Kurt Jaeger wrote: > > https://rt.cpan.org/Ticket/Display.html?id=84285 > > error: invalid conversion from 'const char*' to 'char*' > > I'm surprised the compiler treats this as an error, it's normally a warning. > - char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; > + char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? (char*)"" : (char*)"s"; clang++ is more strict 8-} > > Can someone have a look at it ? Is that patch the right way to do it ? > > It would be better to put the const on the declaration in this case. I.e.: > > - char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; > + const char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; > > but that may trigger other errors/warnings in later code which will need > attending to. (Same goes for the other hunk in the patch.) > > Could you give that a go? Have you seen my second attempt ? It's going along the clang line and seems much cleaner. -- pi@opsec.eu +49 171 3101372 7 years to go ! http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36623.html Mon, 27 May 2013 15:17:03 +0000 Re: DBI Driver.xst and DBD::cego by Tim Bunce Hi Kurt. On Sun, May 26, 2013 at 08:13:58PM +0200, Kurt Jaeger wrote: > https://rt.cpan.org/Ticket/Display.html?id=84285 error: invalid conversion from 'const char*' to 'char*' I'm surprised the compiler treats this as an error, it's normally a warning. - char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; + char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? (char*)"" : (char*)"s"; > Can someone have a look at it ? Is that patch the right way to do it ? It would be better to put the const on the declaration in this case. I.e.: - char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; + const char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? "" : "s"; but that may trigger other errors/warnings in later code which will need attending to. (Same goes for the other hunk in the patch.) Could you give that a go? Tim. http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36622.html Mon, 27 May 2013 15:10:57 +0000 DBI Driver.xst and DBD::cego by Kurt Jaeger Hi! I try to maintain the FreeBSD port databases/p5-DBD-cego, and it has a problem if I compile it with clang. http://www.freebsd.org/cgi/query-pr.cgi?pr=178755 I investigated and I think it is caused by issues in DBI, more exactly, issues in Driver.xst ? I made a first try on a fix in March, and a second one today: https://rt.cpan.org/Ticket/Display.html?id=84285 Can someone have a look at it ? Is that patch the right way to do it ? -- pi@opsec.eu +49 171 3101372 7 years to go ! http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36621.html Sun, 26 May 2013 18:14:11 +0000 Re: DBI article in Korean by Martin J. Evans On 24/05/13 06:51, Gabor Szabo wrote: > Hi, > > On Wed, May 22, 2013 at 10:08 PM, Martin J. Evans <bohica@ntlworld.com> wrote: > >> Another good tutorial - please keep up the good work of promoting Perl. > > Thanks. I hope others will also help promoting my articles and interviews. > >> "The DSN (Data Source Name) (in the $dsn variable) is very straight forward. >> It contains the type of the database. That will be the clue to DBI which DBD >> to load. In case of SQLite, the only thing we really need is the path to the >> database file." >> >> It may be a language thing but it is hardly a "clue". DBI clearly states the >> connection string is dbi:DRIVER_NAME:something_else and DRIVER_NAMEs are >> registered with DBI. Its also not always as "straight forward" as you >> suggest as the something_else is usually a ';' separated string of >> attributes and values e.g. "DRIVER={this driver}". > > I know it can be more complex than my example, but I don't have to > frighten away the reader :) > I am confused with your comment about the word "clue". Isn't the name > of DBD::* derived from > the DRIVER_NAME ? Or does clue mean something else then guiding information? > Or do you mean that DRIVER_NAME is exact and a "clue" is only a direction? I was only commenting on the use of the word "clue". Clue is usually read a little like hint. A clue usually gives you some information but is not everything you need to know whereas the DRIVER_NAME is everything. > >> "The call to disconnect from the database is optional as it will >> automatically be called when the variable $dbh goes out of scope, but it >> having it might be a clear indication for the next programmer dealing with >> this code, that you are done with the database. " >> >> There are a number of gotchas with this. You may still have a select >> statement active where you've not fetched all the rows yet from the cursor >> in which case you'll get a warning. Also, you may be in the middle of a >> transaction and in that case the transaction may be rolled back. > > Are these gotchas different in case $dbh goes out of scope and when I > call $dbh->disconnect ? I'm afraid so because in one case the DBD knows and in the other case it doesn't. Then there is PrintWarn and Warn. use 5.010; use strict; use warnings; use DBI; my $h = DBI->connect("dbi:ODBC:baugi", "xx", "yy", {RaiseError => 1, PrintError => 0, PrintWarn => 0}); eval { $h->do(q/drop table mje/); }; $h->do(q/create table mje (a integer)/); my $s = $h->prepare(q/insert into mje values(?)/); $s->execute_array(undef, [1,2,3,4,5]); $h->disconnect; doit(Disconnect => 1, PrintWarn => 1, Warn => 1, Txn => 0); doit(Disconnect => 0, PrintWarn => 1, Warn => 1, Txn => 0); doit(Disconnect => 1, PrintWarn => 1, Warn => 0, Txn => 0); doit(Disconnect => 1, PrintWarn => 1, Warn => 1, Txn => 1); doit(Disconnect => 0, PrintWarn => 1, Warn => 1, Txn => 1); doit(Disconnect => 1, PrintWarn => 1, Warn => 0, Txn => 1); sub doit { my %args = @_; say "Disconnect=$args{Disconnect}, PrintWarn=$args{PrintWarn}, ", "Warn=$args{Warn}, ", ($args{Txn} ? "Uncommitted txn" : "Unfinished select"); my $h = DBI->connect("dbi:ODBC:baugi", "xx", "yy", {RaiseError => 1, PrintError => 0, PrintWarn => $args{PrintWarn}}); $h->{Warn} = $args{Warn}; my $s; if ($args{Txn}) { $h->{AutoCommit} = 0; $s = $h->prepare(q/delete from mje where a = ?/); $s->execute(1); } else { $s = $h->prepare(q/select * from mje/); $s->execute; $s->fetch; } if ($args{Disconnect}) { say " Disconnecting with Warn=$args{Warn}, PrintWarn=$args{PrintWarn}"; $h->disconnect; } else { say " connection handle going out of scope"; } } produces: Disconnect=1, PrintWarn=1, Warn=1, Unfinished select Disconnecting with Warn=1, PrintWarn=1 DBI::db=HASH(0x89ac660)->disconnect invalidates 1 active statement handle (either destroy statement handles or call finish on them before disconnecting) at /tmp/x.pl line 50. Disconnect=0, PrintWarn=1, Warn=1, Unfinished select connection handle going out of scope Disconnect=1, PrintWarn=1, Warn=0, Unfinished select Disconnecting with Warn=0, PrintWarn=1 Disconnect=1, PrintWarn=1, Warn=1, Uncommitted txn Disconnecting with Warn=1, PrintWarn=1 DBD::ODBC::db disconnect warning: Disconnect with transaction in progress - rolling back at /tmp/x.pl line 50. Disconnect=0, PrintWarn=1, Warn=1, Uncommitted txn connection handle going out of scope Issuing rollback() due to DESTROY without explicit disconnect() of DBD::ODBC::db handle baugi at /tmp/x.pl line 22. Disconnect=1, PrintWarn=1, Warn=0, Uncommitted txn Disconnecting with Warn=0, PrintWarn=1 DBD::ODBC::db disconnect warning: Disconnect with transaction in progress - rolling back at /tmp/x.pl line 50. Note how connection handle going out of scope when an unfinished select does not generate anything but calling disconnect does and then specifically calling disconnect but disabling Warn hides the warning. Note for the txn example, in the first case when you call disconnect it gets to the DBD which knows you have a txn in progress so it rolls it back (note the DBD::ODBC in the message) but when the connection handle goes out of scope DBI sees that and explicitly issues a rollback. I'm not too sure the above is totally consistent now I've done this experiment. > >> "INSERT" >> "UPDATE" > > Clearly, I'll need more articles explaining database handling in more detail. > The thing is, I don't want to overwhelm the readers by giving them > all the examples and explanations at once. It was the insert into a table with 4 columns but only 3 parameters that I thought would confuse. Why not have 3 columns and 3 parameters. > >> "This is by far the most interesting part of the database access. As the >> SELECT statement can return a lot of rows and a lot of values in each row we >> cannot use a simple call to the do method. " >> >> Some DBDs really dislike using the do method for select stmts and especially >> multiple stmts in the same SQL e.g., do(q/something; select something from >> something/); > > I have not encountered that, but then I don't think I ever used do for > SELECT and > I think I use multiple SQL statements in one dbi call very rarely, if at all. > > Surely an article about this could be interesting. I wonder who would > want to write it? > (hint hint :) I already have written a number of articles: Perl DBI/DBD::ODBC Tutorial Part 1 - Drivers, Data Sources and Connection: http://www.easysoft.com/developer/languages/perl/dbd_odbc_tutorial_part_1.html Perl DBI/DBD::ODBC Tutorial Part 2 - Introduction to retrieving data from your database: http://www.easysoft.com/developer/languages/perl/dbd_odbc_tutorial_part_2.html Perl DBI/DBD::ODBC Tutorial Part 3 - Connecting Perl on UNIX or Linux to Microsoft SQL Server: http://www.easysoft.com/developer/languages/perl/sql_server_unix_tutorial.html Perl DBI - Put Your Data On The Web: http://www.easysoft.com/developer/languages/perl/tutorial_data_web.html Debugging Perl DBI: http://www.easysoft.com/developer/languages/perl/dbi-debugging.html Plus a few others on my personal web site. Martin http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36620.html Fri, 24 May 2013 09:38:01 +0000 Re: DBI article in Korean by Gabor Szabo Hi, On Wed, May 22, 2013 at 10:08 PM, Martin J. Evans <bohica@ntlworld.com> wrote: > Another good tutorial - please keep up the good work of promoting Perl. Thanks. I hope others will also help promoting my articles and interviews. > "The DSN (Data Source Name) (in the $dsn variable) is very straight forward. > It contains the type of the database. That will be the clue to DBI which DBD > to load. In case of SQLite, the only thing we really need is the path to the > database file." > > It may be a language thing but it is hardly a "clue". DBI clearly states the > connection string is dbi:DRIVER_NAME:something_else and DRIVER_NAMEs are > registered with DBI. Its also not always as "straight forward" as you > suggest as the something_else is usually a ';' separated string of > attributes and values e.g. "DRIVER={this driver}". I know it can be more complex than my example, but I don't have to frighten away the reader :) I am confused with your comment about the word "clue". Isn't the name of DBD::* derived from the DRIVER_NAME ? Or does clue mean something else then guiding information? Or do you mean that DRIVER_NAME is exact and a "clue" is only a direction? > "The call to disconnect from the database is optional as it will > automatically be called when the variable $dbh goes out of scope, but it > having it might be a clear indication for the next programmer dealing with > this code, that you are done with the database. " > > There are a number of gotchas with this. You may still have a select > statement active where you've not fetched all the rows yet from the cursor > in which case you'll get a warning. Also, you may be in the middle of a > transaction and in that case the transaction may be rolled back. Are these gotchas different in case $dbh goes out of scope and when I call $dbh->disconnect ? > "INSERT" > "UPDATE" Clearly, I'll need more articles explaining database handling in more detail. The thing is, I don't want to overwhelm the readers by giving them all the examples and explanations at once. > "This is by far the most interesting part of the database access. As the > SELECT statement can return a lot of rows and a lot of values in each row we > cannot use a simple call to the do method. " > > Some DBDs really dislike using the do method for select stmts and especially > multiple stmts in the same SQL e.g., do(q/something; select something from > something/); I have not encountered that, but then I don't think I ever used do for SELECT and I think I use multiple SQL statements in one dbi call very rarely, if at all. Surely an article about this could be interesting. I wonder who would want to write it? (hint hint :) regards Gabor http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36619.html Fri, 24 May 2013 05:51:47 +0000 RE: DBD installtion 11G R2 (64Bit) & 32 bit perl version by 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.kumar@nawras.om To: dbi-users@perl.org CC: goran@bildbasen.kiruna.se; jliptak@coefmd3.uswc.uswest.com; z50816@mip.lasc.lockheed.com; verbrug@be.oracle.com; mouche@hometown.com; stephen.zander@mckesson.com; earle.nietzel@es.unisys.com; descarte@hermetica.com; carlson@tis.llnl.gov; dbox@fndapl.fnal.gov; aslookin@alfabank.ru; timb@cpan.org; byterock@cpan.org; yanick@cpan.org; mjevans@cpan.org Subject: RE: DBD installtion 11G R2 (64Bit) & 32 bit perl version Date: Thu, 23 May 2013 14:03:09 +0000 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: <bit-time-kludge> 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: /usr/bin/ld Sysliblist: /lib/crt0_64.o -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat Oracle makefiles would have used these definitions but we override them: CC: $(ORACLE_HOME)/bin/oraxlc $(ORAXLCFLAGS) CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -O3 $(CDEBUG) -q64 -DSS_64BIT_SERVER -qwarn64 -qinfo=uni -DAIXRIOS -qflag=s:s -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -DLDAP_CM $(LPFLAGS) $(PLSQLNCGFLAGS) $(USRFLAGS)] LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) [-o $@ -L/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ -L$(LIBHOME)] Linking with /lib/crt0_64.o -lclntsh -brtl -lld -lm -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat -lm -lpthreads [from $(OCISHAREDLIBS)] WARNING: You will may need to rebuild perl using the xlc_r compiler. The important thing is that perl and DBD::Oracle be built with the same compiler. You may also need to: ORACCENV='cc=xlc_r'; export ORACCENV Also see README.aix for gcc instructions and read about the -p option. Unrecognized argument in LIBS ignored: '-brtl' LD_RUN_PATH=/u01/app/oracle/product/11.2.0/dbhome_1/lib:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib Using DBD::Oracle 1.62. Using DBD::Oracle 1.62. 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/ 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?) bash-3.2# make cp lib/DBD/Oracle/Troubleshooting/Cygwin.pod blib/lib/DBD/Oracle/Troubleshooting/Cygwin.pod cp lib/DBD/Oracle.pm blib/lib/DBD/Oracle.pm cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h cp lib/DBD/Oracle/Troubleshooting/Vms.pod blib/lib/DBD/Oracle/Troubleshooting/Vms.pod cp lib/DBD/Oracle/Troubleshooting/Hpux.pod blib/lib/DBD/Oracle/Troubleshooting/Hpux.pod cp lib/DBD/Oracle/Troubleshooting/Linux.pod blib/lib/DBD/Oracle/Troubleshooting/Linux.pod cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm cp lib/DBD/Oracle/Troubleshooting.pod blib/lib/DBD/Oracle/Troubleshooting.pod cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h cp lib/DBD/Oracle/Troubleshooting/Sun.pod blib/lib/DBD/Oracle/Troubleshooting/Sun.pod cp lib/DBD/Oracle/Troubleshooting/Macos.pod blib/lib/DBD/Oracle/Troubleshooting/Macos.pod cp lib/DBD/Oracle/Object.pm blib/lib/DBD/Oracle/Object.pm cp lib/DBD/Oracle/Troubleshooting/Aix.pod blib/lib/DBD/Oracle/Troubleshooting/Aix.pod cp lib/DBD/Oracle/Troubleshooting/Win64.pod blib/lib/DBD/Oracle/Troubleshooting/Win64.pod cp lib/DBD/Oracle/Troubleshooting/Win32.pod blib/lib/DBD/Oracle/Troubleshooting/Win32.pod cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm /usr/bin/perl -e 'use ExtUtils::Mksymlists; Mksymlists("NAME" => "DBD::Oracle", "DL_FUNCS" => { }, "FUNCLIST" => [], "DL_VARS" => []);' /usr/bin/perl -p -e "s/~DRIVER~/Oracle/g" /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst > Oracle.xsi /usr/bin/perl /usr/opt/perl5/lib/5.10.1/ExtUtils/xsubpp -typemap /usr/opt/perl5/lib/5.10.1/ExtUtils/typemap -typemap typemap Oracle.xs > Oracle.xsc && mv Oracle.xsc Oracle.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 Oracle.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 oci8.c Running Mkbootstrap for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.so 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. bash-3.2# echo $ LD_RUN_PATH $ LD_RUN_PATH bash-3.2# echo $LD_RUN_PATH bash-3.2# This e-mail including any attachment is intended only for the recipient(s) named. It may contain confidential information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please contact the sender and delete the e-mail from your system. The sender does not accept any liability for errors or omissions in the content of this message or for viruses, or any damage due to the e-mail. The recipient is advised to have appropriate virus check software http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36618.html Thu, 23 May 2013 17:32:55 +0000 Re: DBD installtion 11G R2 (64Bit) & 32 bit perl version by Jonathan Leffler You will need a 64-bit Perl (and 64-bit DBI) to work with 64-bit Oracle and hence 64-bit DBD::Oracle. Or you can go 32-bit for everything if there's a 32-bit Oracle client you can install. What you can't do is have some 32-bit code and some 64-bit code built into (or loaded into, since most of this is dynamically loaded) the same executable. All 32-bit or all 64-bit; not a mixture. (Addressee list trimmed.) On Thu, May 23, 2013 at 7:03 AM, Anoop Kumar Paramesweran < anoop.kumar@nawras.om> wrote: > 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: <bit-time-kludge> > > 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: /usr/bin/ld > > Sysliblist: /lib/crt0_64.o -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld > -lperfstat > > Oracle makefiles would have used these definitions but we override them: > > CC: $(ORACLE_HOME)/bin/oraxlc $(ORAXLCFLAGS) > > CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ > > $(SHARED_CFLAG) $(USRFLAGS) > > [$(GFLAG) -O3 $(CDEBUG) -q64 -DSS_64BIT_SERVER -qwarn64 > -qinfo=uni -DAIXRIOS -qflag=s:s > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -DLDAP_CM > $(LPFLAGS) $(PLSQLNCGFLAGS) $(USRFLAGS)] > > LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) > > [-o $@ -L/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ > -L$(LIBHOME)] > > Linking with /lib/crt0_64.o -lclntsh -brtl -lld -lm -ldl -lc -lm > -lpthreads -lodm -lbsd_r -lld -lperfstat -lm -lpthreads [from > $(OCISHAREDLIBS)] > > > > > > WARNING: You will may need to rebuild perl using the xlc_r compiler. > > The important thing is that perl and DBD::Oracle be built with > the same compiler. > > You may also need to: ORACCENV='cc=xlc_r'; export ORACCENV > > Also see README.aix for gcc instructions and read about the -p > option. > > Unrecognized argument in LIBS ignored: '-brtl' > > > LD_RUN_PATH=/u01/app/oracle/product/11.2.0/dbhome_1/lib:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib > > Using DBD::Oracle 1.62. > > Using DBD::Oracle 1.62. > > 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/ > > 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?) > > > > bash-3.2# make > > cp lib/DBD/Oracle/Troubleshooting/Cygwin.pod > blib/lib/DBD/Oracle/Troubleshooting/Cygwin.pod > > cp lib/DBD/Oracle.pm blib/lib/DBD/Oracle.pm > > cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h > > cp lib/DBD/Oracle/Troubleshooting/Vms.pod > blib/lib/DBD/Oracle/Troubleshooting/Vms.pod > > cp lib/DBD/Oracle/Troubleshooting/Hpux.pod > blib/lib/DBD/Oracle/Troubleshooting/Hpux.pod > > cp lib/DBD/Oracle/Troubleshooting/Linux.pod > blib/lib/DBD/Oracle/Troubleshooting/Linux.pod > > cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm > > cp lib/DBD/Oracle/Troubleshooting.pod > blib/lib/DBD/Oracle/Troubleshooting.pod > > cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h > > cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h > > cp lib/DBD/Oracle/Troubleshooting/Sun.pod > blib/lib/DBD/Oracle/Troubleshooting/Sun.pod > > cp lib/DBD/Oracle/Troubleshooting/Macos.pod > blib/lib/DBD/Oracle/Troubleshooting/Macos.pod > > cp lib/DBD/Oracle/Object.pm blib/lib/DBD/Oracle/Object.pm > > cp lib/DBD/Oracle/Troubleshooting/Aix.pod > blib/lib/DBD/Oracle/Troubleshooting/Aix.pod > > cp lib/DBD/Oracle/Troubleshooting/Win64.pod > blib/lib/DBD/Oracle/Troubleshooting/Win64.pod > > cp lib/DBD/Oracle/Troubleshooting/Win32.pod > blib/lib/DBD/Oracle/Troubleshooting/Win32.pod > > cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm > > /usr/bin/perl -e 'use ExtUtils::Mksymlists; Mksymlists("NAME" => > "DBD::Oracle", "DL_FUNCS" => { }, "FUNCLIST" => [], "DL_VARS" => []);' > > /usr/bin/perl -p -e "s/~DRIVER~/Oracle/g" > /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst > > Oracle.xsi > > /usr/bin/perl /usr/opt/perl5/lib/5.10.1/ExtUtils/xsubpp -typemap > /usr/opt/perl5/lib/5.10.1/ExtUtils/typemap -typemap typemap Oracle.xs > > Oracle.xsc && mv Oracle.xsc Oracle.c > > xlc_r -q32 -c > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public > -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI > -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 -O > -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" > "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT > -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 Oracle.c > > xlc_r -q32 -c > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public > -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI > -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 -O > -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" > "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT > -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c > > xlc_r -q32 -c > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo > -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public > -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public > -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI > -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 -O > -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" > "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT > -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 oci8.c > > Running Mkbootstrap for DBD::Oracle () > > chmod 644 Oracle.bs > > rm -f blib/arch/auto/DBD/Oracle/Oracle.so > > 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. > > bash-3.2# echo $ LD_RUN_PATH > > $ LD_RUN_PATH > > bash-3.2# echo $LD_RUN_PATH > > > > bash-3.2# > > > > > > > This e-mail including any attachment is intended only for the > recipient(s) named. It may contain confidential information and should not > be read, copied or otherwise used by any other person. If you are not a > named recipient, please contact the sender and delete the e-mail from your > system. The sender does not accept any liability for errors or omissions in > the content of this message or for viruses, or any damage due to the > e-mail. The recipient is advised to have appropriate virus check software > -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36617.html Thu, 23 May 2013 15:04:37 +0000 RE: DBD installtion 11G R2 (64Bit) & 32 bit perl version by Anoop Kumar Paramesweran 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: <bit-time-kludge> 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: /usr/bin/ld Sysliblist: /lib/crt0_64.o -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat Oracle makefiles would have used these definitions but we override them: CC: $(ORACLE_HOME)/bin/oraxlc $(ORAXLCFLAGS) CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -O3 $(CDEBUG) -q64 -DSS_64BIT_SERVER -qwarn64 -qinfo=uni -DAIXRIOS -qflag=s:s -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -DLDAP_CM $(LPFLAGS) $(PLSQLNCGFLAGS) $(USRFLAGS)] LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) [-o $@ -L/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ -L$(LIBHOME)] Linking with /lib/crt0_64.o -lclntsh -brtl -lld -lm -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat -lm -lpthreads [from $(OCISHAREDLIBS)] WARNING: You will may need to rebuild perl using the xlc_r compiler. The important thing is that perl and DBD::Oracle be built with the same compiler. You may also need to: ORACCENV='cc=xlc_r'; export ORACCENV Also see README.aix for gcc instructions and read about the -p option. Unrecognized argument in LIBS ignored: '-brtl' LD_RUN_PATH=/u01/app/oracle/product/11.2.0/dbhome_1/lib:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib Using DBD::Oracle 1.62. Using DBD::Oracle 1.62. 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/ 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?) bash-3.2# make cp lib/DBD/Oracle/Troubleshooting/Cygwin.pod blib/lib/DBD/Oracle/Troubleshooting/Cygwin.pod cp lib/DBD/Oracle.pm blib/lib/DBD/Oracle.pm cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h cp lib/DBD/Oracle/Troubleshooting/Vms.pod blib/lib/DBD/Oracle/Troubleshooting/Vms.pod cp lib/DBD/Oracle/Troubleshooting/Hpux.pod blib/lib/DBD/Oracle/Troubleshooting/Hpux.pod cp lib/DBD/Oracle/Troubleshooting/Linux.pod blib/lib/DBD/Oracle/Troubleshooting/Linux.pod cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm cp lib/DBD/Oracle/Troubleshooting.pod blib/lib/DBD/Oracle/Troubleshooting.pod cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h cp lib/DBD/Oracle/Troubleshooting/Sun.pod blib/lib/DBD/Oracle/Troubleshooting/Sun.pod cp lib/DBD/Oracle/Troubleshooting/Macos.pod blib/lib/DBD/Oracle/Troubleshooting/Macos.pod cp lib/DBD/Oracle/Object.pm blib/lib/DBD/Oracle/Object.pm cp lib/DBD/Oracle/Troubleshooting/Aix.pod blib/lib/DBD/Oracle/Troubleshooting/Aix.pod cp lib/DBD/Oracle/Troubleshooting/Win64.pod blib/lib/DBD/Oracle/Troubleshooting/Win64.pod cp lib/DBD/Oracle/Troubleshooting/Win32.pod blib/lib/DBD/Oracle/Troubleshooting/Win32.pod cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm /usr/bin/perl -e 'use ExtUtils::Mksymlists; Mksymlists("NAME" => "DBD::Oracle", "DL_FUNCS" => { }, "FUNCLIST" => [], "DL_VARS" => []);' /usr/bin/perl -p -e "s/~DRIVER~/Oracle/g" /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst > Oracle.xsi /usr/bin/perl /usr/opt/perl5/lib/5.10.1/ExtUtils/xsubpp -typemap /usr/opt/perl5/lib/5.10.1/ExtUtils/typemap -typemap typemap Oracle.xs > Oracle.xsc && mv Oracle.xsc Oracle.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 Oracle.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 oci8.c Running Mkbootstrap for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.so 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. bash-3.2# echo $ LD_RUN_PATH $ LD_RUN_PATH bash-3.2# echo $LD_RUN_PATH bash-3.2# This e-mail including any attachment is intended only for the recipient(s) named. It may contain confidential information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please contact the sender and delete the e-mail from your system. The sender does not accept any liability for errors or omissions in the content of this message or for viruses, or any damage due to the e-mail. The recipient is advised to have appropriate virus check software http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36616.html Thu, 23 May 2013 14:06:36 +0000 RE: DBD error by Anoop Kumar Paramesweran GIF89a¡-¶lx¶ÌêíºÂßÊëe»R2´éqËÆîîeËªÒpÂ^¯¥ÔáhSÁºB¼´l¸ãËI¦ÚÈÏå´×0ÐÈÚRËìï®^Ä×X§0ÚëÎÖÛìôõÊÒPX¥Zm²¾ÕD7 ØXd¬\y»u½¸Ò8ºããµØY¹Kãçò ÒíÅ1JµºÛ©Ò{ªÛ¢ÅfÉä·ñóùÚÙâðøÌÙdËxÎÔè¹Èå-¥ÉÜ§¬Òz>V¤ßçu¨×µÜñ|f|¸F«×ðòøûÃÆàÊ{xÃÕÒËÄÌNaªÀÒê-jµáñéÞæwÐÍPªd½²ÅZ\¯ÞÁKu¸£Î½øüý·Ýl¼2»ß®ÓÊüýõ}¿å ÎE°¢Êlô÷ÞÎy¼\ÓÂÝ¢¦Ãâòøò'`ÆÀ©ààÎrÎÅêîöÉÀ"¤ßJÁHXÃâôF%Ü]Ñ#>ÿÿÿ!ÿNETSCAPE2.0!ù,¡ÿÿH° Á*\È°¡Ã5¸<H±¢Å3\ñ¤Æ CÉEÇ'Gª\É%Ç';è´I³æD;vx´É³'O:9wØé³¨Q0°y1á¨Ó§WÝñ"Å¨X³&ä"TT´«ãÅ+&(x1¶-T:U;È %Û»E¹T Wvñ ®¹#ÅÐ:& id°c|¤ÐAYñ,akIG ðÂDÓÍ¨/rI¡IèÑ/ º¶CÖLE®!íß wDÈ Ûñ-&+G8°bÒ)"´ %@åØvÐvt,X¦ÿ`}ywGeåë@?zô-[ÈO"¾üZ¨çCøéG{×ùWÛ|ÃU-ä@$´)ø&4ø íH !j®ÂZ`¡#äèØ&hQq-¾# àáXZä#@R¨á(INø#NXèD Pâå IàLfBuÙ9òÁWfIB)©YÆ) ÅTÈ$sPBþÁFq>±©Züébf éÑ(,©MG´c¥obAá fªiÿt¨,@@£Òt §þ!¦sj¦+G¶Úk®,ízjªî±Z¨°dqÕ@\aëÚ1Æ Ì®D¯Jç"«R[BqQ+yÄkä.H+Ð¡¹ªJ{&µ ÜÁî@7ØjD¼y1ï÷ï¾-´÷£éA,ÛÆËí,\ÁBÃ é¿®fpqÆ 1sÛ(,K2F8±EÄ!YñË0Ä°ðq£F:±îlQÏ[¨¼Å@Mtßà JkÈKmQ NXhÖZc@O4c0M+W@`«Fÿ]Q>ãgBeNk1Ñû×z7}7DîmQûÝPH8mc,p¬F\1ÆØNG.Á#·åÕ ¤æ1vþv; ÁÜm+¨£¾GcT.ëÕ@!¯rn¸Ë»Ì@5à<s²¶>zôÑÇWH@|ñÇ¿õò/gðùG° îÔÛzÅì¡}h qE:oP@X<Åäó\à3îM3ï²§½úáh8þÂ?:ý/£ÝÆxG7oyðiósà/p4ax$È`Áð_{Û2p¡¢û ·®Ð@4a$¼ÀöÿÊÂ¤ÀZÖÌg-xð ½èu=0X$Ãé*Â#IäËBºð(V`SLãý|Ä,þP}Ub$Z#Ñ×&p/ôã±èF5¨u#ãê8'<-PPÐìåívWÈ¤ ÄÁØYØ±BËddBÉ&@1°ì^8IBOR° @J<àËZP¬ôñ±|_;ùÃ[âÒvÐSØ_¢ÒpÂ$æâ (Ît³ä¤-ÕËgBÓ{æ;à_â±PYp´iC/xó#@8IÿÎrÓ@'¨U!P¬'Á~4êú°Ìqö3ç4Fí0üMÐ~ÈR« 4ôöìÝD+ÊÏþS£0µPB¢òL.()¸ØÒ3ö~´h9÷ðRÂtüC¾à/Ô¤5`Ð=X¢AméPjT\àRC*Ï¢å¡Tµª³úIg5£]ÕèWÃÚ.<M_Èk^MÊ@´Ð'[ éR®vU¦};nÀX8ötÍòª¬@Pð¹Ï¶®qÝ@Sá@Aâ Z  (ãÎ&0'ÿ$ Jðä> [NBÓ¨è´ªÞ<¾ÔÚ` 6Xk«ÚÕÊdO¼ðÉÎ:3{¥ö&ìòV\äBâ`` ÈU.k]ëÚãÚ f£|/àYÂ¢a»MhÐ/(!#BÝòÖ(ÀLxCÞÀ)ØàÁ^'< Û«aÒ¯5;ÌPBèÂIJ;Ç!U¨Bàó¢w 01g<ã¼ÉIâv:°uòÊ báÈ,6¯+Ìä&/½^òà7\ø^mà¶LxùË^vÆlä#?ÅU~×¬f%»Ù¦ÍjvÀæLg ÷ x.Éê°åðt´ åæBÍkF3ÀèF3úy%m¹(lÙ f@bÀN;ÚÑô§ÝéR3>õ¨}9Gö^(pþ¬éMÛúÖ¸Î5§wÍiSûú×¾>3ôL2l k@ü\k];ûÙÐÎµ¦Kí8àØr4Ø¶À(,Ó¾æu´Ç=îÀÁÿßÓvfP4p  up3j`Û»Óâ&wÀ8= À°ÛÝP¶éU;úÔ¯÷½K1[j88´=|*ØþoøùÌr´ÊCíðU3ex5Éz`»(@f`ð¾QÜ°bD¿ÁÐH?óÊç<ô9¤°'h@d0p¨ç<ÏA6$èe zÞLv£#ZÎ<¨YÇHÁgÁ `õ«¼àiÐv8 6  e0rãÂ7¹ÉC&òÅç¨7mØ@Ýëó|ëØ;A0¨ÈgÿèGb"Ïaí:pÈÓ}òWÏz>¼gð%HL|âÞ!¶I5p`À7×9ì+_ðÐ> [/@ÀÀ÷àS¤¤ 3ÛãÊ<ógïü$ai( f`5PÿÝÖO²/<^ÆNøÃ_÷»¿üÎç~3Pf`r 0@°4pÁ'èv«÷ÆV·Ëwwè|2ð2!$°Ðk|ØwÚ'8ÐXE`¨Ès#H4@`  |q.Èz1Hr4(9÷zØ|Èÿ%^Tb"p.(u1( EMü'~:çq×|(ìb|A`|^èvA°zb¸efx8¸|8Ç3ðhëV}Áç }w(uw3h'ègj8³íñ'Ø.oAE~Èø°gu:G{W§ñ(õy(bxV`=p0`6PZ·3ÐñGb è_¦8ÁÈ«XûGw§m#×¸Èzäø4 ÀÃÈÜ¸i`u2 sÁ'RP¡xÿÛIë0`B¨6¨~E(Aü(Ú'u 0° ¸k{¹0æèÅéäè!©g0P|R#É-%é3Ù5 ×é>Y|)RDy;Iýè ÀCùPÉx@i8àXbP Ø3©}0aùb u`¹¶Ñú(Ð ð&ÒQÍñ&-&rI@à~àI&BI 1y.áÉ%a-p ÿ)G´é¦I aÉ°)A¯é±)-p&a}ÃÉo|ÙÐª9!gbQ¡ÌyYÜé9ß»éÁ?! 1éµ9ÖyYÛÙáù¡y éÚÔN@Cú9æYóé-  !¡@¡JÁ9ÙÉ)Ðñ¹àùú êiÞÉª¢Ê¢Ê !£~@£íé¢@/zX¡% ¢äÙ¢!*¤ ¤JE(:5vI¤C*ÿ<j0Ú+ zE*,j¡TÚ¡¡9º¥¹ _ê&¤\j¦P¢nÚ£r:hj¤t »é£N±' ]ú§q¦gêÈ¹£uÚ¦Qj¨U:§b¤ÉZ:¤ê¥ò©±¦~w:¢ojjl ê¾á§!Uz£:Z©ªé*¥*¬ªª|«ýIOêSª¥~Ð0©Gj©ª[¢ xº?É¡P©:¢|JZ«q«!5Í©ºÝÚ0³*lÚêûò&Ùz©uh¢Ù ³º+ÔªOñÿ¥ ú©Úÿ¬®zù° »°¢°N(ßY½êìD §ú2@0®Ðº±¯ïz±xù®Ð®(û®±¿i P¨-ê&¹¬Q±²ªI²aÐª'5 @5±búi zJ$+0°àiù´©ýÚKë$6é P®áKZ±¯g²¤ÒJJ2iA[>{69®á°±µÀ);G¤°m{°@0±Dé²|Ë±±ñª¹;¹[¹DI[ëçñ2»²A'ûoKÿ[1Q¿IºÜ¹¢_¤>»Ïàº1¿ º[KÚ8Û¦;WDª¤Ñ¤~0«£êÛÁ«D°òê¹}R+¼c1Ï«Ó¡©êª-@´±z88jDÿºçQ°*ÆzDä hb«Âkê*±ñ¼m!L*µ±´q«ä9¬Ê+fK¨î¡k©ì9ÿÚ¾$ ¼¡}Û½YÕ £%!C¼Á¼vk®=[À¼ ¡i2üY»4ìÂÍ*q[·9ªK¼¡¢ Á ìª2û§Ù´«¢ÀQ¢Âi¦QÂ¡Ä±¦õ*Á§Å #|ÅL¦/¼¥16 ½-*Å¡úK¨xÌ¢QË¾R[[·iÆ/zÏ+¤úò´«g[¬ºÇ Âib,§êÈa¶ÓAÁäË§E\²wk Ázì:së¦·Z¨fßZ \b¶*³wÌÂb;ªzLGw×ì\²6¨Êµ+®ÚüËY¨íº,Âk\²)LÁç©ÌÑiò¼YË¨Â«³±äZÑ,ÁÌÃ§áÅY°2[Ììi¶A+¨©NÐü¨ò9OÜÚ3NÚéÜÁ:ÇN8±JµÝ,ÃS¬ ñËÑJµk õ ;ÆMÈêÙæ¬«1A¤íÍíI¿-P[kÅ¬ó,mºÉI®û£(ü¤·;«,ýÃ¹¼¼ð&²[hÁ¤Cý&Vk¹>; http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36615.html Thu, 23 May 2013 14:04:54 +0000 DBD error by Anoop Kumar Paramesweran 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: /usr/bin/ld Sysliblist: /lib/crt0_64.o -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat Oracle makefiles would have used these definitions but we override them: CC: $(ORACLE_HOME)/bin/oraxlc $(ORAXLCFLAGS) CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -O3 $(CDEBUG) -q64 -DSS_64BIT_SERVER -qwarn64 -qinfo=uni -DAIXRIOS -qflag=s:s -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -DLDAP_CM $(LPFLAGS) $(PLSQLNCGFLAGS) $(USRFLAGS)] LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) [-o $@ -L/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ -L$(LIBHOME)] Linking with /lib/crt0_64.o -lclntsh -brtl -lld -lm -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat -lm -lpthreads [from $(OCISHAREDLIBS)] WARNING: You will may need to rebuild perl using the xlc_r compiler. The important thing is that perl and DBD::Oracle be built with the same compiler. You may also need to: ORACCENV='cc=xlc_r'; export ORACCENV Also see README.aix for gcc instructions and read about the -p option. Unrecognized argument in LIBS ignored: '-brtl' LD_RUN_PATH=/u01/app/oracle/product/11.2.0/dbhome_1/lib:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib Using DBD::Oracle 1.62. Using DBD::Oracle 1.62. 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/ 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?) bash-3.2# make cp lib/DBD/Oracle/Troubleshooting/Cygwin.pod blib/lib/DBD/Oracle/Troubleshooting/Cygwin.pod cp lib/DBD/Oracle.pm blib/lib/DBD/Oracle.pm cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h cp lib/DBD/Oracle/Troubleshooting/Vms.pod blib/lib/DBD/Oracle/Troubleshooting/Vms.pod cp lib/DBD/Oracle/Troubleshooting/Hpux.pod blib/lib/DBD/Oracle/Troubleshooting/Hpux.pod cp lib/DBD/Oracle/Troubleshooting/Linux.pod blib/lib/DBD/Oracle/Troubleshooting/Linux.pod cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm cp lib/DBD/Oracle/Troubleshooting.pod blib/lib/DBD/Oracle/Troubleshooting.pod cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h cp lib/DBD/Oracle/Troubleshooting/Sun.pod blib/lib/DBD/Oracle/Troubleshooting/Sun.pod cp lib/DBD/Oracle/Troubleshooting/Macos.pod blib/lib/DBD/Oracle/Troubleshooting/Macos.pod cp lib/DBD/Oracle/Object.pm blib/lib/DBD/Oracle/Object.pm cp lib/DBD/Oracle/Troubleshooting/Aix.pod blib/lib/DBD/Oracle/Troubleshooting/Aix.pod cp lib/DBD/Oracle/Troubleshooting/Win64.pod blib/lib/DBD/Oracle/Troubleshooting/Win64.pod cp lib/DBD/Oracle/Troubleshooting/Win32.pod blib/lib/DBD/Oracle/Troubleshooting/Win32.pod cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm /usr/bin/perl -e 'use ExtUtils::Mksymlists; Mksymlists("NAME" => "DBD::Oracle", "DL_FUNCS" => { }, "FUNCLIST" => [], "DL_VARS" => []);' /usr/bin/perl -p -e "s/~DRIVER~/Oracle/g" /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst > Oracle.xsi /usr/bin/perl /usr/opt/perl5/lib/5.10.1/ExtUtils/xsubpp -typemap /usr/opt/perl5/lib/5.10.1/ExtUtils/typemap -typemap typemap Oracle.xs > Oracle.xsc && mv Oracle.xsc Oracle.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 Oracle.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 dbdimp.c xlc_r -q32 -c -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -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 -O -DVERSION=\"1.62\" -DXS_VERSION=\"1.62\" "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" -DUTF8_SUPPORT -DORA_OCI_VERSION=\"11.2.0.3\" -DORA_OCI_102 -DORA_OCI_112 oci8.c Running Mkbootstrap for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.so 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. bash-3.2# echo $ LD_RUN_PATH $ LD_RUN_PATH bash-3.2# echo $LD_RUN_PATH bash-3.2# This e-mail including any attachment is intended only for the recipient(s) named. It may contain confidential information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please contact the sender and delete the e-mail from your system. The sender does not accept any liability for errors or omissions in the content of this message or for viruses, or any damage due to the e-mail. The recipient is advised to have appropriate virus check software http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36614.html Thu, 23 May 2013 12:27:34 +0000 Re: DBI article in Korean by Martin J. Evans On 22/05/2013 06:55, Gabor Szabo wrote: > Hi, > > recently I published an introduction to DBI article on the Perl Maven site: > http://perlmaven.com/simple-database-access-using-perl-dbi-and-sql > > the really interesting thing is that articles are constantly being > translated to 13 languages. > The Korean version has already arrived: > http://ko.perlmaven.com/simple-database-access-using-perl-dbi-and-sql > > regards > Gabor > Gabor, Another good tutorial - please keep up the good work of promoting Perl. I have a few comments I hope you'll take constructively. Please ignore some of these if you think it is beyond the scope of your tutorial - it is difficult for me to tell the audience you are targeting. "Those drivers are compiled together with the C client libraries of the respective database engines." although this is mostly true there are pure perl DBDs. "The DSN (Data Source Name) (in the $dsn variable) is very straight forward. It contains the type of the database. That will be the clue to DBI which DBD to load. In case of SQLite, the only thing we really need is the path to the database file." It may be a language thing but it is hardly a "clue". DBI clearly states the connection string is dbi:DRIVER_NAME:something_else and DRIVER_NAMEs are registered with DBI. Its also not always as "straight forward" as you suggest as the something_else is usually a ';' separated string of attributes and values e.g. "DRIVER={this driver}". "The call to disconnect from the database is optional as it will automatically be called when the variable $dbh goes out of scope, but it having it might be a clear indication for the next programmer dealing with this code, that you are done with the database. " There are a number of gotchas with this. You may still have a select statement active where you've not fetched all the rows yet from the cursor in which case you'll get a warning. Also, you may be in the middle of a transaction and in that case the transaction may be rolled back. "INSERT" You've presented an insert with an 4 columns and then inserted 3 - I know you know why but that might confuse people i.e., it is an auto incrementing column with a default value. SQLite is a bit different from other database in this respect as most would require you to define the id column as auto incrementing or having a default value. "UPDATE" Your example with the do method if fine but often people want to insert or update multiple rows and I think it is worth showing you can prepare a stmt and execute it many times with different parameters. As you do with the select example. "This is by far the most interesting part of the database access. As the SELECT statement can return a lot of rows and a lot of values in each row we cannot use a simple call to the do method. " Some DBDs really dislike using the do method for select stmts and especially multiple stmts in the same SQL e.g., do(q/something; select something from something/); Martin -- Martin J. Evans Wetherby, UK http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36613.html Wed, 22 May 2013 19:08:19 +0000 ANNOUNCE: Informix Database Driver for Perl DBI Version 2013.0521(2013-05-21) released by Jonathan Leffler Informix Database Driver for Perl DBI Version 2013.0521 (2013-05-21) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.6.1 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.10.0 - or any later version - you should be planning to upgrade to Perl 5.16.2 or later). You will need the code for DBI version 1.38 or later as well (v1.623 - or any later version - is recommended). The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at dbd.informix@gmail.com. ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2013.0521 * Support CSDK 4.10 for IDS 12.10 * Change work email address to jleffler@google.com New in release 2013.0206: * Bug fix release (not generally available). * Properly handle the new ESQL/C version 4.10. New in release 2013.0113: * Bug fix release. * Workaround for bug in ESQL/C 3.70 and earlier that generates error -1820 when reopening a cursor that previously fetched LVARCHAR data. * Fix for INFORMIXDIR containing Perl regex metacharacters. * Other minor improvements as documented in the ChangeLog. * Formal support for ESQL/C 7.x and 8.x (don't ask why the current version numbers are smaller) will be dropped after this release. The code won't go away yet, but it is beyond time to get off those versions. ESQL/C 5.20 is nominally supported for those still using Informix OnLine 5.20, but there is no testing on that platform. New in release 2011.0612: * Minor bug fix release. * Main change is related to Perl internals and avoids the need for PERL_POLLUTE. This change is not visible to users except that Perl 5.14.x can use the fixed code. * Fixed problem with string that is not null terminated by ESQL/C library. * Clean up some 64-bit compilation warnings. * Build on AIX. * Evade problem with a DISTINCT type of LVARCHAR with NOT NULL (probably ESQL/C bug). * Fewer versions of Informix products are supported. You may try building DBD::Informix with other versions. If it works, great; if not, please upgrade to a supported Informix version. Support email address: * This release is supported by Jonathan Leffler <dbd.informix@gmail.com>. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to bug-DBD-Informix@rt.cpan.org; they also get sent to dbd.informix@gmail.com, etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler (jleffler@google.com, jonathan.leffler@gmail.com) @(#)$Id: Announce,v 2013.6 2013/05/22 05:41:29 jleffler Exp $ -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36612.html Wed, 22 May 2013 06:27:54 +0000 DBI article in Korean by Gabor Szabo Hi, recently I published an introduction to DBI article on the Perl Maven site: http://perlmaven.com/simple-database-access-using-perl-dbi-and-sql the really interesting thing is that articles are constantly being translated to 13 languages. The Korean version has already arrived: http://ko.perlmaven.com/simple-database-access-using-perl-dbi-and-sql regards Gabor http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36611.html Wed, 22 May 2013 05:55:40 +0000 ANNOUNCE DBI-1.627 by Tim Bunce file: $CPAN/authors/id/T/TI/TIMB/DBI-1.627.tar.gz size: 585833 bytes md5: aab49be51b0f4867a1894145b023d2c5 The primary DBI repository is now on github under the ownership of the "perl5-dbi" team: https://github.com/perl5-dbi/dbi https://github.com/perl5-dbi?tab=members =head2 Changes in DBI 1.627 - 16th May 2013 Fixed VERSION regression in DBI::SQL::Nano [Tim Bunce] =head2 Changes in DBI 1.626 - 15th May 2013 Fixed pod text/link was reversed in a few cases RT#85168 [H.Merijn Brand] Handle aliasing of STORE'd attributes in DBI::DBD::SqlEngine [Jens Rehsack] Updated repository URI to git [Jens Rehsack] Fixed skip() count arg in t/48dbi_dbd_sqlengine.t [Tim Bunce] =head2 Changes in DBI 1.625 (svn r15595) 28th March 2013 Fixed heap-use-after-free during global destruction RT#75614 thanks to Reini Urban. Fixed ignoring RootClass attribute during connect() by DBI::DBD::SqlEngine reported in RT#84260 by Michael Schout =head2 Changes in DBI 1.624 (svn r15576) 22nd March 2013 Fixed Gofer for hash randomization in perl 5.17.10+ RT#84146 Clarify docs for can() re RT#83207 =cut Enjoy! Tim. http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36610.html Fri, 17 May 2013 07:35:56 +0000 RE: (Fwd) Perl DBI question by Vancura, Mark D Bruce, Thanks very much, I do see it in the several comments, and it appears to work as well! Thanks to Tim and then particularly Bruce for showing me the way, I do appreciate it! So in a nutshell: When a mysql command executed in a perl DBI do or execute method: load data local infile 'TEMP_LOAD_DATA_7318' into table ports ; Gives the error message: DBD::mysql::db do failed: The used command is not allowed with this MySQL version It is because of the special treatment of load data, explained in 6.1.6. Security Issues with LOAD DATA LOCAL *If you use LOAD DATA LOCAL in Perl scripts or other programs that read the [client] group from option files, you can add the local-infile=1 option to that group. However, to keep this from causing problems for programs that do not understand local-infile, specify it using the loose- prefix: [client] loose-local-infile=1 *If LOAD DATA LOCAL is disabled, either in the server or the client, a client that attempts to issue such a statement receives the following error message: ERROR 1148: The used command is not allowed with this MySQL version And the "option files" can be the dsn setup line in my perl program: my $dsn = "DBI:mysql:database=test;host=myhost;mysql_local_infile=1;" And then the load data local infile command will work without this error, and load the data! I hope this helps. Mark Vancura LSI Corporation -----Original Message----- From: Bruce Johnson [mailto:johnson@pharmacy.arizona.edu] Sent: Thursday, May 09, 2013 12:10 PM Cc: dbi-users@perl.org (dbi-users@perl.org) Subject: Re: (Fwd) Perl DBI question On May 9, 2013, at 10:47 AM, "Vancura, Mark D (Mark)" <Mark.Vancura@lsi.com> wrote: > Bruce, > Thanks, the explanation makes sense, so I need to figure out how to > follow through on this documented suggestion from: 6.1.6. Security > Issues with LOAD DATA LOCAL > > *If you use LOAD DATA LOCAL in Perl scripts or other programs that read the [client] group from option files, you can add the local-infile=1 option to that group. However, to keep this from causing problems for programs that do not understand local-infile, specify it using the loose- prefix: > [client] > loose-local-infile=1 > > *If LOAD DATA LOCAL is disabled, either in the server or the client, a client that attempts to issue such a statement receives the following error message: > ERROR 1148: The used command is not allowed with this MySQL version > > Thus this fits my situation exactly, I just have to learn where the > "option files" are and how to put the [client] loose-local-infile=1 into it. > > Any suggestions where to look this up? right there in theat section you looked at, down in the comments is "For use in perl DBI scripts, adding an option at the end of the data source definition for DBI->connect fixes the LOAD DATA LOCAL problem in some situations... use strict; use DBI; my $dsn = "DBI:mysql:mydb;mysql_local_infile=1"; my $user = "me"; my $password = "secret"; my $dbh = DBI->connect($dsn,$user,$password);" the $dsn creation statement is where you can put a ton of options; mysql-only ones would be documented in the DBD:mysql documentation, I'll bet. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36609.html Thu, 09 May 2013 19:39:45 +0000 Re: (Fwd) Perl DBI question by Bruce Johnson On May 9, 2013, at 10:47 AM, "Vancura, Mark D (Mark)" <Mark.Vancura@lsi.com> wrote: > Bruce, > Thanks, the explanation makes sense, so I need to figure out how to follow through > on this documented suggestion from: 6.1.6. Security Issues with LOAD DATA LOCAL > > *If you use LOAD DATA LOCAL in Perl scripts or other programs that read the [client] group from option files, you can add the local-infile=1 option to that group. However, to keep this from causing problems for programs that do not understand local-infile, specify it using the loose- prefix: > [client] > loose-local-infile=1 > > *If LOAD DATA LOCAL is disabled, either in the server or the client, a client that attempts to issue such a statement receives the following error message: > ERROR 1148: The used command is not allowed with this MySQL version > > Thus this fits my situation exactly, I just have to learn where the "option files" are > and how to put the [client] loose-local-infile=1 into it. > > Any suggestions where to look this up? right there in theat section you looked at, down in the comments is "For use in perl DBI scripts, adding an option at the end of the data source definition for DBI->connect fixes the LOAD DATA LOCAL problem in some situations... use strict; use DBI; my $dsn = "DBI:mysql:mydb;mysql_local_infile=1"; my $user = "me"; my $password = "secret"; my $dbh = DBI->connect($dsn,$user,$password);" the $dsn creation statement is where you can put a ton of options; mysql-only ones would be documented in the DBD:mysql documentation, I'll bet. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36608.html Thu, 09 May 2013 18:10:00 +0000 RE: (Fwd) Perl DBI question by Vancura, Mark D Bruce, Thanks, the explanation makes sense, so I need to figure out how to follow through on this documented suggestion from: 6.1.6. Security Issues with LOAD DATA LOCAL *If you use LOAD DATA LOCAL in Perl scripts or other programs that read the [client] group from option files, you can add the local-infile=1 option to that group. However, to keep this from causing problems for programs that do not understand local-infile, specify it using the loose- prefix: [client] loose-local-infile=1 *If LOAD DATA LOCAL is disabled, either in the server or the client, a client that attempts to issue such a statement receives the following error message: ERROR 1148: The used command is not allowed with this MySQL version Thus this fits my situation exactly, I just have to learn where the "option files" are and how to put the [client] loose-local-infile=1 into it. Any suggestions where to look this up? Thanks again for your help with this! Mark Vancura -----Original Message----- From: Bruce Johnson [mailto:johnson@pharmacy.arizona.edu] Sent: Thursday, May 09, 2013 11:26 AM To: dbi-users@perl.org (dbi-users@perl.org) Subject: Re: (Fwd) Perl DBI question On May 9, 2013, at 9:37 AM, Tim.Bunce@pobox.com wrote: > > However, then I want to put data into it, with a command like the following: > > > > load data local infile 'TEMP_LOAD_DATA_26021' into table ports ; > > > > And I get: > > DBD::mysql::db do failed: The used command is not allowed with this MySQL version at > read_excel_write_mysql.pl line 140. I find this in the MySQL docs: "If the statement fails, it is likely that your MySQL installation does not have local file capability enabled by default. See Section 6.1.6, "Security Issues with LOAD DATA LOCAL", for information on how to change this." <http://dev.mysql.com/doc/refman/5.0/en/loading-tables.html> -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36607.html Thu, 09 May 2013 17:48:06 +0000 Re: (Fwd) Perl DBI question by Bruce Johnson On May 9, 2013, at 9:37 AM, Tim.Bunce@pobox.com wrote: > > However, then I want to put data into it, with a command like the following: > > > > load data local infile 'TEMP_LOAD_DATA_26021' into table ports ; > > > > And I get: > > DBD::mysql::db do failed: The used command is not allowed with this MySQL version at > read_excel_write_mysql.pl line 140. I find this in the MySQL docs: "If the statement fails, it is likely that your MySQL installation does not have local file capability enabled by default. See Section 6.1.6, “Security Issues with LOAD DATA LOCAL”, for information on how to change this." <http://dev.mysql.com/doc/refman/5.0/en/loading-tables.html> -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36606.html Thu, 09 May 2013 17:26:35 +0000 (Fwd) Perl DBI question by Tim.Bunce@pobox.com ----- Forwarded message from "Vancura, Mark D (Mark)" <Mark.Vancura@lsi.com> ----- Date: Thu, 9 May 2013 11:05:37 -0400 From: "Vancura, Mark D (Mark)" <Mark.Vancura@lsi.com> To: "Tim.Bunce@pobox.com" <Tim.Bunce@pobox.com> Subject: Perl DBI question Tim, I am newly trying to make Perl and DBI work with mysql, with some success, e.g. I have been able to get connected, accessing a database, and create a table in it, with this command: MySQL_command = create table ports ( PortName varchar(40), direction enum('input','output','inout'), digital_analog enum('digital','analog'), port_pad enum('port','pad'), powerSupplies varchar(20) ) ; executed create table command However, then I want to put data into it, with a command like the following: load data local infile 'TEMP_LOAD_DATA_26021' into table ports ; And I get: DBD::mysql::db do failed: The used command is not allowed with this MySQL version at read_excel_write_mysql.pl line 140. DBD::mysql::db do failed: The used command is not allowed with this MySQL version at read_excel_write_mysql.pl line 140. Whether I "do" it or "prepare" and then "execute" it. If I run /usr/bin/mysql interactively, these commands are completely successful, so it hardly seems like a "MySQL version" issue. But I also have not been able to find that message in any of the DBI/DBD code, thus I suspect part of it is coming from MySQL. Is there some permission issue related to "Load data local infile" that I can/must manage. I am currently running as the "root" of mysql, and thus I expect I have, or can get any permission necessary. Thanks for any help you can provide. Mark Vancura LSI Corporation. ----- End forwarded message ----- http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36605.html Thu, 09 May 2013 16:38:03 +0000 Re: Huh? 4=3? by Tim Bunce On Wed, May 08, 2013 at 10:58:02AM -0700, felix@crowfix.com wrote: > On Wed, May 08, 2013 at 09:43:27AM -0700, Bill Ward wrote: > > Cool. That whole scalar vs list context thing is one of Perl's biggest > > strengths, but also one of its biggest weaknesses (in that it is a common > > source of bugs like this). When you see head-scratching problems, it's one > > of the first things to look for. > > Just guessing here, not familiar with the particular code in question. > But I have been bitten a few times by code which returns false in the > 'proper' manner > > return; > > instead of forcing a scalar return > > return undef; > > or list return > > return (); There is no difference between "return;" and "return ();". Both return an empty list when called in list context and an undef when called in scalar context. The "return ();" style does serve as a reminder to the reader. > Is that what's going on here -- the original code imparted a list > context, which triggered another perl gotcha, whereby missing list > values simply disappear: > > scalar(1,2,,4,,6) ---> 4, not 6 That returns 6, or rather, it returns whatever happens to be the last value. Tim. http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36604.html Thu, 09 May 2013 14:48:15 +0000 Re: Huh? 4=3? by Derek Jones Hi all, > > You are right -- but this produces 4 first, as I had always thought it > would, and then 6, as I don't quite understand. I would never use > that kind of expression, and I sorta maybe understand why it says 6, > but only in hindsight. > > #!/usr/bin/perl > > my @ary = (1,2,,4,,6); > print "Step 1: ", scalar(@ary), "\n"; > print "Step 2: ", scalar(1,2,,4,,6), "\n"; In the first example, scalar is operating on the array to give you its size. So you do indeed get 4, because only 4 elements are allocated. That is *indeed* an unusual and somewhat apparently counterintutive feature since very often in Perl, otherwise "undefined values" have storage autovifified when assigned under the hood and if interrogated with the defined operator will give you false. i.e. "the box is there but empty". If you want to tell if the element is there at all - you can use exists. E.g. print "Hi there element 4\n" if exists $ary[4]; print "Hi there element 5\n" if exists $ary[5]; which - in the case of @ary above would not print anything since only elements 0..3 exist. If you wanted 6 elements, as was noted earlier, you would have to preserve the indexing of the "missing" elements by using undef (see below). In the 2nd example, as we've noted, - you are simply getting the last value in a list - 6 in this case. So, the question is - why does Perl not keep the otherwise "undefined" elements in the list when they are being represented by ,, ? And the answer is unusual in that it's still seeing my @ary = (1,2,,4,,6); as a sequence on the right hand side - in which there are only 4 scalar items. So, to make it have 6, you'd say: my @ary = (1,2,undef,4,undef,6); That will autovivify all 6 elements, each of which will exist now according to exists, but only 4 of which will have defined values according to defined. Here's an updated version of your example: ------ #!/usr/bin/perl print "Original\n"; my @ary = (1,2,,4,,6); print "Step 1: ", scalar(@ary), "\n"; print "Step 2: ", scalar(1,2,,4,,6), "\n"; print "Hi there element 4\n" if exists $ary[4]; # Does not print print "Hi there element 5\n" if exists $ary[5]; # Does not print print "New\n"; my @ary2 = (1,2,undef,4,undef,6); print "Step 1: ", scalar(@ary2), "\n"; print "Step 2: ", scalar(1,2,undef,4,undef,6), "\n"; print "Hi there element 4\n" if exists $ary2[4]; #Now prints print "Hi there element 5\n" if exists $ary2[5] #Now prints ------ This is somewhat counterintuitive in that, if you had an array where you specified the size of a slice on the left, Perl would automatically allocate that number of elements and automatically assign undef to the ones not otherwise filled. But…. not in the way you expect. E.g. @ary3[0..5] = (1,2,,4,,6); Does *not* preserve the gaps - for the exact same reason as above. But, you do get elements 4 and 5 now - but it's *those* that are undef - and the actual list (1,2,4,6) gets assigned to elements 0..3 E.g. print "New2\n"; my @ary3; @ary3[0..5] = (1,2,,4,,6); print "Size: ", scalar(@ary3), "\n"; print "Hi there element 4\n" if exists $ary3[4]; #Prints print "Hi there element 5\n" if exists $ary3[5]; #Prints print "Hidef 4\n" if defined $ary3[4]; #Does not print print "Hidef 5\n" if defined $ary3[5]; #Does not print $"=":"; print "Elements\n"; print "-->@ary3<--\n"; # Notice the empty (undefined) two elements at the *end*… ;-) Kind regards Derek. http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36603.html Thu, 09 May 2013 03:50:39 +0000 Re: Huh? 4=3? by felix On Wed, May 08, 2013 at 06:22:09PM -0700, James Marshall wrote: > It shows 6 because a comma-separated literal list, when interpreted as a > scalar, evaluates to the final value in the list, not the length of the > list. If you evaluate "scalar(1,2,,4,,7)", it will equal 7. That's the > comma operator at work-- even though it looks like a list (and both use > commas), it's really just a sequential set of expressions. I think I've forgotten more useless perl trivia than I should have... I use the comma operator sometimes, but never inside scalar(). Didn't recognize it. TMTOWTMakeAMess. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36602.html Thu, 09 May 2013 02:54:30 +0000 Re: Huh? 4=3? by James Marshall It shows 6 because a comma-separated literal list, when interpreted as a scalar, evaluates to the final value in the list, not the length of the list. If you evaluate "scalar(1,2,,4,,7)", it will equal 7. That's the comma operator at work-- even though it looks like a list (and both use commas), it's really just a sequential set of expressions. Cheers, James On Wed, May 8, 2013 at 5:14 PM, <felix@crowfix.com> wrote: > On Wed, May 08, 2013 at 02:04:37PM -0400, Derek Jones wrote: > > Huh? > > > > That produces 6 - as it should. What version of Perl are you working > with? > > > On May 8, 2013, at 1:58 PM, felix@crowfix.com wrote: > > > > > scalar(1,2,,4,,6) > > You are right -- but this produces 4 first, as I had always thought it > would, and then 6, as I don't quite understand. I would never use > that kind of expression, and I sorta maybe understand why it says 6, > but only in hindsight. > > #!/usr/bin/perl > > my @ary = (1,2,,4,,6); > print "Step 1: ", scalar(@ary), "\n"; > print "Step 2: ", scalar(1,2,,4,,6), "\n"; > > -- > ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. > Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com > GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license > #4933 > I've found a solution to Fermat's Last Theorem but I see I've run out of > room o > http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36601.html Thu, 09 May 2013 01:22:28 +0000 Re: Huh? 4=3? by felix On Wed, May 08, 2013 at 02:04:37PM -0400, Derek Jones wrote: > Huh? > > That produces 6 - as it should. What version of Perl are you working with? > On May 8, 2013, at 1:58 PM, felix@crowfix.com wrote: > > > scalar(1,2,,4,,6) You are right -- but this produces 4 first, as I had always thought it would, and then 6, as I don't quite understand. I would never use that kind of expression, and I sorta maybe understand why it says 6, but only in hindsight. #!/usr/bin/perl my @ary = (1,2,,4,,6); print "Step 1: ", scalar(@ary), "\n"; print "Step 2: ", scalar(1,2,,4,,6), "\n"; -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36600.html Thu, 09 May 2013 00:15:14 +0000 Re: Huh? 4=3? by Chad Wallace On Wed, 8 May 2013 09:30:18 -0700 Bill Ward <bill@wards.net> wrote: > My guess is that get_value() is returning an empty array rather than > an undef scalar when the values are null. Try copying each one to a > scalar variable and including the list of variables in the execute(). > It'd be more readable that way anyway. Or if you must put them all > one one line like this, add the scalar() function on each argument. I use this idiom: ... get_value(...) || undef, ...get_value(...) || undef, ... If you don't want undef, you can use "|| ''" or "|| 0" instead. > On Wed, May 8, 2013 at 9:18 AM, Bruce Johnson > <johnson@pharmacy.arizona.edu>wrote: > > > Getting the error: > > > > DBD::Oracle::st execute failed: called with 3 bind variables when 4 > > are needed [for Statement "insert into employee_fte_annualrate_l > > (emplid, emptype_cd, fte, annual_rate) values(?,?,?,?)" with > > ParamValues: :p1='22057713', :p2='R', :p3='1', :p4='47311'] > > at /home/oraweb/perl/frs/ kfsupdate.pl line 64, <DATA> line 581. > > > > I'm pretty sure I count 4 placeholders and 4 parameter values in > > that error message, so where is the '3 bind variables' coming from? > > > > here's the cursor definition: > > > > my $csr_emp_info = $lda->prepare("insert into > > employee_fte_annualrate_l (emplid, emptype_cd, fte, annual_rate) > > values(?,?,?,?)"); > > > > I'm pulling the data from an LDAP query, here's the offending line > > 64 (where $mesg is the returned LDAP object): > > > > $csr_emp_info->execute($mesg->entry($n)->get_value('emplId'), > > $mesg->entry($n)->get_value('employeeType'),$mesg->entry($n)->get_value('employeeFTE'),$mesg->entry($n)->get_value('employeeTotalAnnualRate')); > > > > All the columns allow null entries, and these are all single-valued > > entries in the LDAP schema. > > > > > > -- > > Bruce Johnson > > University of Arizona > > College of Pharmacy > > Information Technology Group > > > > Institutions do not have opinions, merely customs > > > > > > > > -- C. Chad Wallace, B.Sc. The Lodging Company http://www.lodgingcompany.com/ OpenPGP Public Key ID: 0x262208A0 http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36599.html Wed, 08 May 2013 19:47:58 +0000 Re: Huh? 4=3? by Bruce Johnson On May 8, 2013, at 10:58 AM, felix@crowfix.com wrote: > > Is that what's going on here -- the original code imparted a list > context, which triggered another perl gotcha, whereby missing list > values simply disappear: > And I remember now the reason the error message is confusing, I'll bet that was an actual bug I discovered in (iirc) DBI or DBD::Oracle which was fixed, but not on this particular server, because we're still constrained to running a very old version for various reasons. The error message actually displays the values for the last successful insert not the one that failed. Mystery now solved. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36598.html Wed, 08 May 2013 18:21:29 +0000 Re: Huh? 4=3? by felix On Wed, May 08, 2013 at 09:43:27AM -0700, Bill Ward wrote: > Cool. That whole scalar vs list context thing is one of Perl's biggest > strengths, but also one of its biggest weaknesses (in that it is a common > source of bugs like this). When you see head-scratching problems, it's one > of the first things to look for. Just guessing here, not familiar with the particular code in question. But I have been bitten a few times by code which returns false in the 'proper' manner return; instead of forcing a scalar return return undef; or list return return (); Is that what's going on here -- the original code imparted a list context, which triggered another perl gotcha, whereby missing list values simply disappear: scalar(1,2,,4,,6) ---> 4, not 6 I understand and appreciate most of Perl's little tricks, but they sometimes catch me by surprise and elicit a few curses while debugging. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36597.html Wed, 08 May 2013 17:58:26 +0000 Re: Huh? 4=3? by Bill Ward Cool. That whole scalar vs list context thing is one of Perl's biggest strengths, but also one of its biggest weaknesses (in that it is a common source of bugs like this). When you see head-scratching problems, it's one of the first things to look for. On Wed, May 8, 2013 at 9:39 AM, Bruce Johnson <johnson@pharmacy.arizona.edu>wrote: > Well, changing the code to: > > my $eid=$mesg->entry($n)->get_value('emplId'); > my $etp=$mesg->entry($n)->get_value('employeeType'); > my $efte=$mesg->entry($n)->get_value('employeeFTE'); > my $ear=$mesg->entry($n)->get_value('employeeTotalAnnualRate'); > > $csr_emp_info->execute($eid,$etp,$efte,$ear); > > like you suggested fixed it. > > Thanks. > > On May 8, 2013, at 9:30 AM, Bill Ward <bill@wards.net> wrote: > > > My guess is that get_value() is returning an empty array rather than an > undef scalar when the values are null. Try copying each one to a scalar > variable and including the list of variables in the execute(). It'd be more > readable that way anyway. Or if you must put them all one one line like > this, add the scalar() function on each argument. > > > > > > On Wed, May 8, 2013 at 9:18 AM, Bruce Johnson < > johnson@pharmacy.arizona.edu> wrote: > > Getting the error: > > > > DBD::Oracle::st execute failed: called with 3 bind variables when 4 are > needed [for Statement "insert into employee_fte_annualrate_l (emplid, > emptype_cd, fte, annual_rate) values(?,?,?,?)" with ParamValues: > :p1='22057713', :p2='R', :p3='1', :p4='47311'] at /home/oraweb/perl/frs/ > kfsupdate.pl line 64, <DATA> line 581. > > > > I'm pretty sure I count 4 placeholders and 4 parameter values in that > error message, so where is the '3 bind variables' coming from? > > > > here's the cursor definition: > > > > my $csr_emp_info = $lda->prepare("insert into employee_fte_annualrate_l > (emplid, emptype_cd, fte, annual_rate) values(?,?,?,?)"); > > > > I'm pulling the data from an LDAP query, here's the offending line 64 > (where $mesg is the returned LDAP object): > > > > $csr_emp_info->execute($mesg->entry($n)->get_value('emplId'), > $mesg->entry($n)->get_value('employeeType'),$mesg->entry($n)->get_value('employeeFTE'),$mesg->entry($n)->get_value('employeeTotalAnnualRate')); > > > > All the columns allow null entries, and these are all single-valued > entries in the LDAP schema. > > > > > > -- > > Bruce Johnson > > University of Arizona > > College of Pharmacy > > Information Technology Group > > > > Institutions do not have opinions, merely customs > > > > > > > > > > > > -- > > Check out my LEGO blog at brickpile.com > > Follow/friend me: Facebook • Flickr • Twitter • LinkedIn > > -- > Bruce Johnson > University of Arizona > College of Pharmacy > Information Technology Group > > Institutions do not have opinions, merely customs > > > -- Check out my LEGO blog at brickpile.com <http://www.brickpile.com/> Follow/friend me: Facebook <http://facebook.com/billward> • Flickr<http://flickr.com/photos/billward/>• Twitter <http://twitter.com/williamward> • LinkedIn<http://www.linkedin.com/pub/william-ward/63/393/985/> http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36596.html Wed, 08 May 2013 16:44:19 +0000 Re: Huh? 4=3? by Bruce Johnson Well, changing the code to: my $eid=$mesg->entry($n)->get_value('emplId'); my $etp=$mesg->entry($n)->get_value('employeeType'); my $efte=$mesg->entry($n)->get_value('employeeFTE'); my $ear=$mesg->entry($n)->get_value('employeeTotalAnnualRate'); $csr_emp_info->execute($eid,$etp,$efte,$ear); like you suggested fixed it. Thanks. On May 8, 2013, at 9:30 AM, Bill Ward <bill@wards.net> wrote: > My guess is that get_value() is returning an empty array rather than an undef scalar when the values are null. Try copying each one to a scalar variable and including the list of variables in the execute(). It'd be more readable that way anyway. Or if you must put them all one one line like this, add the scalar() function on each argument. > > > On Wed, May 8, 2013 at 9:18 AM, Bruce Johnson <johnson@pharmacy.arizona.edu> wrote: > Getting the error: > > DBD::Oracle::st execute failed: called with 3 bind variables when 4 are needed [for Statement "insert into employee_fte_annualrate_l (emplid, emptype_cd, fte, annual_rate) values(?,?,?,?)" with ParamValues: :p1='22057713', :p2='R', :p3='1', :p4='47311'] at /home/oraweb/perl/frs/kfsupdate.pl line 64, <DATA> line 581. > > I'm pretty sure I count 4 placeholders and 4 parameter values in that error message, so where is the '3 bind variables' coming from? > > here's the cursor definition: > > my $csr_emp_info = $lda->prepare("insert into employee_fte_annualrate_l (emplid, emptype_cd, fte, annual_rate) values(?,?,?,?)"); > > I'm pulling the data from an LDAP query, here's the offending line 64 (where $mesg is the returned LDAP object): > > $csr_emp_info->execute($mesg->entry($n)->get_value('emplId'), $mesg->entry($n)->get_value('employeeType'),$mesg->entry($n)->get_value('employeeFTE'),$mesg->entry($n)->get_value('employeeTotalAnnualRate')); > > All the columns allow null entries, and these are all single-valued entries in the LDAP schema. > > > -- > Bruce Johnson > University of Arizona > College of Pharmacy > Information Technology Group > > Institutions do not have opinions, merely customs > > > > > > -- > Check out my LEGO blog at brickpile.com > Follow/friend me: Facebook • Flickr • Twitter • LinkedIn -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36595.html Wed, 08 May 2013 16:39:51 +0000 Re: Huh? 4=3? by Bill Ward My guess is that get_value() is returning an empty array rather than an undef scalar when the values are null. Try copying each one to a scalar variable and including the list of variables in the execute(). It'd be more readable that way anyway. Or if you must put them all one one line like this, add the scalar() function on each argument. On Wed, May 8, 2013 at 9:18 AM, Bruce Johnson <johnson@pharmacy.arizona.edu>wrote: > Getting the error: > > DBD::Oracle::st execute failed: called with 3 bind variables when 4 are > needed [for Statement "insert into employee_fte_annualrate_l (emplid, > emptype_cd, fte, annual_rate) values(?,?,?,?)" with ParamValues: > :p1='22057713', :p2='R', :p3='1', :p4='47311'] at /home/oraweb/perl/frs/ > kfsupdate.pl line 64, <DATA> line 581. > > I'm pretty sure I count 4 placeholders and 4 parameter values in that > error message, so where is the '3 bind variables' coming from? > > here's the cursor definition: > > my $csr_emp_info = $lda->prepare("insert into employee_fte_annualrate_l > (emplid, emptype_cd, fte, annual_rate) values(?,?,?,?)"); > > I'm pulling the data from an LDAP query, here's the offending line 64 > (where $mesg is the returned LDAP object): > > $csr_emp_info->execute($mesg->entry($n)->get_value('emplId'), > $mesg->entry($n)->get_value('employeeType'),$mesg->entry($n)->get_value('employeeFTE'),$mesg->entry($n)->get_value('employeeTotalAnnualRate')); > > All the columns allow null entries, and these are all single-valued > entries in the LDAP schema. > > > -- > Bruce Johnson > University of Arizona > College of Pharmacy > Information Technology Group > > Institutions do not have opinions, merely customs > > > -- Check out my LEGO blog at brickpile.com <http://www.brickpile.com/> Follow/friend me: Facebook <http://facebook.com/billward> • Flickr<http://flickr.com/photos/billward/>• Twitter <http://twitter.com/williamward> • LinkedIn<http://www.linkedin.com/pub/william-ward/63/393/985/> http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36594.html Wed, 08 May 2013 16:31:14 +0000 Huh? 4=3? by Bruce Johnson Getting the error: DBD::Oracle::st execute failed: called with 3 bind variables when 4 are needed [for Statement "insert into employee_fte_annualrate_l (emplid, emptype_cd, fte, annual_rate) values(?,?,?,?)" with ParamValues: :p1='22057713', :p2='R', :p3='1', :p4='47311'] at /home/oraweb/perl/frs/kfsupdate.pl line 64, <DATA> line 581. I'm pretty sure I count 4 placeholders and 4 parameter values in that error message, so where is the '3 bind variables' coming from? here's the cursor definition: my $csr_emp_info = $lda->prepare("insert into employee_fte_annualrate_l (emplid, emptype_cd, fte, annual_rate) values(?,?,?,?)"); I'm pulling the data from an LDAP query, here's the offending line 64 (where $mesg is the returned LDAP object): $csr_emp_info->execute($mesg->entry($n)->get_value('emplId'), $mesg->entry($n)->get_value('employeeType'),$mesg->entry($n)->get_value('employeeFTE'),$mesg->entry($n)->get_value('employeeTotalAnnualRate')); All the columns allow null entries, and these are all single-valued entries in the LDAP schema. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36593.html Wed, 08 May 2013 16:18:31 +0000 Re: Relevance of ChildHandles by Jens Rehsack On 08.05.13 00:05, Tim Bunce wrote: [...] > At this stage in the life of the DBI I think it's reasonable to assume > that there isn't a leak in the DBI itself. If there was then a lot of > people would be affected and complaining about it. I think this assumption is heavily wrong. From my jobs I learned one thing the last years: do it quick. To illustrate what I mean saying that, see following exampple. In a particular project we had the issue, that every monday morning our web-interface was inoperable because of an invalid $dbh (which was cached). The question from our manager was: can you say in 10 minutes why and how to fix and can you guarantee fix it until lunch? Otherwise - implement a cron controlled web-server restart each morning at 5. Because of personal interests I debugged later into it (and fixed it a few weeks later - "guaranteed") ... What I'm trying to say - when administrators see there web-server machines running out of memory, the implement a scheduled restart in the pool of machines. I really don't know business relying on web-services running qualified monitoring with performance measurement (some do, but don't know what they measure and finally one company really does). Sorry for complaining ;) Cheers -- Jens Rehsack http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36592.html Wed, 08 May 2013 11:58:46 +0000 RE: DBI Module installtion by Anoop Kumar Paramesweran Hi Support, DBI has been successfully installed after the instaltion of XLC trail version..Now I am facing issue with DBD-oracle.. I was trying to install DBD module but I receve the errors 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. Trying to find an ORACLE_HOME Your LIBPATH env var is set to '' The ORACLE_HOME environment variable is not set and I couldn't guess it. It must be set to hold the path to an Oracle installation directory on this machine (or a machine with a compatible architecture). See the appropriate README file for your OS for more information. ABORTED! ================================================ After this I set the path export ORACLE_BASE=/u01/app/oracle/product export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export SHLIB_PATH=$ORACLE_HOME/lib export LD_LIBRARY_PATH=$ORACLE_HOME/lib export PATH=$ORACLE_HOME/bin:/usr/bin:/etc:/usr/bin/x11:/usr/local/bin:/usr/vacpp/bin:$PATH export ORACLE_SID= Then I receive these errors ================================================================== 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 '' WARNING: Your LIBPATH env var doesn't include '/u01/app/oracle/product/11.2.0/dbhome_1/lib' but probably needs to. 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: /usr/bin/ld Sysliblist: /lib/crt0_64.o -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat Oracle makefiles would have used these definitions but we override them: CC: $(ORACLE_HOME)/bin/oraxlc $(ORAXLCFLAGS) CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -O3 $(CDEBUG) -q64 -DSS_64BIT_SERVER -qwarn64 -qinfo=uni -DAIXRIOS -qflag=s:s -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/demo -I/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/public -I/u01/app/oracle/product/11.2.0/dbhome_1/plsql/public -I/u01/app/oracle/product/11.2.0/dbhome_1/network/public -DLDAP_CM $(LPFLAGS) $(PLSQLNCGFLAGS) $(USRFLAGS)] LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) [-o $@ -L/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ -L$(LIBHOME)] Linking with /lib/crt0_64.o -lclntsh -brtl -lld -lm -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat -lm -lpthreads [from $(OCISHAREDLIBS)] WARNING: You will may need to rebuild perl using the xlc_r compiler. The important thing is that perl and DBD::Oracle be built with the same compiler. You may also need to: ORACCENV='cc=xlc_r'; export ORACCENV Also see README.aix for gcc instructions and read about the -p option. Checking if your kit is complete... Looks good Unrecognized argument in LIBS ignored: '-brtl' LD_RUN_PATH=/u01/app/oracle/product/11.2.0/dbhome_1/lib:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib Using DBD::Oracle 1.62. Using DBD::Oracle 1.62. 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/ 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?) bash-3.2# Thanks for the replay ,I think we don't have xlc.. but in software listing its showing ..but I cannot find the binaries for it. I have already gcc but it says most of the option are not available with gcc.. Anoop Kumar Paramesweran | Expert - Unix and Storage Systems e anoop.kumar@nawras.om | m +96895103659 twitter/nawras_oman | facebook/nawras -----Original Message----- From: Martin J. Evans [mailto:bohica@ntlworld.com] Sent: Wednesday, May 01, 2013 11:07 PM To: dbi-users@perl.org Cc: Anoop Kumar Paramesweran Subject: Re: DBI Module installtion On 29/04/2013 14:55, Anoop Kumar Paramesweran wrote: > Hi Support, > > I am receiving below error while installing (make ) DBI module in my > AIX box. As I am new to Perl installations could you please help me to > solve this.. > > xlc_r -q32 -c -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 > -O -DVERSION=\"1.625\" -DXS_VERSION=\"1.625\" > "-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE" Perl.c > /bin/sh: xlc_r: not found. > make: 1254-004 The error code from the last command is 127. > > > Stop. The Perl you are using was compiled with the AIX C compiler and it is either a) not installed or b) it is not on your path. You can either: a) add the AIX compiler xlc_r to your path if you have it installed (you usually have to pay IBM for this compiler) b) install the IBM compiler and add it to your PATH. c) install another compiler such as gcc (which is free), build Perl yourself into some dir you can point your PATH at and then install DBI. You might find perlbrew useful if you end up here. Mostly when people report the issue you have they have installed Perl from a package provided by IBM that they built with their compiler and you don't have this compiler. When Perl is built is records the compiler and options used and generally you cannot compile Perl itself with one compiler and then modules which require a C compiler with another compiler. Martin -- Martin J. Evans Wetherby, UK This e-mail including any attachment is intended only for the recipient(s) named. It may contain confidential information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please contact the sender and delete the e-mail from your system. The sender does not accept any liability for errors or omissions in the content of this message or for viruses, or any damage due to the e-mail. The recipient is advised to have appropriate virus check software http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36591.html Wed, 08 May 2013 11:50:54 +0000 Re: Relevance of ChildHandles by Alberto Simões Hello On Tue, May 7, 2013 at 11:05 PM, Tim Bunce <Tim.Bunce@pobox.com> wrote: > > > The DBI purges undef entries from ChildHandles from time to time. > (Specifically whenever the number of entries is a multiple of 120.) > Confirmed. Thanks > > At this stage in the life of the DBI I think it's reasonable to assume > that there isn't a leak in the DBI itself. If there was then a lot of > people would be affected and complaining about it. > > Yeah, that is my though too, but I'm trying to look to all possibilities. My server is crashing too often :-) Thanks -- Alberto Simões http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36590.html Wed, 08 May 2013 09:44:57 +0000 Re: Relevance of ChildHandles by Tim Bunce On Tue, May 07, 2013 at 10:28:29PM +0100, Alberto Simões wrote: > Hello > > Any kind of handle on DBI has a $h->{ChildHandles} that store weakrefs to all child handles created. For > instance, on a $dbh, you will get a list of weakrefs to $sth you create. > > When one of those $sth gets out of scope, its count get to 0. What Perl does to the weakref, is to > change it to an undef value (Perl isn't able to remove that element from the array). > > Although a single undef takes less memory than a complete $sth object, it takes memory space. And if we > get a lot of these undef values, things get worse. The DBI purges undef entries from ChildHandles from time to time. (Specifically whenever the number of entries is a multiple of 120.) At this stage in the life of the DBI I think it's reasonable to assume that there isn't a leak in the DBI itself. If there was then a lot of people would be affected and complaining about it. Tim. http://www.nntp.perl.org/group/perl.dbi.users/2013/05/msg36589.html Tue, 07 May 2013 22:06:12 +0000