perl.dbi.users http://www.nntp.perl.org/group/perl.dbi.users/ ... Copyright 1998-2014 perl.org Sun, 20 Apr 2014 00:59:14 +0000 ask@perl.org Re: DBI->connect performance issue by Greg Sabino Mullane <br/>-----BEGIN PGP SIGNED MESSAGE-----<br/>Hash: RIPEMD160<br/><br/><br/>&gt; We&#39;re finding that simply creating a connection maxes out one of the CPU&#39;s<br/>&gt; and consistently takes over 4s (but sometimes it manages to create the<br/>&gt; connection in about .2s).<br/>...<br/>&gt; If any body can offer up any sort of suggestion, I&#39;d be most grateful -<br/>&gt; we&#39;re truly stumped.<br/><br/>Nothing jumps out right away. You should probably dig deep and see where <br/>the pause is, by running it under strace.<br/><br/>- -- <br/>Greg Sabino Mullane greg@turnstep.com<br/>End Point Corporation http://www.endpoint.com/<br/>PGP Key: 0x14964AC8 201404141925<br/>http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8<br/>-----BEGIN PGP SIGNATURE-----<br/><br/>iEYEAREDAAYFAlNMmPoACgkQvJuQZxSWSsjxFACgv+LgzhH1On5LGQ44Pebns8Li<br/>cBkAoIxt8rPaBMrvnJIVwI4Pg/d1rQzf<br/>=uwKW<br/>-----END PGP SIGNATURE-----<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36947.html Tue, 15 Apr 2014 02:28:03 +0000 DBI->connect performance issue by Andrew Park Hi,<br/><br/>Hoping somebody on this mailing list can help me.<br/>We&#39;re running Perl 5.10.1 on AIX 7.1.<br/><br/>We&#39;re finding that simply creating a connection maxes out one of the CPU&#39;s<br/>and consistently takes over 4s (but sometimes it manages to create the<br/>connection in about .2s).<br/>On our old AIX 5.1 server running Perl 5.6, we were getting connections in<br/>a tiny fraction of a second.<br/><br/>We&#39;re using DBI 1.631 and DBD::DB2 1.85 connecting to DB2 10.5.<br/><br/><br/>To isolate the problem we created a little script:<br/><br/>#!/usr/bin/perl -w<br/><br/>use strict;<br/>use warnings;<br/>use Time::HiRes qw(time);<br/><br/>use DBI;<br/><br/>sub getDatabaseHandle {<br/>my $start = time();<br/><br/> my $dbh =<br/> DBI-&gt;connect_cached( &#39;dbi:DB2:myDatabase&#39;, &#39;userid&#39;, &#39;password&#39;,<br/>{PrintError =&gt; 0} )<br/> or die &quot;Couldn&#39;t connect to database: &quot; . DBI-&gt;errstr;<br/><br/>my $end = time();<br/>printf(&quot;%.2f\n&quot;, $end - $start);<br/><br/> return $dbh;<br/>}<br/><br/>getDatabaseHandle();<br/><br/>1;<br/><br/><br/>We&#39;ve tried various things (like switching from 32-bit to 64-bit, using<br/>ActivePerl instead of then vendor&#39;s Perl 5.10 implementation) and nothing<br/>seems to improve it.<br/><br/>If any body can offer up any sort of suggestion, I&#39;d be most grateful -<br/>we&#39;re truly stumped.<br/><br/>Thanks,<br/><br/>Andrew<br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36946.html Mon, 14 Apr 2014 22:32:50 +0000 Re: Database encoding not recognized by DBD::Pg by Vincent Veyron On Tue, 08 Apr 2014 08:40:45 +1000<br/>Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/><br/>Hi Ron,<br/><br/>&gt; <br/>&gt; AFAICT locales have no effect on my code.<br/>&gt; <br/>&gt; I do have a policy of creating databases with:<br/>&gt; <br/>&gt; create database $name owner $role encoding &#39;UTF8&#39;;<br/>&gt; <br/><br/>Yes, I agree, it does work, just not on this backup server :-(<br/><br/><br/>&gt; See also:<br/>&gt; <br/>&gt; http://savage.net.au/Perl/dbd.utf8.pl<br/>&gt; <br/><br/>Thank you for that (and running tests); I copied it to add<br/><br/>use Encode;<br/>print encode(&#39;UTF8&#39;, $content);<br/><br/>to my module, and then the faulty server displays accented characters properly.<br/><br/>The problem is that the other servers are now subject to double encoding (since they were correctly outputting UTF8 in the first place).<br/><br/>Strangely, all servers, good and bad, report &#39;UTF8 OFF, ASCII&#39; for DBI-&gt;data_string_desc(). I would have expected &#39;UTF8 on&#39;, since the db is UTF8 encoded.<br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://vincentveyron.com<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36945.html Thu, 10 Apr 2014 15:42:16 +0000 Re: Database encoding not recognized by DBD::Pg by Vincent Veyron On Tue, 08 Apr 2014 08:40:45 +1000<br/>Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/><br/>Hi Ron,<br/><br/>&gt; <br/>&gt; AFAICT locales have no effect on my code.<br/>&gt; <br/>&gt; I do have a policy of creating databases with:<br/>&gt; <br/>&gt; create database $name owner $role encoding &#39;UTF8&#39;;<br/>&gt; <br/><br/>Yes, I agree, it does work, just not on this backup server :-(<br/><br/><br/>&gt; See also:<br/>&gt; <br/>&gt; http://savage.net.au/Perl/dbd.utf8.pl<br/>&gt; <br/><br/>Thank you for that (and running tests); I copied it to add<br/><br/>use Encode;<br/>print encode(&#39;UTF8&#39;, $content);<br/><br/>to my module, and then the faulty server displays accented characters properly.<br/><br/>The problem is that the other servers are now subject to double encoding (since they were correctly outputting UTF8 in the first place).<br/><br/>Strangely, all servers, good and bad, report &#39;UTF8 OFF, ASCII&#39; for DBI-&gt;data_string_desc(). I would have expected &#39;UTF8 on&#39;, since the db is UTF8 encoded.<br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://vincentveyron.com<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36944.html Tue, 08 Apr 2014 13:24:43 +0000 Re: Database encoding not recognized by DBD::Pg by Marica On Mon, 07 Apr 2014 08:11:49 +1000<br/>Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/><br/>&gt; Hi Vincent<br/>&gt; <br/>&gt; I ran a few tests, using:<br/>&gt; <br/>&gt; cat /etc/default/locale<br/>&gt; # File generated by update-locale<br/>&gt; LANG=&quot;en_AU.UTF-8&quot;<br/>&gt; LANGUAGE=&quot;en_AU:en&quot;<br/>&gt; <br/>&gt; No problems showed up.<br/>&gt; <br/><br/>It only shows outside of ASCII (&#39;&eacute;&#39;, &#39;&ccedil;&#39; dont display correctly, as shown in the link in my original post). So if you used english characters, you can&#39;t see it.<br/><br/><br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr/<br/>Gestion des contentieux, des dossiers de sinistres assurance et des contrats pour le service juridique<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36943.html Tue, 08 Apr 2014 09:12:21 +0000 Re: Database encoding not recognized by DBD::Pg by Marica On Mon, 07 Apr 2014 08:11:49 +1000<br/>Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/><br/>Ron,<br/><br/>Sorry for the PM, with a wrong identity too. I reposted correctly on the list.<br/><br/><br/><br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr/<br/>Gestion des contentieux, des dossiers de sinistres assurance et des contrats pour le service juridique<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36942.html Tue, 08 Apr 2014 09:12:18 +0000 RE: FW: Perl module DBD::Oracle installation failing by Jillapelli, Ramakrishna Hi Kurt,<br/><br/>Good News, today we have received all the reports.<br/><br/>Thank you very much once again.<br/><br/>Thanks &amp; Regards, <br/><br/>Ramakrishna Jillapelli,<br/>Global Services, Operations and Engineering,<br/><br/>XEROX Business Services, <br/>9th Floor, Explorer Block, White Field Road, ITPL, <br/>Bangalore - 560066, India.<br/><br/>E-Mail: Ramakrishna.Jillapelli@xerox.com, <br/>Ph:&nbsp;+1-214-530-2222, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).<br/><br/><br/>-----Original Message-----<br/>From: Jillapelli, Ramakrishna <br/>Sent: Monday, April 07, 2014 9:35 PM<br/>To: &#39;Kurt Jaeger&#39;<br/>Cc: dbi-users@perl.org<br/>Subject: RE: FW: Perl module DBD::Oracle installation failing<br/><br/>Hi Kurt,<br/><br/>Thanks a lot, I was able to generate one report in the evening. Perl script is connecting to Oracle database.<br/>Some of URLs (links) also depending on Perl scripts which will indirectly connects to Databases fetches the data.<br/><br/>I think, Perl Oracle module installed successfully.<br/><br/>Still verifying lot of other scripts are working or not.<br/><br/>Once again thank you very much.<br/><br/>Thanks &amp; Regards, <br/><br/>Ramakrishna Jillapelli,<br/>Global Services, Operations and Engineering,<br/><br/>XEROX Business Services,<br/>9th Floor, Explorer Block, White Field Road, ITPL, Bangalore - 560066, India.<br/><br/>E-Mail: Ramakrishna.Jillapelli@xerox.com,<br/>Ph:&nbsp;+1-214-530-2222, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).<br/><br/><br/>-----Original Message-----<br/>From: Kurt Jaeger [mailto:pi@opsec.eu] <br/>Sent: Monday, April 07, 2014 8:25 PM<br/>To: Jillapelli, Ramakrishna<br/>Subject: Re: FW: Perl module DBD::Oracle installation failing<br/><br/>Hi!<br/><br/>Did it work out ?<br/><br/>Or do you still have problems ?<br/><br/>-- <br/>pi@opsec.eu +49 171 3101372 6 years to go !<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36941.html Tue, 08 Apr 2014 07:49:09 +0000 Re: Database encoding not recognized by DBD::Pg by Ron Savage Hi Vincent<br/><br/>On 07/04/14 22:03, Vincent Veyron wrote:<br/>&gt; On Mon, 07 Apr 2014 20:10:31 +1000<br/>&gt; Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/>&gt;<br/>&gt;&gt;<br/>&gt;&gt; Of course, but I tested Unicode characters which are not ASCII, OK?<br/>&gt;&gt;<br/>&gt;<br/>&gt; duh! sorry about that, I should have known better. It&#39;s been a long week...<br/>&gt;<br/>&gt; Note that the server with the fr_FR:fr encoding is the one that displays characters correctly, as in your tests. It&#39;s the one with only fr_FR@euro that doesn&#39;t (on a cluster that was initialized with LATIN9; mixed encodings work fine on a UTF-8 default cluster).<br/>&gt;<br/>&gt; I don&#39;t quite grasp locales related matters in Debian. I tried adding it manually in /etc/default/locale on the faulty server, running dpkg-reconfigure afterwards, but to no avail.<br/><br/>AFAICT locales have no effect on my code.<br/><br/>I do have a policy of creating databases with:<br/><br/>create database $name owner $role encoding &#39;UTF8&#39;;<br/><br/>See also:<br/><br/>http://savage.net.au/Perl/dbd.utf8.pl<br/><br/>-- <br/>Ron Savage<br/>savage.net.au<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36940.html Mon, 07 Apr 2014 22:40:58 +0000 Re: Database encoding not recognized by DBD::Pg by Ron Savage Hi Vincent<br/><br/>On 07/04/14 20:03, Vincent Veyron wrote:<br/>&gt; On Mon, 07 Apr 2014 08:11:49 +1000<br/>&gt; Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/>&gt;<br/>&gt;&gt;<br/>&gt;&gt; I ran a few tests, using:<br/>&gt;&gt;<br/>&gt;&gt; cat /etc/default/locale<br/>&gt;&gt; # File generated by update-locale<br/>&gt;&gt; LANG=&quot;en_AU.UTF-8&quot;<br/>&gt;&gt; LANGUAGE=&quot;en_AU:en&quot;<br/>&gt;&gt;<br/>&gt;<br/>&gt;<br/>&gt; It only shows outside of ASCII (&#39;&eacute;&#39;, &#39;&ccedil;&#39; dont display correctly, as shown in the link in my original post). So if you used english characters, you can&#39;t see it.<br/><br/>As I replied to Marica, the tests involve non-ASCII Unicode characters.<br/><br/>I listed the locales because others have done so.<br/><br/>-- <br/>Ron Savage<br/>savage.net.au<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36939.html Mon, 07 Apr 2014 22:37:28 +0000 Re: Database encoding not recognized by DBD::Pg by Vincent Veyron [Hi Martin, you forgot to cc the list, pasting your message below]<br/><br/>On Mon, 7 Apr 2014 11:38:59 -0400<br/>Martin Gainty &lt;mgainty@hotmail.com&gt; wrote:<br/><br/>&gt; <br/>&gt; did you try to set the environment variable<br/>&gt; <br/>&gt; LANG?<br/>&gt; <br/><br/>You made me discover another difference between the two servers: /etc/environment is empty on the faulty server, and contains <br/>LANG=fr_FR.UTF-8 <br/>on the working one.<br/><br/>I tried setting it manually, ran dpkg-reconfigure, rebooted, but no luck.<br/><br/>Interestingly, another machine serves correctly the mixed encodings without it (/etc/environment empty), but it&#39;s an old workstation that runs debian 6.0, whereas the production and backup servers both run debian 7.4<br/><br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr<br/>Gestion des contentieux juridiques, des contrats et des sinistres d&#39;assurance<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36938.html Mon, 07 Apr 2014 20:38:26 +0000 RE: FW: Perl module DBD::Oracle installation failing by Jillapelli, Ramakrishna Hi Kurt,<br/><br/>Thanks a lot, I was able to generate one report in the evening. Perl script is connecting to Oracle database.<br/>Some of URLs (links) also depending on Perl scripts which will indirectly connects to Databases fetches the data.<br/><br/>I think, Perl Oracle module installed successfully.<br/><br/>Still verifying lot of other scripts are working or not.<br/><br/>Once again thank you very much.<br/><br/>Thanks &amp; Regards, <br/><br/>Ramakrishna Jillapelli,<br/>Global Services, Operations and Engineering,<br/><br/>XEROX Business Services, <br/>9th Floor, Explorer Block, White Field Road, ITPL, <br/>Bangalore - 560066, India.<br/><br/>E-Mail: Ramakrishna.Jillapelli@xerox.com, <br/>Ph:&nbsp;+1-214-530-2222, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).<br/><br/><br/>-----Original Message-----<br/>From: Kurt Jaeger [mailto:pi@opsec.eu] <br/>Sent: Monday, April 07, 2014 8:25 PM<br/>To: Jillapelli, Ramakrishna<br/>Subject: Re: FW: Perl module DBD::Oracle installation failing<br/><br/>Hi!<br/><br/>Did it work out ?<br/><br/>Or do you still have problems ?<br/><br/>-- <br/>pi@opsec.eu +49 171 3101372 6 years to go !<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36937.html Mon, 07 Apr 2014 16:05:36 +0000 Re: Database encoding not recognized by DBD::Pg by Vincent Veyron On Mon, 07 Apr 2014 20:10:31 +1000<br/>Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/><br/>&gt; <br/>&gt; Of course, but I tested Unicode characters which are not ASCII, OK?<br/>&gt; <br/><br/>duh! sorry about that, I should have known better. It&#39;s been a long week...<br/><br/>Note that the server with the fr_FR:fr encoding is the one that displays characters correctly, as in your tests. It&#39;s the one with only fr_FR@euro that doesn&#39;t (on a cluster that was initialized with LATIN9; mixed encodings work fine on a UTF-8 default cluster).<br/><br/>I don&#39;t quite grasp locales related matters in Debian. I tried adding it manually in /etc/default/locale on the faulty server, running dpkg-reconfigure afterwards, but to no avail. <br/><br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr<br/>Gestion des contentieux juridiques, des contrats et des sinistres d&#39;assurance<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36936.html Mon, 07 Apr 2014 12:04:03 +0000 Re: Database encoding not recognized by DBD::Pg by Ron Savage Hi Marica<br/><br/>On 07/04/14 18:59, Marica wrote:<br/>&gt; On Mon, 07 Apr 2014 08:11:49 +1000<br/>&gt; Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/>&gt;<br/>&gt;&gt; Hi Vincent<br/>&gt;&gt;<br/>&gt;&gt; I ran a few tests, using:<br/>&gt;&gt;<br/>&gt;&gt; cat /etc/default/locale<br/>&gt;&gt; # File generated by update-locale<br/>&gt;&gt; LANG=&quot;en_AU.UTF-8&quot;<br/>&gt;&gt; LANGUAGE=&quot;en_AU:en&quot;<br/>&gt;&gt;<br/>&gt;&gt; No problems showed up.<br/>&gt;&gt;<br/>&gt;<br/>&gt; It only shows outside of ASCII (&#39;&eacute;&#39;, &#39;&ccedil;&#39; dont display correctly, as shown in the link in my original post). So if you used english characters, you can&#39;t see it.<br/><br/>Of course, but I tested Unicode characters which are not ASCII, OK?<br/><br/>-- <br/>Ron Savage<br/>savage.net.au<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36935.html Mon, 07 Apr 2014 10:10:47 +0000 Re: Database encoding not recognized by DBD::Pg by Vincent Veyron On Mon, 07 Apr 2014 08:11:49 +1000<br/>Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/><br/>&gt; <br/>&gt; I ran a few tests, using:<br/>&gt; <br/>&gt; cat /etc/default/locale<br/>&gt; # File generated by update-locale<br/>&gt; LANG=&quot;en_AU.UTF-8&quot;<br/>&gt; LANGUAGE=&quot;en_AU:en&quot;<br/>&gt; <br/><br/><br/>It only shows outside of ASCII (&#39;&eacute;&#39;, &#39;&ccedil;&#39; dont display correctly, as shown in the link in my original post). So if you used english characters, you can&#39;t see it.<br/><br/><br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr<br/>Gestion des contentieux juridiques, des contrats et des sinistres d&#39;assurance<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36934.html Mon, 07 Apr 2014 10:03:40 +0000 Re: Database encoding not recognized by DBD::Pg by Vincent Veyron On Mon, 7 Apr 2014 16:26:54 +1200<br/>Chris Bannister &lt;cbannister@slingshot.co.nz&gt; wrote:<br/><br/>&gt; <br/>&gt; # dpkg-reconfigure locales <br/><br/>I tried that<br/><br/>&gt; And choose the right one, pick a UTF one this time. :)<br/>&gt; <br/><br/>Those machines host other applications that use an ISO-8859 encoding, the idea was to convert them to UTF-8 one by one; but it looks like I will have to migrate the whole cluster at once. <br/><br/><br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr<br/>Gestion des contentieux juridiques, des contrats et des sinistres d&#39;assurance<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36933.html Mon, 07 Apr 2014 09:09:30 +0000 FW: Perl module DBD::Oracle installation failing by Jillapelli, Ramakrishna # /usr/bin/perl Makefile.PL <br/>Using DBI 1.631 (for perl 5.010001 on aix-thread-multi) installed in /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/ <br/> <br/>Configuring DBD::Oracle for perl 5.010001 on aix (aix-thread-multi) <br/> <br/>Remember to actually *READ* the README file! Especially if you have any problems. <br/> <br/>Installing on a aix, Ver#5.3 <br/>Using Oracle in /oracle/product/v102/fullclnt <br/>DEFINE _SQLPLUS_RELEASE = &quot;1002000100&quot; (CHAR) <br/>Oracle version 10.2.0.1 (10.2) <br/>Found /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk <br/>Found /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms.mk <br/>Found /oracle/product/v102/fullclnt/rdbms/lib/ins_rdbms.mk <br/>Using /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk <br/>Your LIBPATH env var is set to &#39;/usr/local/Tivoli/lib/aix4-r1:/usr/lib:/opt/netcool/platform/aix5/lib:/opt/netcool/omnibus/platform/aix5/lib&#39; <br/>WARNING: Your LIBPATH env var doesn&#39;t include &#39;/oracle/product/v102/fullclnt/lib32&#39; but probably needs to. <br/>Reading /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk <br/>Reading /oracle/product/v102/fullclnt/rdbms/lib/env_rdbms.mk <br/>Deleting -b64 from COMPOBJS because -b64 doesn&#39;t exist. <br/> <br/>Attempting to discover Oracle OCI build rules <br/> xlc_r -q32 -O -c DBD_ORA_OBJ.c <br/>by executing: [make -f /oracle/product/v102/fullclnt/rdbms/demo/demo_rdbms32.mk build ECHODO=echo ECHO=echo GENCLNTSH=&#39;echo genclntsh&#39; CC=true OPTIMIZE= CCFLD_ORA_EXE OBJS=DBD_ORA_OBJ.o] <br/>Oracle oci build command: <br/> [ true -q32 -L/oracle/product/v102/fullclnt/lib32/ -L/oracle/product/v102/fullclnt/rdbms//lib32/ -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh -lld -lcle/product/v102/fullclnt/lib32/sysliblist` -lm -lpthreads] <br/> <br/>Found header files in /oracle/product/v102/fullclnt/rdbms/public. <br/> <br/>client_version=10.2 <br/> <br/> <br/>DEFINE= -DUTF8_SUPPORT -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 <br/> <br/> <br/>Checking for functioning wait.ph <br/> <br/> <br/>System: perl5.010001 aix dennis01 3 5 00c72e9a4c00 <br/>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=extendedal/include -q32 -D_LARGE_FILES -qlonglong <br/>Linker: /usr/bin/ld <br/>Sysliblist: /lib/crt0_64.o -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat <br/>Oracle makefiles would have used these definitions but we override them: <br/> CC: $(ORACLE_HOME)/bin/oraxlc $(ORAXLCFLAGS) <br/> CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(PFLAGS)\ <br/> $(SHARED_CFLAG) $(USRFLAGS) <br/> [$(GFLAG) -O3 $(CDEBUG) -q64 -DSS_64BIT_SERVER -qwarn64 -qinfo=uni -DAIXRIOS -qtocmerge -bimport:/oracle/product/v102/fullclnt/lib/ksms.imp -I/ora/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/plsql/public -I/oracle/product/v102/fullclnt/network/pLAGS) $(LPFLAGS) $(USRFLAGS)] <br/> LDFLAGS: -o $@ $(LDPATHFLAG)$(PRODLIBHOME) $(LDPATHFLAG)$(LIBHOME) <br/> [-o $@ -L/oracle/product/v102/fullclnt/rdbms/lib/ -L$(LIBHOME)] <br/>Linking with OTHERLDFLAGS = -q32 -L/oracle/product/v102/fullclnt/lib32/ -L/oracle/product/v102/fullclnt/rdbms//lib32/ -lclntsh -lld -lm `cat /oracle/produlclnt/lib32/sysliblist` -lm -lpthreads [from &#39;build&#39; rule] <br/> <br/> <br/>WARNING: You will may need to rebuild perl using the xlc_r compiler. <br/> The important thing is that perl and DBD::Oracle be built with the same compiler. <br/> You may also need to: ORACCENV=&#39;cc=xlc_r&#39;; export ORACCENV <br/> Also see README.aix for gcc instructions and read about the -p option. <br/>Checking if your kit is complete... <br/>Looks good <br/>LD_RUN_PATH=/oracle/product/v102/fullclnt/lib32:/oracle/product/v102/fullclnt/rdbms/lib32 <br/>Using DBD::Oracle 1.70. <br/>Using DBD::Oracle 1.70. <br/>Using DBI 1.631 (for perl 5.010001 on aix-thread-multi) installed in /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/ <br/>Writing Makefile for DBD::Oracle <br/> <br/>*** If you have problems... <br/> read all the log printed above, and the README and README.help.txt files. <br/> (Of course, you have read README by now anyway, haven&#39;t you?) <br/> <br/> <br/>[root@ews-pgh1-esmd2] /home/rj46/DBD-Oracle-1.70 <br/># make <br/>cp lib/DBD/Oracle/Troubleshooting/Cygwin.pod blib/lib/DBD/Oracle/Troubleshooting/Cygwin.pod <br/>cp lib/DBD/Oracle.pm blib/lib/DBD/Oracle.pm <br/>cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h <br/>cp lib/DBD/Oracle/Troubleshooting/Vms.pod blib/lib/DBD/Oracle/Troubleshooting/Vms.pod <br/>cp lib/DBD/Oracle/Troubleshooting/Hpux.pod blib/lib/DBD/Oracle/Troubleshooting/Hpux.pod <br/>cp lib/DBD/Oracle/Troubleshooting/Linux.pod blib/lib/DBD/Oracle/Troubleshooting/Linux.pod <br/>cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm <br/>cp lib/DBD/Oracle/Troubleshooting.pod blib/lib/DBD/Oracle/Troubleshooting.pod <br/>cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h <br/>cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h <br/>cp lib/DBD/Oracle/Troubleshooting/Sun.pod blib/lib/DBD/Oracle/Troubleshooting/Sun.pod <br/>cp lib/DBD/Oracle/Troubleshooting/Macos.pod blib/lib/DBD/Oracle/Troubleshooting/Macos.pod <br/>cp lib/DBD/Oracle/Object.pm blib/lib/DBD/Oracle/Object.pm <br/>cp lib/DBD/Oracle/Troubleshooting/Aix.pod blib/lib/DBD/Oracle/Troubleshooting/Aix.pod <br/>cp lib/DBD/Oracle/Troubleshooting/Win64.pod blib/lib/DBD/Oracle/Troubleshooting/Win64.pod <br/>cp lib/DBD/Oracle/Troubleshooting/Win32.pod blib/lib/DBD/Oracle/Troubleshooting/Win32.pod <br/>cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm <br/> /usr/bin/perl -e &#39;use ExtUtils::Mksymlists; Mksymlists(&quot;NAME&quot; =&gt; &quot;DBD::Oracle&quot;, &quot;DL_FUNCS&quot; =&gt; { }, &quot;FUNCLIST&quot; =&gt; [], &quot;DL_VARS&quot; =&gt; []);&#39; <br/> /usr/bin/perl -p -e &quot;s/~DRIVER~/Oracle/g&quot; /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst &gt; Oracle.xsi <br/> /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 &gt; Oracle.xscle.xsc Oracle.c <br/> xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public -oduct/v102/fullclnt/plsql/public -I/oracle/product/v102/fullclnt/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -D_ALL_SOURC_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES -qlonglDVERSION=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 Or <br/> xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public -oduct/v102/fullclnt/plsql/public -I/oracle/product/v102/fullclnt/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -D_ALL_SOURC_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES -qlonglDVERSION=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 db <br/> xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public -oduct/v102/fullclnt/plsql/public -I/oracle/product/v102/fullclnt/network/public -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI -D_ALL_SOURC_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES -qlonglDVERSION=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 oc <br/>Running Mkbootstrap for DBD::Oracle () <br/> chmod 644 Oracle.bs <br/> rm -f blib/arch/auto/DBD/Oracle/Oracle.so <br/> LD_RUN_PATH=&quot;/oracle/product/v102/fullclnt/lib32:/oracle/product/v102/fullclnt/rdbms/lib32&quot; ld -bhalt:4 -G -bI:/usr/opt/perl5/lib/5.10.1/aix-thread-perl.exp -bE:Oracle.exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib Oracle.o dbdimp.o oci8.o -q32 -L/oracle/product/v102/fullclnt/lib32/ -L/oracle/producclnt/rdbms//lib32/ -lclntsh -lld -lm `cat /oracle/product/v102/fullclnt/lib32/sysliblist` -lm -lpthreads -o blib/arch/auto/DBD/Oracle/Oracle.so <br/>ld: 0706-012 The -q flag is not recognized. <br/>ld: 0706-012 The -3 flag is not recognized. <br/>ld: 0706-012 The -2 flag is not recognized. <br/>make: The error code from the last command is 255. <br/> <br/> <br/>Stop. <br/> <br/>[root@ews-pgh1-esmd2] /home/rj46/DBD-Oracle-1.70 <br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36932.html Mon, 07 Apr 2014 08:27:13 +0000 Re: Database encoding not recognized by DBD::Pg by Chris Bannister On Sun, Apr 06, 2014 at 07:59:32PM +0200, Vincent Veyron wrote:<br/>&gt; <br/>&gt; cat /etc/default/locale<br/>&gt; #Primary<br/>&gt; LANG=fr_FR@euro<br/>&gt; LANGUAGE=fr_FR:fr<br/>&gt; <br/>&gt; #Backup<br/>&gt; LANG=fr_FR@euro<br/><br/># dpkg-reconfigure locales <br/>And choose the right one, pick a UTF one this time. :)<br/><br/>-- <br/>&quot;If you&#39;re not careful, the newspapers will have you hating the people<br/>who are being oppressed, and loving the people who are doing the <br/>oppressing.&quot; --- Malcolm X<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36931.html Mon, 07 Apr 2014 04:27:03 +0000 Re: Database encoding not recognized by DBD::Pg by Ron Savage Hi Vincent<br/><br/>I ran a few tests, using:<br/><br/>cat /etc/default/locale<br/># File generated by update-locale<br/>LANG=&quot;en_AU.UTF-8&quot;<br/>LANGUAGE=&quot;en_AU:en&quot;<br/><br/>No problems showed up.<br/><br/>On 07/04/14 03:59, Vincent Veyron wrote:<br/>&gt; On Sun, 6 Apr 2014 16:01:54 -0000<br/>&gt; &quot;Greg Sabino Mullane&quot; &lt;greg@turnstep.com&gt; wrote:<br/>&gt;<br/>&gt;&gt;<br/>&gt;&gt; What are server_encoding and client_encoding set to on each database?<br/>&gt;&gt;<br/>&gt;<br/>&gt; Hi Greg,<br/>&gt;<br/>&gt; Same thing for both servers:<br/>&gt;<br/>&gt; ppro_utf8=&gt; show client_encoding;<br/>&gt; client_encoding<br/>&gt; -----------------<br/>&gt; LATIN9<br/>&gt; (1 ligne)<br/>&gt;<br/>&gt; ppro_utf8=&gt; show server_encoding;<br/>&gt; server_encoding<br/>&gt; -----------------<br/>&gt; UTF8<br/>&gt; (1 ligne)<br/>&gt;<br/>&gt;<br/>&gt; I suspect something to do with locales on Debian? The good server (primary) is an OVH hosted machine, which runs a debian version that they customize, while the bad one (backup) was built using stock debian net-install. I found a difference in the LANGUAGE environnement variable (with that strange fr_FR:fr), other than that all configuration files are identical on both machines.<br/>&gt;<br/>&gt; cat /etc/default/locale<br/>&gt; #Primary<br/>&gt; LANG=fr_FR@euro<br/>&gt; LANGUAGE=fr_FR:fr<br/>&gt;<br/>&gt; #Backup<br/>&gt; LANG=fr_FR@euro<br/>&gt;<br/><br/>-- <br/>Ron Savage<br/>savage.net.au<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36930.html Sun, 06 Apr 2014 22:12:10 +0000 Re: Database encoding not recognized by DBD::Pg by Vincent Veyron On Sun, 6 Apr 2014 16:01:54 -0000<br/>&quot;Greg Sabino Mullane&quot; &lt;greg@turnstep.com&gt; wrote:<br/><br/>&gt; <br/>&gt; What are server_encoding and client_encoding set to on each database?<br/>&gt; <br/><br/>Hi Greg,<br/><br/>Same thing for both servers:<br/><br/>ppro_utf8=&gt; show client_encoding;<br/> client_encoding <br/>-----------------<br/> LATIN9<br/>(1 ligne)<br/><br/>ppro_utf8=&gt; show server_encoding;<br/> server_encoding <br/>-----------------<br/> UTF8<br/>(1 ligne)<br/><br/><br/>I suspect something to do with locales on Debian? The good server (primary) is an OVH hosted machine, which runs a debian version that they customize, while the bad one (backup) was built using stock debian net-install. I found a difference in the LANGUAGE environnement variable (with that strange fr_FR:fr), other than that all configuration files are identical on both machines.<br/><br/>cat /etc/default/locale<br/>#Primary<br/>LANG=fr_FR@euro<br/>LANGUAGE=fr_FR:fr<br/><br/>#Backup<br/>LANG=fr_FR@euro<br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr/<br/>Gestion des contentieux, des dossiers de sinistres assurance et des contrats pour le service juridique<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36929.html Sun, 06 Apr 2014 17:59:50 +0000 Re: Database encoding not recognized by DBD::Pg by Greg Sabino Mullane <br/>-----BEGIN PGP SIGNED MESSAGE-----<br/>Hash: RIPEMD160<br/><br/><br/>&gt; Why does data_string_desc return &#39;UTF8 off&#39; all servers, <br/>&gt; when the database is UTF8 encoded?<br/><br/>What are server_encoding and client_encoding set to on each database?<br/><br/>- -- <br/>Greg Sabino Mullane greg@turnstep.com<br/>End Point Corporation http://www.endpoint.com/<br/>PGP Key: 0x14964AC8 201404061201<br/>http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8<br/><br/>-----BEGIN PGP SIGNATURE-----<br/><br/>iEYEAREDAAYFAlNBelcACgkQvJuQZxSWSshdcQCgv4Kh7QUbOenSsH8BVk2owfrL<br/>rKQAn2tuPKxWfc+Zz6Sca4Hg8aahbwgc<br/>=XECb<br/>-----END PGP SIGNATURE-----<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36928.html Sun, 06 Apr 2014 16:02:02 +0000 DBD::Pg 3.1.0 released (driver for Postgres) by Greg Sabino Mullane <br/>-----BEGIN PGP SIGNED MESSAGE-----<br/>Hash: RIPEMD160<br/><br/><br/>Version 3.1.0 of DBD::Pg, DBI driver for PostgreSQL, has <br/>been uploaded to CPAN.<br/><br/>Changes:<br/><br/>Version 3.1.0 Released April 4, 2014 (git commit 26517a3531f93de79375a02da45a79789cd3caae)<br/><br/> - Make sure UTF-8 enabled notifications are handled correctly<br/> [Greg Sabino Mullane]<br/><br/> - Allow &quot;WITH&quot; and &quot;VALUES&quot; as valid words starting a DML statement<br/> [Greg Sabino Mullane] (CPAN bug #92724)<br/><br/><br/>Checksums:<br/><br/>dc350b9eeb5316e2ae0f574a64ff333c DBD-Pg-3.1.0.tar.gz<br/>322b201281949afb55cbdfdf78e89618053f16f5 DBD-Pg-3.1.0.tar.gz<br/><br/>- -- <br/>Greg Sabino Mullane greg@turnstep.com<br/>End Point Corporation http://www.endpoint.com/<br/>PGP Key: 0x14964AC8 201404050758<br/>http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8<br/>-----BEGIN PGP SIGNATURE-----<br/><br/>iEYEAREDAAYFAlM/7/AACgkQvJuQZxSWSshA5gCgll06SlSIodlQx4tUX/gMJX4Y<br/>OmQAni2ZZbEjS6D7F/KRqhJtIENmpK+s<br/>=LjS5<br/>-----END PGP SIGNATURE-----<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36927.html Sat, 05 Apr 2014 12:00:15 +0000 Re: CPAN DBI make & make test error by John R Pierce On 4/3/2014 8:43 PM, Jonathan Leffler wrote:<br/>&gt; Maybe you don&#39;t have the xlc_r installed on your machine at all, or <br/>&gt; maybe it is not on your path when you are logged in as root.<br/><br/><br/>try putting /usr/vac/bin in your PATH ...<br/><br/>$ /usr/vac/bin/xlc_r -qversion<br/>IBM XL C/C++ for AIX, V11.1 (5724-X13)<br/>Version: 11.01.0000.0006<br/><br/><br/>Do note, IBM XLC and/or XLCPP are licensed on a named user basis. At my <br/>work, only two of us have licenses to use it.<br/><br/><br/><br/>-- <br/>john r pierce 37N 122W<br/>somewhere on the middle of the left coast<br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36926.html Fri, 04 Apr 2014 03:58:43 +0000 Re: CPAN DBI make & make test error by Jonathan Leffler On Thu, Apr 3, 2014 at 6:14 AM, Karthi Keyan01<br/>&lt;Karthi_Keyan01@infosys.com&gt;wrote:<br/><br/>&gt; I&#39;m trying to install the DBI module in the below mentioned steps as a<br/>&gt; root user.<br/>&gt;<br/>&gt;<br/>&gt;<br/>&gt; xlc_r -q32 -c -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE<br/>&gt; -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT<br/>&gt; -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong<br/>&gt; -O -DVERSION=\&quot;1.631\&quot; -DXS_VERSION=\&quot;1.631\&quot;<br/>&gt; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; Perl.c<br/>&gt;<br/>&gt; /bin/sh: xlc_r: not found.<br/>&gt;<br/>&gt; make: 1254-004 The error code from the last command is 127.<br/>&gt;<br/>&gt;<br/>&gt;<br/><br/>Maybe you don&#39;t have the xlc_r installed on your machine at all, or maybe<br/>it is not on your path when you are logged in as root.<br/><br/>Either way, the primary fix is to ensure that root has access to the xlc_r<br/>compiler.<br/><br/>The secondary problem is that you&#39;re compiling as root. Personally, I<br/>recommend doing the compilation and testing as a regular user. Only if<br/>you&#39;re sure you want to mess with the system installation of Perl do you do<br/>the install as &#39;root&#39;. Minimize the use of root privileges; it reduces the<br/>risks of doing damage if something goes wrong.<br/><br/><br/>-- <br/>Jonathan Leffler &lt;jonathan.leffler@gmail.com&gt; #include &lt;disclaimer.h&gt;<br/>Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org<br/>&quot;Blessed are we who can laugh at ourselves, for we shall never cease to be<br/>amused.&quot;<br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36925.html Fri, 04 Apr 2014 03:44:09 +0000 CPAN DBI make & make test error by Karthi Keyan01 Hi,<br/><br/>I&#39;m trying to install the DBI module in the below mentioned steps as a root user.<br/><br/><br/>1. export DB2_HOME=/opt/IBM/db2/V9.7<br/><br/>2. export DB2LIB=/opt/IBM/db2/V9.7/lib64<br/><br/>3. perl Makefile.PL<br/><br/>4. make<br/><br/>5. make test<br/><br/>6. make install<br/><br/><br/>The first 3 steps are completed successfully and the 4th step, make process is throwing the below error.<br/><br/> 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=\&quot;1.631\&quot; -DXS_VERSION=\&quot;1.631\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; Perl.c<br/>/bin/sh: xlc_r: not found.<br/>make: 1254-004 The error code from the last command is 127.<br/><br/><br/>I have posted the complete results that I performed. Kindly help.<br/><br/>--------------------------------------------------------------------------------------------------------------<br/><br/># export DB2_HOME=/opt/IBM/db2/V9.7 --- Step 1<br/><br/># export DB2LIB=/opt/IBM/db2/V9.7/lib64 --- Step 2<br/><br/># perl Makefile.PL --- Step 3 - Completed successfully<br/><br/><br/># make --- Step 4<br/><br/>Skip blib/arch/auto/DBI/Driver_xst.h (unchanged)<br/>Skip blib/lib/DBD/Proxy.pm (unchanged)<br/>Skip blib/lib/DBI/Gofer/Response.pm (unchanged)<br/>Skip blib/lib/DBI/Gofer/Transport/Base.pm (unchanged)<br/>Skip blib/lib/DBI/Util/_accessor.pm (unchanged)<br/>Skip blib/lib/DBD/DBM.pm (unchanged)<br/>Skip blib/arch/auto/DBI/DBIXS.h (unchanged)<br/>Skip blib/lib/dbixs_rev.pl (unchanged)<br/>Skip blib/lib/DBI/Const/GetInfoType.pm (unchanged)<br/>Skip blib/lib/DBI/Gofer/Serializer/DataDumper.pm (unchanged)<br/>Skip blib/lib/DBI/DBD/Metadata.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Transport/pipeone.pm (unchanged)<br/>Skip blib/lib/DBI/Const/GetInfo/ODBC.pm (unchanged)<br/>Skip blib/lib/DBI/ProfileDumper/Apache.pm (unchanged)<br/>Skip blib/lib/DBD/File/Roadmap.pod (unchanged)<br/>Skip blib/arch/auto/DBI/Driver.xst (unchanged)<br/>Skip blib/lib/DBD/File.pm (unchanged)<br/>Skip blib/lib/DBI/Util/CacheMemory.pm (unchanged)<br/>Skip blib/lib/DBD/NullP.pm (unchanged)<br/>Skip blib/lib/DBI/ProfileSubs.pm (unchanged)<br/>Skip blib/arch/auto/DBI/dbi_sql.h (unchanged)<br/>Skip blib/lib/DBD/File/HowTo.pod (unchanged)<br/>Skip blib/lib/DBD/Gofer.pm (unchanged)<br/>Skip blib/arch/auto/DBI/dbivport.h (unchanged)<br/>Skip blib/arch/auto/DBI/dbd_xsh.h (unchanged)<br/>Skip blib/lib/DBI/DBD/SqlEngine/HowTo.pod (unchanged)<br/>Skip blib/arch/auto/DBI/dbixs_rev.h (unchanged)<br/>Skip blib/lib/DBD/Gofer/Transport/Base.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Transport/corostream.pm (unchanged)<br/>Skip blib/lib/DBI/FAQ.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Policy/rush.pm (unchanged)<br/>Skip blib/lib/DBI/SQL/Nano.pm (unchanged)<br/>Skip blib/lib/DBI/Const/GetInfo/ANSI.pm (unchanged)<br/>Skip blib/lib/DBI/Gofer/Request.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Transport/stream.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Policy/classic.pm (unchanged)<br/>Skip blib/lib/DBI/Const/GetInfoReturn.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Policy/Base.pm (unchanged)<br/>Skip blib/lib/DBI.pm (unchanged)<br/>Skip blib/lib/DBI/Gofer/Serializer/Storable.pm (unchanged)<br/>Skip blib/lib/DBI/Gofer/Transport/stream.pm (unchanged)<br/>Skip blib/lib/DBD/Sponge.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Policy/pedantic.pm (unchanged)<br/>Skip blib/lib/DBI/W32ODBC.pm (unchanged)<br/>Skip blib/lib/DBI/DBD/SqlEngine/Developers.pod (unchanged)<br/>Skip blib/lib/DBI/Gofer/Transport/pipeone.pm (unchanged)<br/>Skip blib/lib/DBD/Gofer/Transport/null.pm (unchanged)<br/>Skip blib/lib/Bundle/DBI.pm (unchanged)<br/>Skip blib/lib/DBD/File/Developers.pod (unchanged)<br/>Skip blib/lib/DBI/Profile.pm (unchanged)<br/>Skip blib/lib/DBI/ProfileDumper.pm (unchanged)<br/>Skip blib/lib/DBI/ProxyServer.pm (unchanged)<br/>Skip blib/lib/DBI/Gofer/Serializer/Base.pm (unchanged)<br/>Skip blib/arch/auto/DBI/dbipport.h (unchanged)<br/>Skip blib/lib/DBI/Gofer/Execute.pm (unchanged)<br/>Skip blib/lib/DBI/DBD.pm (unchanged)<br/>Skip blib/lib/DBI/DBD/SqlEngine.pm (unchanged)<br/>Skip blib/lib/Win32/DBIODBC.pm (unchanged)<br/>Skip blib/lib/DBI/PurePerl.pm (unchanged)<br/>Skip blib/lib/DBD/ExampleP.pm (unchanged)<br/>Skip blib/lib/DBI/ProfileData.pm (unchanged)<br/> 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=\&quot;1.631\&quot; -DXS_VERSION=\&quot;1.631\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; Perl.c<br/>/bin/sh: xlc_r: not found.<br/>make: 1254-004 The error code from the last command is 127.<br/><br/><br/>Stop.<br/><br/># make test --- Step 5<br/><br/> 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=\&quot;1.631\&quot; -DXS_VERSION=\&quot;1.631\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; Perl.c<br/>/bin/sh: xlc_r: not found.<br/>make: 1254-004 The error code from the last command is 127.<br/><br/><br/>Stop.<br/><br/><br/><br/>________________________________<br/>Thanks &amp; Regards,<br/>Karthikeyan Paramasivan<br/>E-mail:Karthi_Keyan01&lt;mailto:Karthi_Keyan01@infosys.com&gt;|Mobile: +91-9994989217<br/><br/>**************** CAUTION - Disclaimer *****************<br/>This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely<br/>for the use of the addressee(s). If you are not the intended recipient, please<br/>notify the sender by e-mail and delete the original message. Further, you are not<br/>to copy, disclose, or distribute this e-mail or its contents to any other person and<br/>any such actions are unlawful. This e-mail may contain viruses. Infosys has taken<br/>every reasonable precaution to minimize this risk, but is not liable for any damage<br/>you may sustain as a result of any virus in this e-mail. You should carry out your<br/>own virus checks before opening the e-mail or attachment. Infosys reserves the<br/>right to monitor and review the content of all messages sent to or from this e-mail<br/>address. Messages sent to or from this e-mail address may be stored on the<br/>Infosys e-mail system.<br/>***INFOSYS******** End of Disclaimer ********INFOSYS***<br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36924.html Thu, 03 Apr 2014 17:13:25 +0000 Database encoding not recognized by DBD::Pg by Vincent Veyron Hi,<br/><br/>I have the following setup : Workstation, Primary, and Backup servers all running on a current version of Debian Stable. All run an identical LAMP stack of Apache/Mod_perl/Postgresql, except for default locale (see below). DBD::PG version is 3.0.0<br/><br/>My perl modules misbehave when connecting to a UTF8 encoded database on the backup server *only*. The link below shows the result of Data::Dumper, decode, and data_string_desc for each machine, for a record containing accented characters.<br/><br/>http://vincentveyron.com/tmp/tmp.html<br/><br/>I have 2 questions :<br/><br/>- Why does data_string_desc return &#39;UTF8 off&#39; all servers, when the database is UTF8 encoded?<br/><br/>- What should I inspect to understand why data_string_desc gets a wrong number of characters in the backup server?<br/><br/>#<br/>#/etc/default/locale for each server <br/>#<br/>#Workstation<br/>LANG=fr_FR.UTF-8<br/><br/>#Primary<br/>LANG=fr_FR@euro<br/>LANGUAGE=fr_FR:fr<br/><br/>#Backup<br/>LANG=fr_FR@euro<br/><br/><br/>#<br/>#Code used for the example<br/>#<br/>package Mysite::utf8_db_handle ;<br/><br/>use strict ;<br/>use warnings ;<br/><br/>use DBI qw(:utils) ;<br/><br/>use Data::Dumper ;<br/><br/>use Encode qw (decode) ;<br/><br/>use Apache2::Const -compile =&gt; qw (OK REDIRECT) ;<br/><br/>sub handler {<br/><br/> my $r = shift ;<br/><br/> my $dbh = DBI-&gt;connect_cached( &quot;DBI:Pg:dbname=bla_2&quot;, &#39;www-data&#39;, undef, {<br/> PrintError =&gt; 1,<br/> RaiseError =&gt; 1,<br/> AutoCommit =&gt; 1,<br/> pg_bool_tf =&gt; &#39;t&#39;<br/> } ) ;<br/><br/> my $sql = &#39;SELECT prenom FROM tblclient where id_client=2&#39; ;<br/><br/> my $result_set = $dbh-&gt;selectall_arrayref($sql) ;<br/><br/> my $content = &#39;&lt;h1&gt;Mysite&lt;/h1&gt;&#39; ;<br/> <br/> $content = &#39;&lt;h2&gt;Not decoded, using Data::Dumper&lt;/h2&gt;&#39; ;<br/><br/> $content .= &#39;&lt;pre&gt;&#39; ;<br/><br/> $content .= Dumper($result_set) ;<br/> <br/> $content .= &#39;&lt;/pre&gt;&#39; ;<br/><br/> $content .= &#39;&lt;h2&gt;Decoded using decode(UTF8,...&lt;/h2&gt;&#39; ;<br/><br/> $content .= &#39;&lt;p&gt;&#39; . ( decode(&#39;UTF8&#39;, $result_set-&gt;[0]-&gt;[0] ) || &#39;wtf?&#39; ) . &#39;&lt;/p&gt;&#39; ;<br/><br/> $content .= &#39;&lt;h2&gt;data_string_desc&lt;/h2&gt;&#39; ;<br/><br/> $content .= &#39;&lt;p&gt;&#39; . data_string_desc($result_set-&gt;[0]-&gt;[0]) . &#39;&lt;/p&gt;&#39; ;<br/><br/> $r-&gt;content_type(&#39;text/html; charset=UTF-8&#39;) ;<br/><br/> $r-&gt;no_cache(1) ;<br/><br/> print $content ;<br/><br/> return Apache2::Const::OK ;<br/><br/>}<br/><br/>1 ;<br/><br/><br/><br/>-- <br/> Salutations, Vincent Veyron<br/><br/>http://marica.fr/<br/>Gestion des contentieux, des dossiers de sinistres assurance et des contrats pour le service juridique<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/04/msg36923.html Thu, 03 Apr 2014 15:43:55 +0000 CPAN installation by Bhaskaran, Arun Hello,<br/><br/>Please be informed that we have upgraded our AIX box to 7.1 and are using Perl 5.10 on Oracle v.10.2,<br/>We are getting module related error while running some perl scripts, for which thought of installing them using CPAN.<br/><br/>When we execute the command perl -MCPAN -eshell, we get the following output:<br/><br/># /usr/opt/perl5/bin/perl -MCPAN -eshell<br/>Sorry, we have to rerun the configuration dialog for CPAN.pm due to<br/>some missing parameters...<br/>The following questions are intended to help you with the<br/>configuration. The CPAN module needs a directory of its own to cache<br/>important index files and maybe keep a temporary mirror of CPAN files.<br/>This may be a site-wide or a personal directory.<br/>I see you already have a directory<br/> /root/.cpan<br/>Shall we use it as the general CPAN build and cache directory?<br/>&lt;cpan_home&gt;<br/>CPAN build and cache directory? [/root/.cpan] yes<br/>The path &#39;yes&#39; is not an absolute path. Please specify an absolute path<br/>CPAN build and cache directory? [/home/abn5/DBD-Oracle-1.70/yes] /root/.cpan<br/>Unless you are accessing the CPAN on your filesystem via a file: URL,<br/>CPAN.pm needs to keep the source files it downloads somewhere. Please<br/>supply a directory where the downloaded files are to be kept.<br/>&lt;keep_source_where&gt;<br/>Download target directory? [/root/.cpan/sources]<br/>&lt;build_dir&gt;<br/>Directory where the build process takes place? [/root/.cpan/build]<br/>Normally CPAN.pm keeps config variables in memory and changes need to<br/>be saved in a separate &#39;o conf commit&#39; command to make them permanent<br/>between sessions. If you set the &#39;auto_commit&#39; option to true, changes<br/>to a config variable are always automatically committed to disk.<br/>&lt;auto_commit&gt;<br/>Always commit changes to config variables to disk? [no]<br/>CPAN.pm can limit the size of the disk area for keeping the build<br/>directories with all the intermediate files.<br/>&lt;build_cache&gt;<br/>Cache size for build directory (in MB)? [100]<br/>The CPAN indexes are usually rebuilt once or twice per hour, but the<br/>typical CPAN mirror mirrors only once or twice per day. Depending on<br/>the quality of your mirror and your desire to be on the bleeding edge,<br/>you may want to set the following value to more or less than one day<br/>(which is the default). It determines after how many days CPAN.pm<br/>downloads new indexes.<br/>&lt;index_expire&gt;<br/>Let the index expire after how many days? [1]<br/>By default, each time the CPAN module is started, cache scanning is<br/>performed to keep the cache size in sync. To prevent this, answer<br/>&#39;never&#39;.<br/>&lt;scan_cache&gt;<br/>Perform cache scanning (atstart or never)? [atstart]<br/>To considerably speed up the initial CPAN shell startup, it is<br/>possible to use Storable to create a cache of metadata. If Storable is<br/>not available, the normal index mechanism will be used.<br/>Note: this mechanism is not used when use_sqlite is on and SQLLite is<br/>running.<br/>&lt;cache_metadata&gt;<br/>Cache metadata (yes/no)? [yes]<br/>The CPAN module can detect when a module which you are trying to build<br/>depends on prerequisites. If this happens, it can build the<br/>prerequisites for you automatically (&#39;follow&#39;), ask you for<br/>confirmation (&#39;ask&#39;), or just ignore them (&#39;ignore&#39;). Please set your<br/>policy to one of the three values.<br/>&lt;prerequisites_policy&gt;<br/>Policy on building prerequisites (follow, ask or ignore)? [ask]<br/>Every Makefile.PL is run by perl in a separate process. Likewise we<br/>run &#39;make&#39; and &#39;make install&#39; in separate processes. If you have<br/>any parameters (e.g. PREFIX, UNINST or the like) you want to<br/>pass to the calls, please specify them here.<br/>If you don&#39;t understand this question, just press ENTER.<br/>Typical frequently used settings:<br/> PREFIX=~/perl # non-root users (please see manual for more hints)<br/>&lt;makepl_arg&gt;<br/>Parameters for the &#39;perl Makefile.PL&#39; command? []<br/>Parameters for the &#39;make&#39; command? Typical frequently used setting:<br/> -j3 # dual processor system (on GNU make)<br/>&lt;make_arg&gt;<br/>Your choice: []<br/>Parameters for the &#39;make install&#39; command?<br/>Typical frequently used setting:<br/> UNINST=1 # to always uninstall potentially conflicting files<br/>&lt;make_install_arg&gt;<br/>Your choice: []<br/>A Build.PL is run by perl in a separate process. Likewise we run<br/>&#39;./Build&#39; and &#39;./Build install&#39; in separate processes. If you have any<br/>parameters you want to pass to the calls, please specify them here.<br/>Typical frequently used settings:<br/> --install_base /home/xxx # different installation directory<br/>&lt;mbuildpl_arg&gt;<br/>Parameters for the &#39;perl Build.PL&#39; command? []<br/>Parameters for the &#39;./Build&#39; command? Setting might be:<br/> --extra_linker_flags -L/usr/foo/lib # non-standard library location<br/>&lt;mbuild_arg&gt;<br/>Your choice: []<br/>Do you want to use a different command for &#39;./Build install&#39;? Sudo<br/>users will probably prefer:<br/> su root -c ./Build<br/>or<br/> sudo ./Build<br/>or<br/> /path1/to/sudo -u admin_account ./Build<br/>&lt;mbuild_install_build_command&gt;<br/>or some such. Your choice: [./Build]<br/>Parameters for the &#39;./Build install&#39; command? Typical frequently used<br/>setting:<br/> --uninst 1 # uninstall conflicting files<br/>&lt;mbuild_install_arg&gt;<br/>Your choice: []<br/>If you&#39;re accessing the net via proxies, you can specify them in the<br/>CPAN configuration or via environment variables. The variable in<br/>the $CPAN::Config takes precedence.<br/>&lt;ftp_proxy&gt;<br/>Your ftp_proxy? []<br/>&lt;http_proxy&gt;<br/>Your http_proxy? []<br/>&lt;no_proxy&gt;<br/>Your no_proxy? []<br/>CPAN needs access to at least one CPAN mirror.<br/>As you did not allow me to connect to the internet you need to supply<br/>a valid CPAN URL now.<br/>Please enter the URL of your CPAN mirror<br/><br/>Now we need to know what details we need to feed for CPAN mirror, if you can guide us it will be helpful.<br/><br/>Thanks &amp; Regards,<br/>Arun Bhaskaran<br/>+919611134241<br/>arun.bhaskaran@xerox.com<br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36922.html Sun, 30 Mar 2014 09:08:50 +0000 Re: DBI Mysql Driver Handle Mysteriously Changes! by Duncan McEwan Hi,<br/><br/>&gt; &gt; <br/>&gt; &gt; At the moment I only turn DBI tracing on in the connect_cached() call and<br/>&gt; &gt; turn it off again before the call returns. I did that because I was worried<br/>&gt; &gt; about the amount of output that would be produced if I left tracing on.<br/>&gt; &gt; But perhaps that is what I will have to do.<br/>&gt; <br/>&gt; Perhaps you don&#39;t need to output it. Call $stacktrace = Carp::longmess<br/>&gt; and only output it if the stacktrace is different to the last one, or<br/>&gt; some similar logic.<br/><br/>I decided I had enough disk space to just leave debugging on for a bit and<br/>a quick look at the debugging I&#39;m getting now shows something that seems<br/>odd and potentially may be interesting.<br/><br/>I&#39;m now getting debugging for more than just calls to connect_cached().<br/>It seems that as well as calling DBI-&gt;connect_cached() for it&#39;s connections to<br/>one database, our application is also calling DBI-&gt;connect() for connections<br/>to a different database (I think this may be buried in the CGI::Application<br/>package that the application uses, which is why I hadn&#39;t noticed it before).<br/><br/>Both databases are on the same mysql server.<br/><br/>I haven&#39;t looked at it in detail yet (and as it&#39;s nearly home time on Friday<br/>evening here won&#39;t have time to look at it properly until later!). But the<br/>quick look I have had seems to reveal that the driver handle changes after<br/>each call (or maybe only some calls?) to DBI-&gt;connect().<br/><br/>Perhaps a more in-depth examination will show I&#39;ve misinterpreted the debugging<br/>and this isn&#39;t what is happening. If so, I&#39;ll post a followup message later.<br/>But I thought it worth posting this message now to ask if this sounds like<br/>something that could happen. And if it could, is it a feature or a bug?<br/><br/>Thanks for all the help/pointers so far...<br/><br/>Duncan<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36921.html Fri, 28 Mar 2014 04:11:49 +0000 Re: DBI Mysql Driver Handle Mysteriously Changes! by Tim Bunce On Thu, Mar 27, 2014 at 04:43:41PM +1300, Duncan McEwan wrote:<br/>&gt; <br/>&gt; &gt; &gt; I&#39;ve got 1000&#39;s of lines of debugging showing this happening. Some of it<br/>&gt; &gt; &gt; is my own, inserted as print statements or cluck calls directly into DBI.pm<br/>&gt; &gt; &gt; and some of it the standard DBI debugging set to level 9. There is way too<br/>&gt; &gt; &gt; much to include in this message, but I&#39;ve included some small extracts below<br/>&gt; &gt; &gt; to illustrate what I am seeing.<br/>&gt; &gt; <br/>&gt; &gt; What you&#39;ve included doesn&#39;t show the drh changing.<br/>&gt; <br/>&gt; Then maybe I&#39;m mis-interpreting the debugging I&#39;m seeing?<br/><br/>No, nevermind, I was. Thanks.<br/><br/>&gt; &gt; I suggest you focus on that. Specifically the code path taken by the<br/>&gt; &gt; request that notices that the drh has changed, _and_ the code path taken<br/>&gt; &gt; by the _previous_ request _in the same process_.<br/>&gt; <br/>&gt; Yes. I had been looking at that. Within DBI.pm I&#39;ve inserted calls to<br/>&gt; cluck so I could see the stack trace both the case when a cached database<br/>&gt; handle is returned and when a new one is created. There were *sometimes*<br/>&gt; differences in the call stack between those times, but sometimes not.<br/>&gt; <br/>&gt; At the moment I only turn DBI tracing on in the connect_cached() call and<br/>&gt; turn it off again before the call returns. I did that because I was worried<br/>&gt; about the amount of output that would be produced if I left tracing on.<br/>&gt; But perhaps that is what I will have to do.<br/><br/>Perhaps you don&#39;t need to output it. Call $stacktrace = Carp::longmess<br/>and only output it if the stacktrace is different to the last one, or<br/>some similar logic.<br/><br/>Also try turning on $drh-&gt;{TraceLevel} after the $dbh is created.<br/>That&#39;ll then log just future connect_cached calls *and* handle<br/>destruction, which might be useful.<br/><br/>&gt; A potential further complication that I didn&#39;t mention previously is that<br/>&gt; our application (which I *did* mention is written as a foswiki plugin)<br/>&gt; uses the CGI::Application perl package. From a very quick look at its<br/>&gt; code, it does seem to know about the DBI and could perhaps be doing something<br/>&gt; &quot;too clever&quot; which is causing us problems. I&#39;ll look more into that as<br/>&gt; well.<br/><br/>I didn&#39;t see anything suspicious in CGI::Application<br/>https://metacpan.org/source/MARKSTOS/CGI-Application-4.50/lib/CGI/Application.pm<br/>or CGI::Application::Plugin::DBH<br/>https://metacpan.org/source/FREW/CGI-Application-Plugin-DBH-4.04/lib/CGI/Application/Plugin/DBH.pm<br/><br/>For more areas to dig, note the mention of dbi_connect_method<br/>in https://metacpan.org/pod/DBI#connect and<br/>https://metacpan.org/source/TIMB/DBI-1.631/DBI.pm#L571<br/><br/>Keep focused on why a new drh appears.<br/><br/>See https://metacpan.org/source/TIMB/DBI-1.631/DBI.pm#L652<br/>Perhaps something is altering %DBI::installed_drh<br/><br/>Tim.<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36920.html Thu, 27 Mar 2014 13:36:44 +0000 Re: DBI Mysql Driver Handle Mysteriously Changes! by Duncan McEwan Hi Tim,<br/><br/>Thanks for the quick response.<br/><br/>&gt; Could you post the fcgid configuration details for us?<br/>&gt; https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html<br/><br/>Our full httpd config is long and complex and not very pretty! I&#39;ve extracted<br/>out what I think are the bits from it that are associated with making foswiki<br/>run under fcgid and attached them below.<br/><br/>&gt; &gt; The database connection used by this application should be persistent<br/>&gt; &gt; due to the application calling DBI-&gt;connect_cached() on each invocation.<br/>&gt; <br/>&gt; Persistent within a single backend process, yes.<br/><br/>Yes, that&#39;s right. Our apache fires off a number of fcgid handlers, each<br/>one running a persistent instance of the foswiki perl code. Our application<br/>is in turn written as a foswiki &quot;plugin&quot;. So in theory, each fcgid/foswiki<br/>instance (process) should have a single persistent database connection<br/>(the database, host, password and attributes are always the same) which gets<br/>used when required to answer any queries that Apache passes to it.<br/><br/>&gt; &gt; I&#39;ve got 1000&#39;s of lines of debugging showing this happening. Some of it<br/>&gt; &gt; is my own, inserted as print statements or cluck calls directly into DBI.pm<br/>&gt; &gt; and some of it the standard DBI debugging set to level 9. There is way too<br/>&gt; &gt; much to include in this message, but I&#39;ve included some small extracts below<br/>&gt; &gt; to illustrate what I am seeing.<br/>&gt; <br/>&gt; What you&#39;ve included doesn&#39;t show the drh changing.<br/><br/>Then maybe I&#39;m mis-interpreting the debugging I&#39;m seeing? The log extract<br/>I posted contained:<br/><br/>DBI::dr=HASH(0x7f7fe874fee8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.630-ithread (pid 18887)<br/>...<br/>DBI::dr=HASH(0x7f7fe874fee8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.630-ithread (pid 18887)<br/>...<br/>&lt;lots of repetitions of the above&gt;<br/>...<br/>DBI::dr=HASH(0x7f7fe299c5e8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.630-ithread (pid 18887)<br/><br/>The last DBI::dr=HASH(...) had a different value than the preceding ones.<br/> <br/>&gt; I suggest you focus on that. Specifically the code path taken by the<br/>&gt; request that notices that the drh has changed, _and_ the code path taken<br/>&gt; by the _previous_ request _in the same process_.<br/><br/>Yes. I had been looking at that. Within DBI.pm I&#39;ve inserted calls to<br/>cluck so I could see the stack trace both the case when a cached database<br/>handle is returned and when a new one is created. There were *sometimes*<br/>differences in the call stack between those times, but sometimes not.<br/><br/>At the moment I only turn DBI tracing on in the connect_cached() call and<br/>turn it off again before the call returns. I did that because I was worried<br/>about the amount of output that would be produced if I left tracing on.<br/>But perhaps that is what I will have to do.<br/><br/>A potential further complication that I didn&#39;t mention previously is that<br/>our application (which I *did* mention is written as a foswiki plugin)<br/>uses the CGI::Application perl package. From a very quick look at its<br/>code, it does seem to know about the DBI and could perhaps be doing something<br/>&quot;too clever&quot; which is causing us problems. I&#39;ll look more into that as<br/>well.<br/><br/>&gt; &gt; I don&#39;t know enough about perl internals to know exactly what this does.<br/>&gt; &gt; But I did wonder if something like the following might be better given the<br/>&gt; &gt; persistent nature of our application provided by fcgid.<br/>&gt; &gt; <br/>&gt; &gt; my $dbi = new DBI;<br/>&gt; &gt; my $dbh = $dbi-&gt;connect_cached(...)<br/>&gt; <br/>&gt; No. Using new DBI (or DBI-&gt;new) isn&#39;t a valid way to use the DBI.<br/>&gt; Just DBI-&gt;connect_cached is fine.<br/><br/>OK - thanks for clarifying that and ruling it out as the source of the problem,<br/><br/>Duncan<br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36919.html Thu, 27 Mar 2014 03:43:54 +0000 DBD::mysql 4.027 released by Patrick Galbraith Dear Perl community,<br/><br/>I&rsquo;m pleased to announce the release of DBD::mysql 4.027. This release isn&rsquo;t a huge release but has some nice fixes nonetheless. Particularly, some fixes that improve building and installing on OS X.<br/><br/>Per the change log:<br/><br/>2014-13-15 Patrick Galbraith, Michiel Beijen, DBI/DBD community (4.027)<br/>* Added more OS X notes and fixed compiler warnings<br/>* Skip tests if test database is not present-RT92330 (zefram &lt;zefram at fysh dot org&gt;<br/>* metacpan.org and search.cpan.org didn&#39;t display module POD, caused by fix for RT90101. Reported by Oleg, RT92350.<br/><br/>As before, thank you to Michael Beijen and the community for your help!<br/><br/>You can find the latest in github:<br/><br/>https://github.com/perl5-dbi/DBD-mysql<br/><br/>As well as CPAN:<br/><br/>http://search.cpan.org/~capttofu/DBD-mysql-4.027/lib/DBD/mysql.pm<br/><br/>Thank you for using DBD::mysql!<br/><br/>Patrick Galbraith<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36918.html Tue, 25 Mar 2014 16:31:33 +0000 Re: DBI Mysql Driver Handle Mysteriously Changes! by Tim Bunce Hello Duncan.<br/><br/>On Tue, Mar 25, 2014 at 04:42:56PM +1300, Duncan McEwan wrote:<br/>&gt; <br/>&gt; First, a brief recap. We have a web-based application that runs as a FosWiki <br/>&gt; plugin under Apache/fcgid.<br/><br/>Could you post the fcgid configuration details for us?<br/>https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html<br/><br/>&gt; The database connection used by this application should be persistent<br/>&gt; due to the application calling DBI-&gt;connect_cached() on each invocation.<br/><br/>Persistent within a single backend process, yes.<br/><br/>&gt; The new piece of information that I have discovered recently is that on a<br/>&gt; call to connect_cached() which *doesn&#39;t* return the cached database handle,<br/>&gt; the database driver handle reference passed into connect_cached() has changed.<br/>&gt; Since the dbh cache is obtained from &quot;$drh-&gt;{CachedKids} ||= {}&quot; I can now<br/>&gt; understand why the cached handled is not found!<br/>&gt; <br/>&gt; What I can&#39;t understand is why the driver handle passed into connect_cached()<br/>&gt; has changed!<br/><br/>Neither can I.<br/><br/>&gt; I&#39;ve got 1000&#39;s of lines of debugging showing this happening. Some of it<br/>&gt; is my own, inserted as print statements or cluck calls directly into DBI.pm<br/>&gt; and some of it the standard DBI debugging set to level 9. There is way too<br/>&gt; much to include in this message, but I&#39;ve included some small extracts below<br/>&gt; to illustrate what I am seeing.<br/><br/>What you&#39;ve included doesn&#39;t show the drh changing.<br/><br/>I suggest you focus on that. Specifically the code path taken by the<br/>request that notices that the drh has changed, _and_ the code path taken<br/>by the _previous_ request _in the same process_.<br/><br/>&gt; One thing I did just notice is that our application calls connect_cached()<br/>&gt; in the way shown in the DBI pod - that is:<br/>&gt; <br/>&gt; my $dbh = DBI-&gt;connect_cached(...)<br/>&gt; <br/>&gt; I don&#39;t know enough about perl internals to know exactly what this does.<br/>&gt; But I did wonder if something like the following might be better given the<br/>&gt; persistent nature of our application provided by fcgid.<br/>&gt; <br/>&gt; my $dbi = new DBI;<br/>&gt; my $dbh = $dbi-&gt;connect_cached(...)<br/><br/>No. Using new DBI (or DBI-&gt;new) isn&#39;t a valid way to use the DBI.<br/>Just DBI-&gt;connect_cached is fine.<br/><br/>Tim.<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36917.html Tue, 25 Mar 2014 10:53:59 +0000 DBI Mysql Driver Handle Mysteriously Changes! by Duncan McEwan Hi there,<br/><br/>Way back in December 2012 I posted a query to this list with the subject<br/>&quot;Possible database handle leak in DBI?&quot;. There were a few replies to my<br/>query, which can be found at<br/>https://groups.google.com/forum/#!topic/perl.dbi.users/nElyR6hFka8<br/>but no conclusive answer.<br/><br/>The lack of follow up was partly because we had our Christmas/summer break<br/>and then in the new year there were other problems to deal with. Also the<br/>issue seemed to occur less frequently, so tracking it down got put on the<br/>backburner, where it has remained until now...<br/><br/>Recently the problem has been occurring more frequently again, causing our<br/>mysql server to run out of connections. We&#39;ve papered over the problem by<br/>increasing the maximum number of connections and restarting our web server<br/>each night. But it would be much more satisfying to figure out what is<br/>going on here!<br/><br/>Quite a few things have changed since my post of 15 months ago (newer versions<br/>of DBI, DBD::mysql, mysql etc, plus our Apache now uses fcgid rather than<br/>fastcgi). I know I should give all the relevant version numbers, but given that<br/>the problem has persisted over multiple versions I&#39;m not sure that would help<br/>all that much.<br/><br/>Instead I&#39;ll describe the one new fact that my recent debugging efforts have<br/>turned up. Hopefully this may allow someone with a deeper understanding<br/>of the perl DBI and/or DBD::mysql packages to suggest what might be happening<br/>here, or at least some more debugging strategies I could try...<br/><br/>First, a brief recap. We have a web-based application that runs as a FosWiki <br/>plugin under Apache/fcgid. The database connection used by this application <br/>should be persistent due to the application calling DBI-&gt;connect_cached() on<br/>each invocation.<br/><br/>What we see is that most of the time this works correctly, but every so<br/>often the call to connect_cached() doesn&#39;t find the cached connection and<br/>so creates a new one. This is despite a &quot;mysql processlist&quot; showing that<br/>the old connection *is* still active.<br/><br/>The new piece of information that I have discovered recently is that on a<br/>call to connect_cached() which *doesn&#39;t* return the cached database handle,<br/>the database driver handle reference passed into connect_cached() has changed.<br/>Since the dbh cache is obtained from &quot;$drh-&gt;{CachedKids} ||= {}&quot; I can now<br/>understand why the cached handled is not found!<br/><br/>What I can&#39;t understand is why the driver handle passed into connect_cached()<br/>has changed! Especially since none of our application code knows or cares<br/>about the existence of the driver handle (and as stated in the DBI pod, the<br/>driver handle object is rarely seen or used in applications).<br/><br/>I&#39;ve got 1000&#39;s of lines of debugging showing this happening. Some of it<br/>is my own, inserted as print statements or cluck calls directly into DBI.pm<br/>and some of it the standard DBI debugging set to level 9. There is way too<br/>much to include in this message, but I&#39;ve included some small extracts below<br/>to illustrate what I am seeing.<br/><br/>From these small extracts I don&#39;t expect anyone to be able to debug this<br/>for me. What I am hoping for though is perhaps some insight into the<br/>circumstances in which the driver handle could change in this way.<br/><br/>One thing I did just notice is that our application calls connect_cached()<br/>in the way shown in the DBI pod - that is:<br/><br/> my $dbh = DBI-&gt;connect_cached(...)<br/><br/>I don&#39;t know enough about perl internals to know exactly what this does.<br/>But I did wonder if something like the following might be better given the<br/>persistent nature of our application provided by fcgid.<br/><br/> my $dbi = new DBI;<br/> my $dbh = $dbi-&gt;connect_cached(...)<br/><br/>Any other advice would be greatly appreciated.<br/><br/>Thanks,<br/><br/>Duncan<br/><br/>Extract from Debugging:<br/><br/><br/> DBI::dr=HASH(0x7f7fe874fee8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.630-ithread (pid 18887)<br/> DBI 1.630-ithread default trace level set to 0x0/9 (pid 18887 pi 7f7ff7703000) at DBI.pm line 1494 via UM.pm line 191<br/> ...<br/> No cached handle - creating new connection, dbh = DBI::db=HASH(0x7f7fe86f8468)<br/> ...<br/><br/> DBI::dr=HASH(0x7f7fe874fee8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.630-ithread (pid 18887)<br/> DBI 1.630-ithread default trace level set to 0x0/9 (pid 18887 pi 7f7ff7703000) at DBI.pm line 1494 via UM.pm line 450<br/> ...<br/> Using cached handle, dbh = DBI::db=HASH(0x7f7fe86f8468)<br/> ...<br/><br/> &lt;lots of repetitions of the above&gt;<br/><br/> ...<br/><br/> DBI::dr=HASH(0x7f7fe299c5e8) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.630-ithread (pid 18887)<br/> DBI 1.630-ithread default trace level set to 0x0/9 (pid 18887 pi 7f7ff7703000) at DBI.pm line 1494 via UM.pm line 191<br/> ...<br/> No cached handle - creating new connection, dbh = DBI::db=HASH(0x7f7fe2819db0)<br/> ...<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36916.html Tue, 25 Mar 2014 03:43:08 +0000 Re: make test failed for perl module DBD-Oracle-1.70 by Martin J. Evans On 19/03/2014 18:31, Jillapelli, Ramakrishna wrote:<br/>&gt; Hi,<br/>&gt;<br/>&gt; struck with &ldquo;DBD-Oracle-1.70&rdquo;<br/><br/>You are likely to get more/better help if you tell us more. Platform? <br/>Perl version and where it came from? compiler? Oracle you are compiling <br/>against - full Oracle or Instant Client and version?<br/><br/>Anyway, I can guess some from the following:<br/><br/>&gt; Make test returned the following error:<br/>&gt;<br/>&gt; cp lib/DBD/Oracle/Troubleshooting/Win32.pod<br/>&gt; blib/lib/DBD/Oracle/Troubleshooting/Win32.pod<br/>&gt;<br/>&gt; cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm<br/>&gt;<br/>&gt; /usr/bin/perl -e &#39;use ExtUtils::Mksymlists; Mksymlists(&quot;NAME&quot;<br/>&gt; =&gt; &quot;DBD::Oracle&quot;, &quot;DL_FUNCS&quot; =&gt; { }, &quot;FUNCLIST&quot; =&gt; [], &quot;DL_VARS&quot; =&gt; []);&#39;<br/>&gt;<br/>&gt; /usr/bin/perl -p -e &quot;s/~DRIVER~/Oracle/g&quot;<br/>&gt; /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst<br/>&gt; &gt; Oracle.xsi<br/><br/>You are possibly using perl 5.10.1 - pretty old now but should still be <br/>ok. /usr/opt is an unusual place to see Perl so I&#39;m guessing this is a <br/>Perl installed via your operating system vendor.<br/><br/>&gt; /usr/bin/perl /usr/opt/perl5/lib/5.10.1/ExtUtils/xsubpp<br/>&gt; -typemap /usr/opt/perl5/lib/5.10.1/ExtUtils/typemap -typemap typemap<br/>&gt; Oracle.xs &gt; Oracle.xsc &amp;&amp; mv Oracle.xsc Oracle.c<br/>&gt;<br/>&gt; xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public<br/><br/>xlc_r. That looks like the IBM AIX compiler?<br/><br/>You need to compile and link DBD::Oracle using the same tools (compiler <br/>and linker) as IBM (or whoever) built your Perl. If this is an IBM <br/>compiled Perl for AIX they probably used their compiler (xlc) - a perl <br/>-V should verify this.<br/><br/>&gt; -I/oracle/product/v102/fullclnt/rdbms/demo<br/>&gt; -I/oracle/product/v102/fullclnt/rdbms/public<br/>&gt; -I/oracle/product/v102/fullclnt/plsql/public<br/>&gt; -I/oracle/product/v102/fullclnt/network/public<br/>&gt; -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI<br/>&gt; -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias<br/>&gt; -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended<br/>&gt; -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O<br/>&gt; -DVERSION=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot;<br/>&gt; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT<br/>&gt; -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 Oracle.c<br/><br/>Guessing you are using Oracle OCI 10.2.0.1 and this is a full install of <br/>Oracle and not instant client.<br/><br/>&gt; xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public<br/>&gt; -I/oracle/product/v102/fullclnt/rdbms/demo<br/>&gt; -I/oracle/product/v102/fullclnt/rdbms/public<br/>&gt; -I/oracle/product/v102/fullclnt/plsql/public<br/>&gt; -I/oracle/product/v102/fullclnt/network/public<br/>&gt; -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI<br/>&gt; -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias<br/>&gt; -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended<br/>&gt; -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O<br/>&gt; -DVERSION=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot;<br/>&gt; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT<br/>&gt; -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 dbdimp.c<br/>&gt;<br/>&gt; xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public<br/>&gt; -I/oracle/product/v102/fullclnt/rdbms/demo<br/>&gt; -I/oracle/product/v102/fullclnt/rdbms/public<br/>&gt; -I/oracle/product/v102/fullclnt/plsql/public<br/>&gt; -I/oracle/product/v102/fullclnt/network/public<br/>&gt; -I/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI<br/>&gt; -D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias<br/>&gt; -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended<br/>&gt; -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O<br/>&gt; -DVERSION=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot;<br/>&gt; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT<br/>&gt; -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 oci8.c<br/>&gt;<br/>&gt; Running Mkbootstrap for DBD::Oracle ()<br/>&gt;<br/>&gt; chmod 644 Oracle.bs<br/>&gt;<br/>&gt; rm -f blib/arch/auto/DBD/Oracle/Oracle.so<br/>&gt;<br/>&gt;<br/>&gt; LD_RUN_PATH=&quot;/oracle/product/v102/fullclnt/lib32:/oracle/product/v102/fullclnt/rdbms/lib32&quot;<br/>&gt; ld -bhalt:4 -G<br/>&gt; -bI:/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE/perl.exp<br/>&gt; -bE:Oracle.exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib Oracle.o<br/>&gt; dbdimp.o oci8.o -q32 -L/oracle/product/v102/fullclnt/lib32/<br/>&gt; -L/oracle/product/v102/fullclnt/rdbms//lib32/ -lclntsh -lld -lm `cat<br/>&gt; /oracle/product/v102/fullclnt/lib32/sysliblist` -lm -lpthreads -o<br/>&gt; blib/arch/auto/DBD/Oracle/Oracle.so<br/>&gt;<br/>&gt; ld: 0706-012 The -q flag is not recognized.<br/>&gt;<br/>&gt; ld: 0706-012 The -3 flag is not recognized.<br/>&gt;<br/>&gt; ld: 0706-012 The -2 flag is not recognized.<br/><br/>That is a bit strange as it is passing -q32 to ld which is the linker.<br/><br/>What does a perl -V output?<br/><br/>You could try searching the Makefile for -q32 and removing it from <br/>anything that looks like a linker (ld) command argument e.g., LDFLAGS. <br/>That is a bit of a hack but it should get you further. If you are <br/>struggling with this mail the Makefile to me (only) and I&#39;ll take a look.<br/><br/><br/>&gt; make: The error code from the last command is 255.<br/>&gt;<br/>&gt; Stop.<br/>&gt;<br/>&gt; [root@ews-pgh1-esmd2] /home/rj46/DBD-Oracle-1.70<br/>&gt;<br/>&gt; q32 option is mandatory?<br/><br/>no idea what your question is there.<br/><br/>&gt;<br/>&gt; Can you please guide how to proceed on this?<br/>&gt;<br/>&gt; Thanks &amp; Regards,<br/><br/><br/>Martin<br/>-- <br/>Martin J. Evans<br/>Wetherby, UK<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36915.html Wed, 19 Mar 2014 19:17:15 +0000 make test failed for perl module DBD-Oracle-1.70 by Jillapelli, Ramakrishna Hi,<br/><br/>struck with &quot;DBD-Oracle-1.70&quot;<br/><br/>Make test returned the following error:<br/><br/><br/>cp lib/DBD/Oracle/Troubleshooting/Win32.pod blib/lib/DBD/Oracle/Troubleshooting/Win32.pod<br/>cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm<br/> /usr/bin/perl -e &#39;use ExtUtils::Mksymlists; Mksymlists(&quot;NAME&quot; =&gt; &quot;DBD::Oracle&quot;, &quot;DL_FUNCS&quot; =&gt; { }, &quot;FUNCLIST&quot; =&gt; [], &quot;DL_VARS&quot; =&gt; []);&#39;<br/> /usr/bin/perl -p -e &quot;s/~DRIVER~/Oracle/g&quot; /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi/auto/DBI/Driver.xst &gt; Oracle.xsi<br/> /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 &gt; Oracle.xsc &amp;&amp; mv Oracle.xsc Oracle.c<br/> xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/plsql/public -I/oracle/product/v102/fullclnt/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=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 Oracle.c<br/> xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/plsql/public -I/oracle/product/v102/fullclnt/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=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 dbdimp.c<br/> xlc_r -q32 -c -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/rdbms/demo -I/oracle/product/v102/fullclnt/rdbms/public -I/oracle/product/v102/fullclnt/plsql/public -I/oracle/product/v102/fullclnt/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=\&quot;1.70\&quot; -DXS_VERSION=\&quot;1.70\&quot; &quot;-I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE&quot; -DUTF8_SUPPORT -DORA_OCI_VERSION=\&quot;10.2.0.1\&quot; -DORA_OCI_102 oci8.c<br/>Running Mkbootstrap for DBD::Oracle ()<br/> chmod 644 Oracle.bs<br/> rm -f blib/arch/auto/DBD/Oracle/Oracle.so<br/> LD_RUN_PATH=&quot;/oracle/product/v102/fullclnt/lib32:/oracle/product/v102/fullclnt/rdbms/lib32&quot; 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 -q32 -L/oracle/product/v102/fullclnt/lib32/ -L/oracle/product/v102/fullclnt/rdbms//lib32/ -lclntsh -lld -lm `cat /oracle/product/v102/fullclnt/lib32/sysliblist` -lm -lpthreads -o blib/arch/auto/DBD/Oracle/Oracle.so<br/>ld: 0706-012 The -q flag is not recognized.<br/>ld: 0706-012 The -3 flag is not recognized.<br/>ld: 0706-012 The -2 flag is not recognized.<br/>make: The error code from the last command is 255.<br/><br/><br/>Stop.<br/><br/>[root@ews-pgh1-esmd2] /home/rj46/DBD-Oracle-1.70<br/><br/>q32 option is mandatory?<br/><br/>Can you please guide how to proceed on this?<br/><br/><br/>Thanks &amp; Regards,<br/><br/>Ramakrishna Jillapelli,<br/>Global Services, Operations and Engineering,<br/><br/>XEROX Business Services,<br/>9th Floor, Explorer Block, White Field Road, ITPL,<br/>Bangalore - 560066, India.<br/><br/>E-Mail: Ramakrishna.Jillapelli@xerox.com&lt;mailto:Ramakrishna.Jillapelli@xerox.com&gt;,<br/>Ph: +1-214-530-2222, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36914.html Wed, 19 Mar 2014 18:31:37 +0000 Re: make test failed for Perl module Crypt-SSLeay-0.65_02 by Chad Wallace On Tue, 18 Mar 2014 16:25:59 +0000<br/>&quot;Jillapelli, Ramakrishna&quot; &lt;Ramakrishna.Jillapelli@xerox.com&gt; wrote:<br/><br/>&gt; Hi,<br/>&gt; <br/>&gt; I am getting the following error while doing &quot;make test&quot; for Perl<br/>&gt; module &quot;Crypt-SSLeay-0.65_02&quot;<br/>&gt; <br/>&gt; # make test<br/>&gt; PERL_DL_NONLAZY=1 /usr/bin/perl &quot;-MExtUtils::Command::MM&quot;<br/>&gt; &quot;-e&quot; &quot;test_harness(0, &#39;blib/lib&#39;, &#39;blib/arch&#39;)&quot; t/*.t<br/>&gt; t/00-basic.t .... ok t/01-connect.t .. ok<br/>&gt; t/02-live.t ..... Can&#39;t locate Try/Tiny.pm in @INC (@INC<br/>[...]<br/>&gt; <br/>&gt; I have searched in the code for file &quot;Tiny.pm&quot; not found it. Please<br/>&gt; help me to fix this issue.<br/><br/>Install Try::Tiny from CPAN.<br/><br/><br/><br/>-- <br/><br/>C. Chad Wallace, B.Sc.<br/>The Lodging Company<br/>http://www.lodgingcompany.com/<br/>OpenPGP Public Key ID: 0x262208A0<br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36913.html Tue, 18 Mar 2014 21:10:54 +0000 make test failed for Perl module Crypt-SSLeay-0.65_02 by Jillapelli, Ramakrishna Hi,<br/><br/>I am getting the following error while doing &quot;make test&quot; for Perl module &quot;Crypt-SSLeay-0.65_02&quot;<br/><br/># make test<br/> PERL_DL_NONLAZY=1 /usr/bin/perl &quot;-MExtUtils::Command::MM&quot; &quot;-e&quot; &quot;test_harness(0, &#39;blib/lib&#39;, &#39;blib/arch&#39;)&quot; t/*.t<br/>t/00-basic.t .... ok<br/>t/01-connect.t .. ok<br/>t/02-live.t ..... Can&#39;t locate Try/Tiny.pm in @INC (@INC contains: /home/rj46/Crypt-SSLeay-0.65_02/blib/lib /home/rj46/Crypt-SSLeay-0.65_02/blib/arch /usr/opt/perl5/lib/5.10.1/aix-thread-multi /usr/opt/perl5/lib/5.10.1 /usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi /usr/opt/perl5/lib/site_perl/5.10.1 .) at t/02-live.t line 4.<br/>BEGIN failed--compilation aborted at t/02-live.t line 4.<br/>t/02-live.t ..... Dubious, test returned 2 (wstat 512, 0x200)<br/>No subtests run<br/><br/>Test Summary Report<br/>-------------------<br/>t/02-live.t (Wstat: 512 Tests: 0 Failed: 0)<br/> Non-zero exit status: 2<br/> Parse errors: No plan found in TAP output<br/>Files=3, Tests=20, 1 wallclock secs ( 0.02 usr 0.01 sys + 0.07 cusr 0.03 csys = 0.13 CPU)<br/>Result: FAIL<br/>Failed 1/3 test programs. 0/20 subtests failed.<br/>make: The error code from the last command is 2.<br/><br/><br/>Stop.<br/><br/>I have searched in the code for file &quot;Tiny.pm&quot; not found it. Please help me to fix this issue.<br/><br/>Thanks &amp; Regards,<br/><br/>Ramakrishna Jillapelli,<br/>Global Services, Operations and Engineering,<br/><br/>XEROX Business Services,<br/>9th Floor, Explorer Block, White Field Road, ITPL,<br/>Bangalore - 560066, India.<br/><br/>E-Mail: Ramakrishna.Jillapelli@xerox.com&lt;mailto:Ramakrishna.Jillapelli@xerox.com&gt;,<br/>Ph: +1-214-530-2222, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36912.html Tue, 18 Mar 2014 20:32:54 +0000 RE: perl DBI errors by Curtis Leach Sorry to say, but you are into a mini-project to get things working again. From past experience, IBM tends to make a minimalistic version of Perl available to you by default with AIX. So your original error messages were telling you that the modules your program requires are not part of the IBM&#39;s standard Perl package. Also the AIX perl packages tends to be fairly old.<br/><br/>First of all, I strongly recommend that you don&#39;t copy any more files from under the Perl 5.8.8 tree into your Perl 5.10.1 tree. You copy the wrong one and you may start getting really strange errors that no one will be able to help you resolve. So if you still have a list of those modules you did this for, I&#39;d recommend removing what you manually copied over and reinstalling them the correct way. (It may be too late already &amp; you may have to completely remove it &amp; reinstall Perl to fix things. Sometimes multiple modules are installed in the same directory. But let&#39;s assume for now that things are still OK after you remove things. That you didn&#39;t overwrite anything important.)<br/><br/>Second there may be a short cut you can take. If your previous version of Perl is still installed after your upgrade, you can downgrade back down to Perl 5.8.8 by updating a some symbolic links. If the original Perl was removed as part of your upgrade, you&#39;re out of luck there. The only reason I mention this option is you said you copied files between releases. And if it was from the same machine, this is doable. But this requires a Unix Admin to update about 31 different Symbolic links in the /usr/bin directory. If IBM provided a script to do this, I don&#39;t know what it is.<br/><br/>Now onto fixing Perl 5.10.1.<br/><br/>You can tell what version a module is at by running the following command:<br/>perl -we &#39;use modulename 999;&#39;<br/><br/>It will tell you either the module is not installed, or it will tell you what version the module is currently at. So for example:<br/> perl -we &#39;use Net::FTP 999;&#39;<br/> Net::FTP version 999 required--this is only version 2.75 at -e line 1.<br/> BEGIN failed--compilation aborted at -e line 1.<br/><br/>NOTE: To install some Perl modules, like DBI, you will need IBM&#39;s C/C++ compiler, which costs $$$. If you end up having to go with the free GCC compiler be warned that you may have to recompile Perl itself and start from scratch. Using different C compilers for compiling Perl &amp; it&#39;s modules is known to cause issues. So the instructions below assume you have IBM&#39;s C/C++ compiler already available.<br/><br/>Install Perl Modules:<br/><br/>1) Download the missing modules &amp; their dependencies from CPAN. http://search.cpan.org/ This link will allow you to search for the modules you need to download.<br/><br/>2) Extract the compressed tar file into a work directory.<br/><br/>3) Read the README file, it will tell you if there is anything special required for building the module. But in general it&#39;s the following 4 steps:<br/><br/>a) perl Makefile.PL<br/><br/>b) make<br/><br/>c) make test<br/><br/>d) make install<br/><br/>A couple of things to watch out for that can cause you headaches.<br/><br/>1) You must do steps 3c &amp; 3d as root. (or whatever user Perl was installed under) It&#39;s OK to do all steps as root if you wish.<br/><br/>2) When you 1st login as root, check your umask settings. If it doesn&#39;t say 022, run &quot;umask 022&quot;. A common problem is someone forgets to do this and after the successful install, no other user can use the module.<br/><br/>3) Do not ignore any errors reported by step 3c, it&#39;s OK for it to skip tests, but NOT OK if it says it has problems.<br/><br/>4) For step 3a, read any messages about dependencies carefully. Some of the modules it lists are optional, while others are really required. Sometimes a module is already installed, but it&#39;s at an incompatible version &amp; needs to be upgraded before you can install the one you are working on. If you&#39;re not careful here, you could end up installing way more modules than you really need to.<br/><br/>As a final note, if you are doing this for multiple machines, you can take a short cut on the next AIX box by taring up all your work directory and copying it between machines. So on the other AIX boxes all you would have to do is steps 3c &amp; 3d. This helps greatly if a C/C++ compiler is needed. Since then you&#39;ll only need the compiler on your development box. But be careful that all dependency software was installed in the same location on all servers and install the perl modules in the same order you did for the original AIX box. So keep good notes!<br/><br/>Good luck :)<br/><br/>Curtis<br/><br/>From: Jillapelli, Ramakrishna [mailto:Ramakrishna.Jillapelli@xerox.com]<br/>Sent: Friday, March 07, 2014 6:49 AM<br/>To: dbi-users@perl.org<br/>Subject: Reg: perl DBI errors<br/><br/>Hi,<br/><br/>Recently AIX 6.x is upgraded to AIX 7.1 on our servers.<br/>That upgraded automatically Perl version to 5.10.1.<br/><br/>There are lot of perl and shell scripts on our servers.<br/>After upgrading most of the perl scripts failing.<br/><br/>Errors:<br/><br/>1) Can&#39;t locate loadable object for module DBI in @INC (@INC contains: /usr/opt/perl5/lib/5.10.1/aix-thread-multi /usr/opt/perl5/lib/5.10.1<br/><br/>2)<br/>/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi /usr/opt/perl5/lib/site_perl/5.10.1 .) at /usr/opt/perl5/lib/5.10.1/aix-thread-multi/DBI.pm line 265<br/>BEGIN failed--compilation aborted at /usr/opt/perl5/lib/5.10.1/aix-thread-multi/DBI.pm line 265.<br/>Compilation failed in require at /tivoli/MWV/scripts/EventsByClass.pl line 31.<br/>BEGIN failed--compilation aborted at /tivoli/MWV/scripts/EventsByClass.pl line 31.<br/><br/><br/>3) Can&#39;t locate Date/Pcalc.pm in @INC (@INC contains: /usr/opt/perl5/lib/5.10.1/aix-thread-multi /usr/opt/perl5/lib/5.10.1<br/><br/>4)<br/>/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi /usr/opt/perl5/lib/site_perl/5.10.1 .) at netview_update.pl line 18.<br/>BEGIN failed--compilation aborted at netview_update.pl line 18.<br/><br/>Error 2, I fixed by copying the &quot;Date&quot; dir from old perl version 5.8.8<br/>cp -R /usr/opt/perl5/lib/site_perl/5.8.8/aix-thread-multi/Date /usr/opt/perl5/lib/5.10.1/aix-thread-multi/<br/><br/>Similarly I copied DBI, DBD dirs. For fixing error 1, not worked.<br/><br/>Why we are not getting *.pm files automatically.<br/>Do we need to separately install all required libraries (functions)?<br/><br/>Our perl scripts using the following functions:<br/>Date::Pcalc qw(:all)<br/>Net::FTP<br/>File::Copy<br/>DBI::<br/>LWP::UserAgent<br/>HTTP::Request::Common qw(POST)<br/>Net::Ping<br/>Getopt::Std<br/>Time::Local<br/><br/>I am not sure what all we missed *.pm files in the latest perl 5.10.1.<br/><br/>Please guide me how to install *.pm files (DBI, Date,...) in latest version.<br/><br/>Thanks &amp; Regards,<br/><br/>Ramakrishna Jillapelli,<br/>Global Services, Operations and Engineering,<br/><br/>XEROX Business Services,<br/>9th Floor, Explorer Block, White Field Road, ITPL,<br/>Bangalore - 560066, India.<br/><br/>E-Mail: Ramakrishna.Jillapelli@xerox.com&lt;mailto:Ramakrishna.Jillapelli@xerox.com&gt;,<br/>Ph: +1-214-530-2222, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36911.html Wed, 12 Mar 2014 00:33:12 +0000 Reg: perl DBI errors by Jillapelli, Ramakrishna Hi,<br/><br/>Recently AIX 6.x is upgraded to AIX 7.1 on our servers.<br/>That upgraded automatically Perl version to 5.10.1.<br/><br/>There are lot of perl and shell scripts on our servers.<br/>After upgrading most of the perl scripts failing.<br/><br/>Errors:<br/><br/>1) Can&#39;t locate loadable object for module DBI in @INC (@INC contains: /usr/opt/perl5/lib/5.10.1/aix-thread-multi /usr/opt/perl5/lib/5.10.1<br/><br/>1)<br/>/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi /usr/opt/perl5/lib/site_perl/5.10.1 .) at /usr/opt/perl5/lib/5.10.1/aix-thread-multi/DBI.pm line 265<br/>BEGIN failed--compilation aborted at /usr/opt/perl5/lib/5.10.1/aix-thread-multi/DBI.pm line 265.<br/>Compilation failed in require at /tivoli/MWV/scripts/EventsByClass.pl line 31.<br/>BEGIN failed--compilation aborted at /tivoli/MWV/scripts/EventsByClass.pl line 31.<br/><br/><br/>2) Can&#39;t locate Date/Pcalc.pm in @INC (@INC contains: /usr/opt/perl5/lib/5.10.1/aix-thread-multi /usr/opt/perl5/lib/5.10.1<br/><br/>2)<br/>/usr/opt/perl5/lib/site_perl/5.10.1/aix-thread-multi /usr/opt/perl5/lib/site_perl/5.10.1 .) at netview_update.pl line 18.<br/>BEGIN failed--compilation aborted at netview_update.pl line 18.<br/><br/>Error 2, I fixed by copying the &quot;Date&quot; dir from old perl version 5.8.8<br/>cp -R /usr/opt/perl5/lib/site_perl/5.8.8/aix-thread-multi/Date /usr/opt/perl5/lib/5.10.1/aix-thread-multi/<br/><br/>Similarly I copied DBI, DBD dirs. For fixing error 1, not worked.<br/><br/>Why we are not getting *.pm files automatically.<br/>Do we need to separately install all required libraries (functions)?<br/><br/>Our perl scripts using the following functions:<br/>Date::Pcalc qw(:all)<br/>Net::FTP<br/>File::Copy<br/>DBI::<br/>LWP::UserAgent<br/>HTTP::Request::Common qw(POST)<br/>Net::Ping<br/>Getopt::Std<br/>Time::Local<br/><br/>I am not sure what all we missed *.pm files in the latest perl 5.10.1.<br/><br/>Please guide me how to install *.pm files (DBI, Date,...) in latest version.<br/><br/>Thanks &amp; Regards,<br/><br/>Ramakrishna Jillapelli,<br/>Global Services, Operations and Engineering,<br/><br/>XEROX Business Services,<br/>9th Floor, Explorer Block, White Field Road, ITPL,<br/>Bangalore - 560066, India.<br/><br/>E-Mail: Ramakrishna.Jillapelli@xerox.com&lt;mailto:Ramakrishna.Jillapelli@xerox.com&gt;,<br/>Ph: +1-214-530-2222, Ext 3208, Mob: +91-9008177255 (Off), +91-9880678154 (Per).<br/><br/><br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36910.html Mon, 10 Mar 2014 15:45:00 +0000 Re: DSN retrievable from DBI? by Ron Savage Hi Vincent<br/><br/>On 07/03/14 21:17, Vincent Veyron wrote:<br/>&gt; On Fri, 07 Mar 2014 17:57:26 +1100<br/>&gt; Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/>&gt;<br/>&gt;&gt;<br/>&gt;&gt; Is it possible to get back from DBI, or (preferably) $dbh, the DSN used<br/>&gt;&gt; in the call to connect?<br/>&gt;&gt;<br/>&gt;<br/>&gt; You can retrieve the db and username with this :<br/>&gt;<br/>&gt; http://search.cpan.org/dist/DBI/DBI.pm#Database_Handle_Attributes<br/><br/>Yes, that gives me Username, and uc $username gives me the Oracle <br/>schema, as I understand it.<br/><br/>$many x $thanx;<br/><br/><br/>-- <br/>Ron Savage<br/>savage.net.au<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36909.html Fri, 07 Mar 2014 21:43:41 +0000 Re: DSN retrievable from DBI? by Vincent Veyron On Fri, 07 Mar 2014 17:57:26 +1100<br/>Ron Savage &lt;ron@savage.net.au&gt; wrote:<br/><br/>&gt; <br/>&gt; Is it possible to get back from DBI, or (preferably) $dbh, the DSN used <br/>&gt; in the call to connect?<br/>&gt; <br/><br/>You can retrieve the db and username with this :<br/><br/>http://search.cpan.org/dist/DBI/DBI.pm#Database_Handle_Attributes<br/><br/>-- <br/> Regards, Vincent Veyron <br/><br/>http://libremen.com/ <br/>Legal case, contract and insurance claim management software<br/> http://www.nntp.perl.org/group/perl.dbi.users/2014/03/msg36908.html Fri, 07 Mar 2014 10:17:33 +0000