Re: make error- ld: Unrecognized argument: -Wl,+b...
\ +Z -I/opt/perl_64/lib/5. 8.8/IA64.ARCHREV_0-thread-multi-LP64/CORE -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_ OCI_VERSION=\10.2.0.3\ dbdimp.c dbdimp.c, line 82: warning #2236-D: controlling expression is constant OCIErrorGet_log_stat(errhp, recno, (text*)NULL, eg_errcode, errbuf, ^ dbdimp.c, line 281: warning #4275-D: constant out of range ([0 - 4294967295] ) for the operator Newz(42, fb_ary-aindp, (unsigned)size,sb2); ^ dbdimp.c, line 282: warning #4275-D: constant out of range ([0 - 4294967295] ) for the operator Newz(42, fb_ary-arlen, (unsigned)size,ub2); ^ dbdimp.c, line 283: warning #4275-D: constant out of range ([0 - 4294967295] ) for the operator Newz(42, fb_ary-arcode, (unsigned)size,ub2); ^ cc -c -I/usr/oracle/client/10.2/rdbms/public -I/usr/oracle/client/10.2/ rdbms/demo -I/usr/oracle/client/10.2/rdbms/public -I/usr/oracle/client/10.2/plsq l/public -I/usr/oracle/client/10.2/network/public -I/opt/perl_64/lib/site_perl/5 .8.8/IA64.ARCHREV_0-thread-multi-LP64/auto/DBI -D_POSIX_C_SOURCE=199506L -D_REE NTRANT -Ae -D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 +Z -DUSE_SITECUSTOMIZE -D NO_HASH_SEED -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fast +DSitanium2 +Oflta cc=strict-DVERSION=\1.20\ -DXS_VERSION=\1.20\ +Z -I/opt/perl_64/lib/5. 8.8/IA64.ARCHREV_0-thread-multi-LP64/CORE -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_ OCI_VERSION=\10.2.0.3\ oci8.c oci8.c, line 137: warning #2236-D: controlling expression is constant OCIErrorGet_log_stat(errhp, recno, (text*)NULL, eg_errcode, errbuf, ^ oci8.c, line 1330: warning #2167-D: argument of type ub4 * is incompatible with parameter of type size_t * str_len, ^ oci8.c, line 1359: warning #2181-D: argument is incompatible with corresponding format string conversion sprintf(s_tz_hour, %03ld,tz_hour); ^ oci8.c, line 1361: warning #2181-D: argument is incompatible with corresponding format string conversion sprintf(s_tz_hour, %02ld,tz_hour); ^ oci8.c, line 1364: warning #2181-D: argument is incompatible with corresponding format string conversion sprintf(s_tz_min,:%02ld,tz_minute); ^ oci8.c, line 1365: warning #4212-D: mismatch between character pointer types text * and char * strcat(str_buf,s_tz_hour); ^ oci8.c, line 1366: warning #4212-D: mismatch between character pointer types text * and char * strcat(str_buf, s_tz_min); ^ oci8.c, line 916: warning #4275-D: constant out of range ([0 - 4294967295]) for the operator New(42, buffer, buflen, ub1); ^ oci8.c, line 1821: warning #4275-D: constant out of range ([0 - 4294967295]) for the operator Newz(1, obj-fields, (unsigned) obj-field_count, fbh_obj_t); ^ oci8.c, line 2021: warning #4275-D: constant out of range ([0 - 4294967295]) for the operator Newz(42, imp_sth-fbh, num_fields, imp_fbh_t); ^ Running Mkbootstrap for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.so /usr/bin/ld -Wl,+b/usr/oracle/client/10.2/lib:/usr/oracle/client/10.2/r dbms/lib -b +vnocompatwarnings -L/usr/lib/hpux64 Oracle.o dbdimp.o oci8.o -L /usr/oracle/client/10.2/rdbms/lib/ -L/usr/oracle/client/10.2/lib/ -lclntsh `c at /usr/oracle/client/10.2/lib/ldflags` -lm -lpthread -o blib/arch/auto/DBD /Oracle/Oracle.so \ \ ld: Unrecognized argument: -Wl,+b/usr/oracle/client/10.2/lib:/usr/oracle/client/10.2/rdbms/lib Fatal error. *** Error exit code 1 Stop. - -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBD::Sybase context allocation routine failed
On Feb 12, 2008 3:26 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: attempting a DB connection using a brand new installation of perl 5.8.8 on an old sun box: 'sun4u sparc SUNW,Ultra-4'. i have connectivity. this command line script returns a reference to a hash: perl -MDBI -e 'print DBI- connect(DBI:Sybase:server=,user,password)' but when i attempt to run this stub script: #!/usr/local/bin/perl5.8.8 use strict; use CGI qw(:standard); use DBI; use DBD::Sybase; I get this error: The context allocation routine failed. The following problem caused the failure: Invalid context version. Content-Type: text/html; charset=ISO-8859-1 I don't get the error it if I comment out the DBD::Sybase statement Any help is much appreciated. Why do you want to 'use DBD::Sybase' given that the working example shows that it is not necessary to do so? If you were importing some specific symbols from DBD::Sybase, it would make sense - but you aren't self-evidently doing that, so it doesn't make much sense. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: To remove from mailing list
From the email headers of your message List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Id: dbi-users.perl.org On Feb 5, 2008 6:53 AM, Ammayappa SELVAKUMAR [EMAIL PROTECTED] wrote: Hello, Anyone tell me how to remove my mail id from mailing list Regards Selva -Original Message- From: Jared Still [mailto:[EMAIL PROTECTED] Sent: 05 February 2008 15:46 To: Mohammed, Shafi Cc: dbi-users@perl.org Subject: Re: DBD::ORACLE INSTALLATION ERROR On Mon, 2008-02-04 at 16:52 +0530, Mohammed, Shafi wrote: Hello, I am trying to install DBD::oracle package in my machine. Version? Please tell me how to resolve this issue. I know nothing about hpux, do have extensive experience perusing documentation. A good start would be to read the extensive instructions in README.hpux.txt. (perldoc README.hpux.txt) Jared -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Find current database name from db handle
On Feb 4, 2008 6:23 AM, Kostas Chatzikokolakis [EMAIL PROTECTED] wrote: I'm using a dbi handle that is shared between many packages in my code. Some package might do a USE db_name to change the current database of the connection. Can I retrieve the current database name from the handle, either from DBI or from the DBD::mysql driver (without querying the server)? What's wrong with 'perldoc DBI'? What's the name attribute of a database handle documented as doing? Does it not work for you? This was a bit churlish of me, but may I recommend reading http://www.catb.org/~esr/faqs/smart-questions.html which advises you on how to ask questions without incurring such ... ire. Hello Jonathan, thanks for your reply. From perldoc: Name [...] Usually (and recommended to be) the same as the dbi:DriverName:... string used to connect to the database, but with the leading dbi:DriverName: removed. So Name returns the dsn used to connect, it is not meant to be the current database (it's not updated when changing database by doing USE db-name). I want something that is dynamic, similar to doing a SELECT DATABASE() query in mysql, but without doing an actual query. Sorry if I wasn't clear enough in my previous mail. OK - fair enough. With DBD::Informix the Name is the 'DSN' supplied at connection time. There's a separate ix_Database attribute (in the private namespace) that gives the current database name. If you can change databases while a connection is in progress, Name is unreliable (that's the case on DBD::Informix, though it takes some care to make a connection changeable). But I think you are dependent on driver properties -- different drivers do it differently. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Find current database name from db handle
On Feb 3, 2008 11:47 AM, Kostas Chatzikokolakis [EMAIL PROTECTED] wrote: I'm using a dbi handle that is shared between many packages in my code. Some package might do a USE db_name to change the current database of the connection. Can I retrieve the current database name from the handle, either from DBI or from the DBD::mysql driver (without querying the server)? What's wrong with 'perldoc DBI'? What's the name attribute of a database handle documented as doing? Does it not work for you? And please don't double post without waiting for an answer or explaining your double post. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Any news on CPAN bug 32309 in DBI - faulty definition of DBIS for big-endian 64-bit machines with MULTIPLICITY
CPAN Bug 32309 was created recently, but I'm told that the underlying problems was first reported in 2003 (though I only see DBI bugs dating back 4 years or so, so I can believe that the original bug report has now been lost). The new bug entry includes a plausible solution (albeit not as a patch file, but it is a one-line change). http://rt.cpan.org/Public/Bug/Display.html?id=32309 It does not appear to have been fixed in DBI 1.601. The problem appears not to affect most people - it requires a big-endian machine (such as IBM PowerPC) running in 64-bit mode[*] where 'sizeof(int) != sizeof(void *)' with MULTIPLICITY (or PERL_OBJECT or PERL_CAPI if I'm reading DBIXS.hcorrectly) set. Is there a reason why this cannot be fixed - or should not be fixed? Colleagues of mine in India have asked about this. Is there a timeline I can offer them for when this might be fixed in a general release of DBI? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused. [*] 64-bit mode: or it might be on a 32-bit machine with 16-bit ints, I suppose, but that's not a plausible choice these days.
Re: DBI-DBD::ORACLE EROR
On Jan 29, 2008 5:31 AM, Mohammed, Shafi [EMAIL PROTECTED] wrote: I need following files. As has already been explained to you -- you need to get those files from a legitimate source, namely Oracle, or your authorized Oracle supplier. Nothing else will work; no-one who respects the law will help you other than by telling you to get them from Oracle. Please wake up, read the messages, and act on them. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Using q() to define a query
On Jan 10, 2008 7:59 PM, Colin Wetherbee [EMAIL PROTECTED] wrote:
Greetings.
I have a DBI (DBD::Pg) application I'm building in mod_perl. My queries
tend to look something like the following.
my $sql = q(SELECT departure_date, eq.name AS equipment,
dp.full_city AS departure_city, ap.full_city AS arrival_city,
ca.name AS carrier_name, number
FROM jsjourneys
FULL OUTER JOIN jscarriers AS ca ON jsjourneys.carrier = ca.id
FULL OUTER JOIN jsequipment AS eq ON jsjourneys.equipment = eq.id
JOIN jsports AS dp ON jsjourneys.departure_port = dp.id
JOIN jsports AS ap ON jsjourneys.arrival_port = ap.id
ORDER BY departure_date);
And, then, I execute them as follows.
$dbh-selectall_arrayref($sql, { Slice = {} });
Which works quite well.
However, I'm concerned about $sql because when I output it to Apache's
debug log, it looks like this:
[Fri Jan 11 03:49:09 2008] [debug] Log.pm(36): [client 192.168.171.80]
[JetSet] SELECT departure_date, eq.name AS equipment,\n
dp.full_city AS departure_city, ap.full_city AS arrival_city,\n
ca.name AS carrier_name, number\n FROM jsjourneys\n FULL OUTER
JOIN jscarriers AS ca ON jsjourneys.carrier = ca.id\n FULL OUTER
JOIN jsequipment AS eq ON jsjourneys.equipment = eq.id\n JOIN
jsports AS dp ON jsjourneys.departure_port = dp.id\n JOIN jsports
AS ap ON jsjourneys.arrival_port = ap.id\n ORDER BY departure_date
Notice the newline characters in there. If those were really in the
query, I can't imagine the database would run it, so I suppose they're
an artifact of the combination of using q() to quote my query and using
Apache's logger to output it.
If you're referring to the newlines in the $sql string - I'd be astonished
if the DBMS did not handle them OK. If you're referring to the \n notation
in the log output, I'd assume those are interpolated by the Apache logging
module.
All this leads up to a pretty simple question: is using q() to quote my
queries a bad thing, and/or will it cause trouble in the future?
It's fine...
(As an aside, how do you guys quote your queries? I find that for
anything longer than about 60 characters, q() and '' and everything else
start to look horribly inelegant.)
q{}; q%%; q[];
On occasion, I've done evil things like q and qq'' -- it seemed like a
good idea at the time.
Thanks.
Colin
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Perl DBI::prepare Question. My head is sore from banging it against the wall. Can you help ease my pain?
There's no solution to your problem below - there is some commentary that
may, or may not, be of relevance.
On Nov 29, 2007 8:06 AM, BAIER, ANTHONY (TONY), ATTSI [EMAIL PROTECTED]
wrote:
Can you take a quick look at the code block below and error messages
being generated when executing.
Any idea why the last 2 characters of the $sql variable are getting
chopped off when prepare is executed?
How do I prevent the program from termininating and letting me handle
the error handling? I tried the following DBI::CONNECT statement put
it did not help.
my $dbh = DBI-connect($data_source, $dbUser, $dbPassword, {
PrintError=0, RaiseError=0, AutoCommit=0 });
If you are going to have DBI not act on errors, you must do the error
checking yourself.
If you are debugging a problem, use PrintError = 1 and/or RaiseError = 1.
Code Block in Error:
$sql = insert into
odba_user.dbh_high_memory_read_sqls
(report_id, query_no,buffer_gets,
no_executions, sql_text)
values
($reportId, $queryNumber,
$readCount,
$execCount, '$queryText');
This is a bad way of processing input data with SQL -- you are setting
yourself up for an SQL injection attack.
For a wonderful, comical demonstration of an SQL injection attack, see:
http://xkcd.com/327/
Use placeholders - or, learn about $dbh-quote.
print \n\nflag11a sql [$sql]\n\n;
$sth = $dbh-prepare($sql);
No error check?
undef $rc;
$rc = $sth-execute();
An odd way of doing business...
unless (defined $rc) {
printf LOGFILE statement
execution failed:\n\$sql\\n$DBI::errstr\n;
# ignore these insert errors
# $errorCode = 1;
print flag11\n;
}
My Print Statement of $sql
flag11a sql [insert into odba_user.dbh_high_memory_read_sqls
(report_id, query_no, buffer_gets,
no_executions, sql_text)
values
(570, 8, 620184,
206727, 'select job,
nvl2(last_date, 1,
0) from sys.job$ where (((:1 = next_date) and (next_date = :2)) or
((last_date
is null) and (next_date :3))) and (field1 = :4 or (field1 = 0 and
''Y'' = :5)
) and (this_date is null) order by next_date, job')]
This looks correct - is there a problem here?
Perl DBI::PrintError Results (where is the trailing single quote ')
DBD::Oracle::db prepare failed: ORA-01756: quoted string not properly
terminated
(DBD ERROR: OCIStmtPrepare) [for Statement insert into
odba_user.dbh_high_mem
ory_read_sqls
(report_id, query_no, buffer_gets,
no_executions, sql_text)
values
(570, 8, 620184,
206727, 'select job,
nvl2(last_date, 1,
0) from sys.job$ where (((:1 = next_date) and (next_date = :2)) or
((last_date
is null) and (next_date :3))) and (field1 = :4 or (field1 = 0 and
''Y'' = :5)
) and (this_date is null) order by next_date, job at
../../bin/DBhealthParseDB.p
l line 653, REPORTFILE line 319.
This I agree seems to be missing some data - two characters as you say. You
are fortunate that your SQL does not contain any single quotes, of course --
that's the SQL injection issue above.
Can't call method execute on an undefined value at
../../bin/DBhealthParseDB.
l line 655, REPORTFILE line 319.
This is because you ignored the error from prepare and blithely tried to use
the $sth that wasn't available.
Issuing rollback() for database handle being DESTROY'd without explicit
disconn
ct(), REPORTFILE line 319.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: DBI install error under Solaris 10
On Nov 14, 2007 10:11 AM, zilonx [EMAIL PROTECTED] wrote: I need to install the DBD::Pg under Solaris 10 sparc, the DBI::DBD installed without errors with CPAN, but when trying to install DBI I get the following error: Can't create variants of tests in 't' directory: No such file or directory at /usr/perl5/site_perl/5.8.4/sun4-solaris-64int/DBI/DBD.pm line 3119. This is the exact same error with Sun Studio or GCC 3.4.6 - I'm not sure if this is the correct location to ask for help. Normally, I would have expected DBI::DBD (which is basically a POD for developers of DBD modules) to come along with DBI. The Can't create message suggests that you are trying to build in a directory where you don't have a sub-directory called 't', which in turn suggests that your current directory is not where the DBI source code is. It is good that you have both Sun Studio and GCC available; the build will use the same one as was used to build Perl. That should save you angst later. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: not able to install DBI Module
On 11/2/07, Sreedhar Gundreddy [EMAIL PROTECTED] wrote: I am not able to install Perl DBI module #perl Makefile.PL has displayed this output [...] Writing Makefile for DBI # make output gcc -c -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DNO_HASH_SEED -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\1.601\ -DXS_VERSION=\1.601\ -fPIC -I/usr/local/lib/perl5/site_perl/lib/5.8.3/sun4-solaris-thread-multi/CORE -W -Wall -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual Perl.c *** Error code 1 Please suggest the solution for the above problem Have you been able to compile other modules, or is DBI the first module you're trying to install. It is odd that there is no error message from the compiler - but it appears that the compilation failed. Do you have gcc installed? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Fwd: DBI install error,can you help me?
Please use the mailing lists for support. Are you sure the compiler you have is the one used to build Perl? -- Forwarded message -- From: tedabc [EMAIL PROTECTED] Date: Oct 30, 2007 5:12 AM Subject: DBI install error,can you help me? To: [EMAIL PROTECTED] [EMAIL PROTECTED] Hello Jonathan Leffler I try to install the DBI package but it failed. Can you please help? thanks. My os is HP-UX 11.23,perl version 5.8.8. --- 1、perl Makefile.PL Set up gcc environment - 4.2.1 *** You are using a perl configured with threading enabled. *** You should be aware that using multiple threads is *** not recommended for production environments. *** Note: The optional PlRPC-modules (RPC::PlServer etc) are not installed. If you want to use the DBD::Proxy driver and DBI::ProxyServer modules, then you'll need to install the RPC::PlServer, RPC::PlClient, Storable and Net::Daemon modules. The CPAN Bundle::DBI may help you. You can install them any time after installing the DBI. You do *not* need these modules for typical DBI usage. Optional modules are available from any CPAN mirror, in particular http://search.cpan.org/ http://www.perl.com/CPAN/modules/by-module http://www.perl.org/CPAN/modules/by-module ftp://ftp.funet.fi/pub/languages/perl/CPAN/modules/by-module Your perl was compiled with gcc (version 4.2.1), okay. Creating test wrappers for DBI::PurePerl: t/zvp_01basics.t ... t/zvxgp_87gofer_cache.t Warning: By default new modules are installed into your 'site_lib' directories. Since site_lib directories come after the normal library directories you must delete old DBI files and directories from your 'privlib' and 'archlib' directories and their auto subdirectories. Reinstall DBI and your DBD::* drivers after deleting the old directories. Here's a list of probable old files and directories: /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/DBD I see you're using perl 5.008008 on PA-RISC1.1-thread-multi, okay. Remember to actually *read* the README file! Use 'make' to build the software (dmake or nmake on Windows). Then 'make test' to execute self tests. Then 'make install' to install the DBI and then delete this working directory before unpacking and building any DBD::* drivers. Writing Makefile for DBI 2、make gcc -c -D_POSIX_C_SOURCE=199506L -D_REENTRANT -D_HPUX_SOURCE -fPIC -D USE_SITECUSTOMIZE -DNO_HASH_SEED -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno -strict-aliasing -pipe -DVERSION=\1.601\ -DXS_VERSION=\1.601\ -fPIC -I /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE -W -Wall -Wpointer-arith - Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual -Wmissing-noret urn -Wno-unused-parameter Perl.c In file included from /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/iperls ys.h:51, from /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/perl.h :2733, from DBIXS.h:19, from Perl.xs:6: /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/perlio.h:229: error: expecte d declaration specifiers or '...' before '*' token /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/perlio.h:232: warning: type defaults to 'int' in declaration of 'PerlIO_open' /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/perlio.h:236: error: expecte d declaration specifiers or '...' before '*' token ... ... In file included from /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/perl.h :2747, from DBIXS.h:19, from Perl.xs:6: /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/sv.h:377: error: expected sp ecifier-qualifier-list before '*' token In file included from /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/perl.h :3884, from DBIXS.h:19, from Perl.xs:6: /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/intrpvar.h:204: error: expec ted specifier-qualifier-list before '*' token In file included from /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/perl.h :3951, from DBIXS.h:19, from Perl.xs:6: /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:201: error: expected declaration specifiers or '...' before '*' token /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:265: error: expected declaration specifiers or '...' before '*' token ... ... multi/CORE/proto.h:2018: warning: data definition has no type or storage class /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:2018: warning: type defaults to 'int' in declaration of 'Perl_PerlIO_stdin' /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:2021: warning: data definition has no type or storage class /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:2021: warning: type defaults to 'int' in declaration of 'Perl_PerlIO_stdout' /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:2024: warning: data definition has no type or storage class /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:2024: warning: type defaults to 'int' in declaration of 'Perl_PerlIO_stderr' /opt/perl_32/lib/5.8.8/PA-RISC1.1-thread-multi/CORE/proto.h:2046: error: expecte d
Re: Issue with perl, DBD::Oracle, Solaris 10
On 10/28/07, Nicholas Veeser [EMAIL PROTECTED] wrote: First, is this the right place to ask questions about compiling DBD::Oracle? Strictly no -- it should be in [EMAIL PROTECTED] I am having trouble building with DBD-Oracle 1.19 Against the stock perl in Solaris 10, I get an error that looks like this: -- LD_RUN_PATH=/oracle/product/9.2.0.7/lib32:/oracle/product/9.2.0.7/rdbms/lib32 cc -G Oracle.o dbdimp.o oci8.o cc -Xa -xstrconst -xF-xarch=v8 -xchip=ultra -W2,-AKNR_S -W2,-Rglobal_hoist -Wc,-Qdelay-speculate -Wc,-Qdepgraph-safe_spec_load=3 -W2,-Rloop -errtags=yes -v -K PIC -L/opt/SUNWcluster/lib -R/opt/SUNWcluster/lib -L/oracle/product/9.2.0.7/rdbms/lib32/ -L/oracle/product/9.2.0.7/lib32/-lclntsh `cat /oracle/product/9.2.0.7/lib32/ldflags` `cat /oracle/product/9.2.0.7/lib32/sysliblist` -R/oracle/product/9.2.0.7/lib32 -laio -lposix4 -lkstat -lm -lthread -o blib/arch/auto/DBD/Oracle/Oracle.so ld: fatal: file cc: open failed: No such file or directory ld: fatal: File processing errors. No output written to blib/arch/auto/DBD/Oracle/Oracle.so *** Error code 1 make: Fatal error: Command failed for target `blib/arch/auto/DBD/Oracle/Oracle.so' --- So it seems that the perl Makefile.PL is putting cc on the ld commandline and ld is trying to open cc. That seems odd. Did you build this Perl? Do you have a Sun C compiler on the machine? Building shared objects with the C compiler is common practice many places and standard practice on Solaris. The most usual problems people have is that they do not have a Sun C compiler on the machine at all, or they only have /usr/ucb/cc (which is found but doesn't compile anything). The fix is to get the Sun C compiler -- or rebuild Perl with GCC (and have GCC on the machine), or obtain a Perl build with GCC. It shows up in OTHERLDFLAGS. So when I edit the Makefile that is created to just remove cc, everything works fine. See: http://groups.google.com/group/perl.dbi.users/browse_frm/thread/d1eb4267a3721668/70f75626c884f609?lnk=stq=ld%3A+fatal%3A+file+cc%3A+open+failed%3A+No+such+file+or+directory#70f75626c884f609 Anyone know the Makefile.PL well enough to say why cc ends up in the OTHERLDFLAGS, since its not a flag? Is there something I should add to the commandline of Makefile.PL when I run it? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Repost from CPAN DBD::ORacle forum
On 10/10/07, John Scoles [EMAIL PROTECTED] wrote:
Hi. Sorry if this turns out to be a newbie mistake, but I've run into an
odd
problem while using DBD::Oracle.
For some reason, my sql statement results in empty strings.
[...snip...]
This is the result with the empty strings when using DBD::Oracle :
main::(db1.pl:47):
my $result = $sth-dump_results; DB1 '', '', '', '', '', '' '', '', '',
'',
'', '' '', '', '', '', '', '' '', '', '', '', '', '' '', '', '', '', '',
''
5 rows
SQL this is the code i'm using :
#!/usr/bin/perl use DBI;
#!/usr/bin/perl -w
use strict;
You could waste the one argument you're allowed on -MDBI to load the DBI
module.
use DBD::Oracle;
If it is working at all, I assume the 'use DBI' on the #! line 'works'; you
should be using:
use DBI;
here instead.
$ENV{'LD_LIBRARY_PATH'} =
'/home/httpd/perl/instantclient_11_1/';
[...11 comments omitted..]
$ENV{NLS_LANG} = 'american_america.we8iso8859p1';
my $host=
my $sid=
my $port=
my $user =
my $passwd =
I assume there's a bunch of initializers not shown...
my $dbh = DBIconnect(dbi:Oracle:host=$host;port=$port;sid=$sid, $user,
$passwd) or die Unable to connect: $DBI::errstr;
There's a typo above: DBI-connect
my $statement = 'SELECT * FROM table';
$sth = $dbh-prepare($statement);
There's no evidence here of checking whether the prepare succeeded.
$sth-execute;
There's no evidence here of checking whether the execute succeeded.
my $result = $sth-dump_results;
There's evidence here that some error checking earlier might help.
Put { RaiseError = 1 } as the 4th argument to your DBI-connect.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: int8 Informix and 64bit perl
On 9/27/07, Clive Eisen [EMAIL PROTECTED] wrote:
I seem to have a problem with negative int8 on a 64 bit linux platform
dbaccess gives the correct answer but DBD::Informix does not
[EMAIL PROTECTED]:~ oninit -V
IBM Informix Dynamic Server Version 10.00.FC6
[EMAIL PROTECTED]:~ esql -V
IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.FC4R1
[EMAIL PROTECTED]:~ perl -v
This is perl, v5.8.8 built for x86_64-linux
[EMAIL PROTECTED]:~ perl -MDBI -e 'print $DBI::VERSION\n'
1.53
[EMAIL PROTECTED]:~ perl -MDBD::Informix -e 'print
$DBD::Informix::VERSION\n'
2007.0914
[EMAIL PROTECTED]:~ echo 'select pings_remaining from ping_count' |
dbaccess master_118
Database selected.
pings_remaining
-256512
[EMAIL PROTECTED]:~ cat test.pl
#!/usr/local/bin/perl
use DBI;
my $database=[EMAIL PROTECTED];
my $dbh = DBI-connect(dbi:Informix:$database, '', '',
{ AutoCommit = 1, PrintError = 1
,PrintWarn = 1});
$sth=$dbh-prepare(qq(select pings_remaining from ping_count));
$sth-execute;
($pings_remaining) = $sth-fetchrow_array;
print pings_remaining = $pings_remaining\n;
[EMAIL PROTECTED]:~ perl test.pl
pings_remaining = 4294710784
Any help gratefully received
Dear Clive,
Unfortunately (for you - fortunately for me), Perl 5.8.8 with 64-bit
CSDK 3.00.FC2 on Solaris 10 correctly produces the negative answer.
That means that to some extent, the problem is platform specific.
I'll try to build DBD::Informix with CSDK 2.90.FC1 later - I have to
rig the build environment on my machine to do that. It might be CSDK
2.90 vs 3.00; it might be Linux x86 vs Solaris SPARC.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease
to be amused.
Re: int8 Informix and 64bit perl
On 9/27/07, Clive Eisen [EMAIL PROTECTED] wrote: Jonathan Leffler wrote: On 9/27/07, Clive Eisen [EMAIL PROTECTED] wrote: I seem to have a problem with negative int8 on a 64 bit linux platform dbaccess gives the correct answer but DBD::Informix does not [EMAIL PROTECTED]:~ oninit -V IBM Informix Dynamic Server Version 10.00.FC6 [EMAIL PROTECTED]:~ esql -V IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.FC4R1 [EMAIL PROTECTED]:~ perl -v This is perl, v5.8.8 built for x86_64-linux [EMAIL PROTECTED]:~ perl -MDBI -e 'print $DBI::VERSION\n' 1.53 [EMAIL PROTECTED]:~ perl -MDBD::Informix -e 'print $DBD::Informix::VERSION\n' 2007.0914 [...] Unfortunately (for you - fortunately for me), Perl 5.8.8 with 64-bit CSDK 3.00.FC2 on Solaris 10 correctly produces the negative answer. That means that to some extent, the problem is platform specific. I'll try to build DBD::Informix with CSDK 2.90.FC1 later - I have to rig the build environment on my machine to do that. It might be CSDK 2.90 vs 3.00; it might be Linux x86 vs Solaris SPARC. Rigged environment - it works correctly on Solaris under CSDK 2.90.FC1. Please can you send me 'perl -V' output - I suggest taking dbi-users off this chat until we have a resolution. FYI 32bit client using 2.90.UC4 works correctly on linux against the same DB server So it is a client-side problem - CSDK or DBD::Informix - and not a server problem. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: report (problems compiling DBD::Oracle on Solaris 10)
#30509] use encoding and eq cause memory leak 23074 Segfault using HTML::Entities 23106 Numeric comparison operators mustn't compare addresses of ... 23320 [perl #30066] Memory leak in nested shared data structures ... 23321 [perl #31459] Bug in read() SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 Built under solaris Compiled at Feb 13 2006 05:12:02 @INC: /usr/perl5/5.8.4/lib/sun4-solaris-64int /usr/perl5/5.8.4/lib /usr/perl5/site_perl/5.8.4/sun4-solaris-64int /usr/perl5/site_perl/5.8.4 /usr/perl5/site_perl /usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int /usr/perl5/vendor_perl/5.8.4 /usr/perl5/vendor_perl . /REPORT -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0904 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
ANNOUNCE: IBM Informix Database Driver for Perl DBI Version 2007.0904 (2007-09-04) released
IBM Informix Database Driver for Perl DBI Version 2007.0904 (2007-09-04) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.6.1 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.8.8 - or any later version - you should be planning to upgrade). You will need the code for DBI version 1.38 or later as well (v1.59 - or any later version - is recommended). The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at [EMAIL PROTECTED] ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2007.0904: * Bug fix and tidying up release - no new functionality. * Simplified internal release processing * Refixed support for ESQL/C 5.20. * Report server version better (using DBINFO). * Reworked some headers. * Reworked ExtUtils::AutoInstall code. Release 2007.0903: * Released without updating Announce or ChangeLog. * Will be removed from CPAN shortly. New in release 2007.0826 * Fixed support for CSDK 3.00. * Fixed support for ESQL/C 7.24 (and 5.20). * Detecting mismatched 32-bit Perl vs 64-bit ESQL/C or vice versa. * Fixed memory leak associated with LVARCHAR. * Fix problem with DBD_INFORMIX_DEBUG_ESQLCC=yes. * Fetch UDTs into SQLLVARCHAR instead of CHAR(256). * RT#14954 - only do smart blob test if smart blob space exists. * RT#14095: CLONE function added to driver 2005-08-12. * RT#13708: (LVARCHAR on 32-bit systems) fixed if you use CSDK (ESQL/C) 3.00.xC2 or later. IBM CQ bug idsdb00139040 needs to be resolved. Support email address: * This release is supported by Jonathan Leffler [EMAIL PROTECTED]. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to [EMAIL PROTECTED]; they also get sent to [EMAIL PROTECTED], etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) @(#)$Id: Announce,v 2007.7 2007/09/04 07:31:21 jleffler Exp $ -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0826 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBI::Informix and DBD::Informix
On 8/27/07, Martin Gainty [EMAIL PROTECTED] wrote: ActiveStates answer for windows is ;extension=php_ifx.dll which of course does not load and therefore doesnt work I wouldn't really expect a PHP extension to work with Perl. You shouldn't either. Havent seen anything from IBM which is disappointing since Informix is their product Fair enough - discuss with your IBM sales rep. If I get tasked with it formally, I'll do it - assuming that time is allocated too. If not, it will happen on my (non-urgent) schedule. Amongst other things, I use Cygwin on Windows - and AFAIK, CSDK does not support that (despite my putting in a request for ESQL/C to support GCC out of the box several years ago - not being a customer, I don't have much clout). So, to get things to work on Windows, I have to get a MSVC compiler that will do the job. There may be sufficiently good freebies from MS for my purposes - but it just adds to the complexity of the job. Cobbler's Children springs to mind as an epithet - so does over-worked, under-paid. From: Jonathan Leffler [EMAIL PROTECTED] On 8/27/07, Martin Gainty [EMAIL PROTECTED] wrote: Anyone know where the DBD::Informix and DBI::Informix packages are located? DBD::Informix is located on CPAN, as usual. There is no DBI::Informix package that I know of. I suspect that your question means that you are running on Windows, rather than Unix, and using ActiveState Perl, and are wanting a PPM for DBD::Informix on Windows. Sadly, I have not yet got DBD::Informix running on Windows - partly for lack of motivation, partly for lack of time. So, there is no PPM available. Various people at various times have reported various issues; due to the lack of a test environment, I've not tested it recently (meaning in the last 5+ years). Fundamentally, it hasn't been enough of an itch for me to be particularly interested in scratching it - which may or may not be wholly a good idea, but I'm only a volunteeer when it comes to doing DBD::Informix (I'm not specifically paid by IBM or anyone else to do it). I'm hoping to do some testing on Windows between now and the end of the year (hoping means that - no promises). If anyone needs it sooner than that, they'll have to provide some round tuits. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0826 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Fwd: DBI::Informix and DBD::Informix
Oops - omitted dbi-users; sorry. -- Forwarded message -- From: Jonathan Leffler [EMAIL PROTECTED] Date: Aug 27, 2007 6:43 PM Subject: Re: DBI::Informix and DBD::Informix To: Martin Gainty [EMAIL PROTECTED] On 8/27/07, Martin Gainty [EMAIL PROTECTED] wrote: Anyone know where the DBD::Informix and DBI::Informix packages are located? DBD::Informix is located on CPAN, as usual. There is no DBI::Informix package that I know of. I suspect that your question means that you are running on Windows, rather than Unix, and using ActiveState Perl, and are wanting a PPM for DBD::Informix on Windows. Sadly, I have not yet got DBD::Informix running on Windows - partly for lack of motivation, partly for lack of time. So, there is no PPM available. Various people at various times have reported various issues; due to the lack of a test environment, I've not tested it recently (meaning in the last 5+ years). Fundamentally, it hasn't been enough of an itch for me to be particularly interested in scratching it - which may or may not be wholly a good idea, but I'm only a volunteeer when it comes to doing DBD::Informix (I'm not specifically paid by IBM or anyone else to do it). I'm hoping to do some testing on Windows between now and the end of the year (hoping means that - no promises). If anyone needs it sooner than that, they'll have to provide some round tuits. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0826 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused. If you're not familiar with 'Round Tuits', Google is your friend. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0826 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
ANNOUNCE: IBM Informix Database Driver for Perl DBI Version 2007.0826 (2007-08-26) released
IBM Informix Database Driver for Perl DBI Version 2007.0826 (2007-08-26) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.6.1 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.8.8 - or any later version - you should be planning to upgrade). You will need the code for DBI version 1.38 or later as well (v1.54 - or any later version - is recommended). The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at [EMAIL PROTECTED] ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2007.0826: * Fixed support for CSDK 3.00. * Fixed support for ESQL/C 7.24 (and 5.20). * Detecting mismatched 32-bit Perl vs 64-bit ESQL/C or vice versa. * Fixed memory leak associated with LVARCHAR. * Fix problem with DBD_INFORMIX_DEBUG_ESQLCC=yes. * Fetch UDTs into SQLLVARCHAR instead of CHAR(256). * RT#14954 - only do smart blob test if smart blob space exists. * RT#14095: CLONE function added to driver 2005-08-12. * RT#13708: (LVARCHAR on 32-bit systems) fixed if you use CSDK (ESQL/C) 3.00.xC2 or later. IBM CQ bug idsdb00139040 needs to be resolved. Support email address: * This release is supported by Jonathan Leffler [EMAIL PROTECTED]. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to [EMAIL PROTECTED]; they also get sent to [EMAIL PROTECTED], etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) @(#)$Id: Announce,v 2007.4 2007/08/26 04:52:44 jleffler Exp $ -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0826 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBD::Informix
On 24 Aug 2007 16:04:06 +0200, Piotr Poloczek [EMAIL PROTECTED] wrote: Hello! I have problem with compiling DBD::Informix. Could anybody help me ? Note the part of the diagnostic output that says: ===QUOTE=== Using INFORMIXDIR=/u/informix and ESQL/C compiler esql Using INFORMIX-ESQL Version 7.24.UC7 from /u/informix Your version of ESQL/C is crippled and will not link with shared libraries even if you tell the script to use them (PTS Bug 102265). We are going to make a hacked copy of the script and use that. If the hacked ESQL/C script does not work, then you will probably have to make a static version of Perl with DBD::Informix and the ESQL/C. Read the Notes/static.build file for more information. Or (a much better idea) upgrade to Client SDK 2.40 or later! ===EOQ=== Really and truly, with IDS 7.31, you should be using a CSDK from the 21st century, rather than ESQL/C 7.24 which dates back a decade or so. The following message in the build information indicates a bug in esqlcc: Testing whether your Informix test environment will work... Argument yes isn't numeric in numeric gt () at esqlcc line 102. esqlcc: Num args = 27 I'll get that fixed - but it won't be doing much harm either. (A workaround is to set DBD_INFORMIX_DEBUG_ESQLCC=1 instead of 'yes'.) The real immediate problem is: esqlc: dbdimp.ec, line 1328: Error -33200: Invalid statement on symbol 'ifx_int8_t'. esqlc: dbdimp.ec, line 2202: Error -33200: Invalid statement on symbol 'ifx_int8_t'. 2 error(s) found make: *** [dbdimp.o] Error 1 That's another bug - the ESQL/C 7.2x compiler should not be seeing ifx_int8_t because that is only supported by CSDK versions of ESQL/C. OK - it will take time to get a fixed release of DBD::Informix out - I've been working on and off on it for several months, and I'm having some problems. So, you need a workaround. The simplest from my perspective would be if you upgrade to CSDK 2.90 or thereabouts (which would give you ESQL/C 2.90, which really is newer than ESQL/C 7.24 and 9.52 -- I didn't get a say in the version numbering!). Failing that: Line 1324 of dbdimp.ec says #ifdef SQLINT8 change it to read $ifdef POLLYWOGS_ARE_WONDERFUL;, and the matching #else to $else; and the matching #endif to $endif;, noting carefully the new semi-colons that are mandatory. Line 2202 is in the middle of a #if 0 / #endif section - but it is the ESQL/C compiler that is complaining, not the C compiler. The best thing to do, then, is delete the whole block of code - lines 2192 to 2211. If you prefer to leave it there, then you'll have to embed it in comments, but there are already comments in that section, so it ain't trivial. Alternatively, wrap the #if 0 / #endif section in $ifdef POLLYWOGS_ARE_STUPENDOUS; and $endif; as above. With luck, those two changes will get you on to the next hurdle. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Using an existing JDBC Connection
On 8/9/07, Mathew Delong [EMAIL PROTECTED] wrote: I am calling into a Perl script from a Java class to retrieve information from a database, and am interested in using DBI for the connection. However, the Java class calling into the perl script will already have an established JDBC connection to the database, and I would like to reuse this connection instead of creating a second connection. Is there any way to do this with DBI, or am I barking up the wrong tree? You're barking up the wrong tree, IMNSHO. In general, separate processes cannot share a single database connection. It is doubly complicated when the processes use different language infrastructures (Java and Perl in your case). I wouldn't go so far as to say it can never, ever be done. But I wouldn't want to go to the effort of making it work - it would be excruciatingly hard and revoltingly error prone and most probably wholly unportable (across platforms and across DBMS).. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Using an existing JDBC Connection
On 8/9/07, Mathew Delong [EMAIL PROTECTED] wrote: The issue is that I want to keep the connections on the database to a minimum (1 if possible,) to avoid any problems which might come up with a maximum number of connections be allowed at any given time. Nice target. Not attainable. I was thinking there might be some java library out there which will basically wrap a JDBC connection and at the same time act as the connection retrieved from DBI for the Perl script. So the script thinks it is dealing with one connection when it is actually delegating into the original one. Nope. Nothing doing. -Original Message- From: Peter J. Holzer [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 12:38 PM To: dbi-users@perl.org Subject: Re: Using an existing JDBC Connection On 2007-08-09 11:57:53 -0400, Mathew Delong wrote: I am calling into a Perl script from a Java class to retrieve information from a database, and am interested in using DBI for the connection. However, the Java class calling into the perl script will already have an established JDBC connection to the database, and I would like to reuse this connection instead of creating a second connection. Generally this is not possible. Your perl script will be executed by a second process and most databases don't support sharing database connections between processes (It's too difficult to keep the processess from messing with each other). Even if your database does support it, it is unlikely that the JDBC driver and the DBD driver also support it in a compatible way, so I wouldn't bother and just open a new connection. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: float bug? perl 5.8, DBI and oracle 10.2.0
On 7/18/07, Erwan Lemonnier [EMAIL PROTECTED] wrote:
Hello folk!
Now I think I got a clean shot at what's troubling me 8-)
Consider the following code:
-snip--
use strict;
use warnings;
use DBI;
my $ORASID = $ENV{ORACLE_SID};
my $ORAUSR = 'username';
my $ORAPWD = 'password';
sub showbin {
print bin: .unpack(B70,reverse pack(d,$_[0])).\n;
}
my $v1 = 1.73696;
showbin($v1);
print connecting\n;
my $DBC = DBI-connect(dbi:Oracle:$ORASID,$ORAUSR,$ORAPWD,
{ PrintError=0, AutoCommit=0 } );
my $v2 = 1.73696;
showbin($v2);
-snip--
This code simply opens a connection toward an oracle database. And
shows the binary representation of the string 1.73696 converted into
a native float (NV) before and after we opened the connection.
When I run it with perl 5.6.2, DBI 1.38 and DBD::Oracle 1.17, it says:
[HEAD] ~/HEAD/test/t !967$ /opt/perl-5.6.2/bin/perl 04_test1.t
bin: 0011100010101001011010010001101001110101110011010001
connecting
bin: 0011100010101001011010010001101001110101110011010001
When I run it with perl 5.8.8, DBI 1.58 and DBD::Oracle 1.19, it says:
[HEAD] ~/HEAD/test/t !969$ /opt/perl-5.8.8/bin/perl 04_test1.t
bin: 0011100010101001011010010001101001110101110011010001
connecting
bin: 001110001010100101101001000110100111010111001101
See how the least significant bit (last one on the right) changes in
the last run?
There we have it. It is what caused the problems I have been spamming
you all with for the last few days :)
Conclusion: on my host (perl 5.8 etc.), the line:
my $DBC = DBI-connect(dbi:Oracle:$ORASID,$ORAUSR,$ORAPWD,
{ PrintError=0, AutoCommit=0 } );
seems to alter the way perl parses the string 1.73696. This later
resulted in arithmetic errors that looked like floating point related
issues but were not.
Has anyone any idea of what's happening here
Silly question time - I assume that if you don't includes the DBI-connect
line, then the two invocations of showbin produce the same output in both
versions of Perl.
Somewhere in Elements of Programming Style by Kernighan Plauger, it says
words to the effect that:
A wise programmer once said 'moving floating point numbers is like moving
sand piles; every time you do, you lose a little sand and you pick up a
little dirt'.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: DBI-1.50 | make error on Solaris 10
gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-E' cccdlflags='-fPIC', lddlflags=' -Wl,-E -G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under solaris Compiled at Nov 14 2003 17:42:31 @INC: /apps/iw-home/iw-perl/lib /apps/iw-home/iw-perl/site/lib /apps/iw-home/iw-perl/vendor/lib Oh, and for whatever it is worth, a default build of GCC 4.2.0 needs about 2 GB disk space in the object directory, plus the space for the source code - on Solaris 10 at any rate. Also, there's a stunt you have to pull to get the Korn shell used by configure/make, and the build fails if you don't get that sorted. I forget the details - I will look sometime for them since I had to sort the same problem out for earlier GCC 4.x compilers too. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Smart way to detect SELECT statements?
On 7/10/07, Alexander Foken [EMAIL PROTECTED] wrote: Great, exactly what I needed. I did not see the wood for the trees ;-) Remember that procedures might return values, and might therefore be confused with SELECT statements (eg Informix with EXECUTE PROCEDURE - sometimes; sometimes Informix procedures don't return values). There again, maybe that wouldn't matter to you. And some SELECT statements start with WITH these days (DB2, ISO SQL). On 09.07.2007 10:29, Martin Evans wrote: Alexander Foken wrote: is there a smart way to detect if a prepared statement is a SELECT or a non-SELECT statement? Examine NUM_OF_FIELDS on the statement which will be 0 for non-select statements. From DBI: Statements that don't return rows of data, like DELETE and CREATE set NUM_OF_FIELDS to 0 (though it may be undef in some drivers). -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: TZ info used by dB drivers
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I'm trying to track down how TZ info is used by a dB driver, in this case
DBD::Ingres.
It would appear that TZ is getting passed to the driver on the first
connection (when the driver is installed) and doesn't see changes to
$ENV{TZ} between the first connection and subsequent connections in the
running script.
If this is a driver issue is there an uninstall driver method, such that
subsequent connections will reload the driver in the running script so the
changed $ENV{TZ} will be seen? If this is a DBI issue is there a way for
the changed $ENV{TZ} value to be seen in the driver?
There are multiple places that could be affected by this - I just spent the
weekend chasing timezones around a JDBC driver, and it is painful.
The underlying Unix API really only provides one function call to control
the current time zone, and call is tzset(). No arguments, no return value.
It gets called implicitly by a bunch of functions, too, if they think it
necessary. The result is 'gating'; the time zone is set once and not
adjustable thereafter -- which is what you are observing.
Speculation: maybe, just maybe, if you set the environment and manage to
explicitly call tzset() afterwards, it might, conceivable notice the new
time zone. But I'm not confident that it would, and could easily be
platform specific.
The java.util.Date, java.util.Calendar and java.util.TimeZone APIs allow for
a lot of control and information for which there is no corresponding C API,
sadly.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Help requested : Compile/build requirements for DBI - 1.37 and DBD-Oracle- 1.14 - Double message
/Driver.xst /opt/SUNWsymon/lib/DBI/site_perl/sun4-solaris/auto/DBI/Driver_xst.h /opt/SUNWsymon/lib/DBI/site_perl/sun4-solaris/auto/DBI/dbd_xsh.h /opt/SUNWsymon/lib/DBI/site_perl/sun4-solaris/auto/DBI/dbi_sql.h /opt/SUNWsymon/lib/DBI/site_perl/sun4-solaris/auto/DBI/dbipport.h You might not need the Win32 stuff; you might not need the DBI headers (but then again, you might if you ever needed to upgrade in the field). You might not need ... but I think you're being penny-wise and pound-foolish. Original Message Subject:URGENT help required : Compile/build requirements for DBI - 1.37 and DBD-Oracle- 1.14 Date: Mon, 25 Jun 2007 16:36:42 +0530 From: [EMAIL PROTECTED] To: Tim Bunce [EMAIL PROTECTED] We need to bundle DBI -1.37 and DBD-Oracle-1.14 in our product. Our product is supported on Solaris 8, 9 and 10 (sparc architecture). Are there any architecture specific or OS specific source code in DBI or DBD-Oracle that we have to build them on every OS or architecture? We are assuming that if we compile DBI and DBD-Oracle source on Solaris 8, it should work fine with Solaris 9 and 10 as well. Is our assumption correct? Please help. Most probably, if the Perl works and the Oracle works on all three (and Perl will; Oracle I won't answer for), then DBI and DBD::Oracle will too. Will the Oracle database be installed in a fixed location on all machines? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
DBD::Informix test failure for lvarchar - bug found!
)
{
printf(**BUG** wanted = %s\n, lvc2);
num_bugs++;
}
}
}
ifx_var_freevar(lv1);
ifx_var_freevar(lv2);
$ close c;
$ free c;
$ free p;
$ deallocate descriptor d;
}
int main(int argc, char **argv)
{
$ char *dbname = stores;
if (argc 1)
dbname = argv[1];
$ database :dbname;
$ whenever error continue;
$ drop table lvarchar_test;
$ whenever error stop;
printf(\nTest 1: LVARCHAR(128) - with NOT NULL\n);
$ create table lvarchar_test
(
row_numberserial not null primary key,
lvc_with_null lvarchar(128),
lvc_wout_null lvarchar(128) not null
);
$ insert into lvarchar_test values(1, :lvc1, :lvc2);
check_data();
printf(\nTest 2: LVARCHAR - with NOT NULL\n);
$ drop table lvarchar_test;
$ create table lvarchar_test
(
row_numberserial not null primary key,
lvc_with_null lvarchar,
lvc_wout_null lvarchar not null
);
$ insert into lvarchar_test values(1, :lvc1, :lvc2);
check_data();
printf(\nTest 3: LVARCHAR(128) - without NOT NULL\n);
$ drop table lvarchar_test;
$ create table lvarchar_test
(
row_numberserial not null primary key,
lvc_with_null lvarchar(128),
lvc_wout_null lvarchar(128)
);
$ insert into lvarchar_test values(1, :lvc1, :lvc2);
check_data();
printf(\nTest 4: LVARCHAR - without NOT NULL\n);
$ drop table lvarchar_test;
$ create table lvarchar_test
(
row_numberserial not null primary key,
lvc_with_null lvarchar,
lvc_wout_null lvarchar
);
$ insert into lvarchar_test values(1, :lvc1, :lvc2);
check_data();
printf(\nTest 5: LVARCHAR(128) - with NOT NULL in TEMP TABLE\n);
$ drop table lvarchar_test;
$ create temp table lvarchar_test
(
row_numberserial not null primary key,
lvc_with_null lvarchar(128),
lvc_wout_null lvarchar(128) not null
);
$ insert into lvarchar_test values(1, :lvc1, :lvc2);
check_data();
$ close database;
if (num_bugs == 0)
printf(== PASSED ==\n);
else
printf(** FAILED ** %d bugs detected\n, num_bugs);
return(num_bugs 0); /* 0 on no bugs; 1 otherwise */
}
To say that the circumstances under which it fails are obscure is to be
excessively polite.
I tried to release an update to DBD::Informix, but the release process goes
through the test suite, and since the test t/t93lvarchar.t was failing, it
was not possible to make the release automatically, so I haven't made the
update. I may decide to cheat and make the release using a 64-bit Perl and
64-bit ESQL/C, like I did with the DBD::Informix 2007.0226 (though that was
released completely unaware of the issue - this one would be released
despite knowing the test fails). The temptation to modify the test (eg to
use a temp table instead of a permanent one) is also quite considerable.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: DBD::Informix test failure for lvarchar
On 6/2/07, John Siracusa [EMAIL PROTECTED] wrote: On 6/2/07 5:42 PM, John Siracusa wrote: Just to chime in, we have a similar problem at work: selecting a row with an LVARCHAR column in it causes a segfault(!) for us. This happens on two of our machines, but does not happen on a third. We have yet to narrow down the exact differences. I'll post more when I have more information. In the meantime, I just wanted to add my basic we can't use LVARCHAR columns with DBD::Informix either report. Sorry, this is using the latest DBD::Informix form CPAN, in case that wasn't clear. We've tried a few minor revisions of the CSDK with no affect, but I don't recall the exact versions. Again, more info to follow eventually... Just spent some 'spare time' building Perl 5.8.8 plus DBI 1.56 plus DBD::Informix 2007.0226 plus ESQL/C 3.00.FC1 (more or less) on RedHat Linux for PowerPC 64-bit, and (once some build issues are resolved), the damn thing works without visible error (using an IDS 10.00.UC5 server on Solaris 10 running some 1,500 miles from where the Linux box is). That's a pity! It looks like a memory allocation problem (I managed to get a core dump out of CSDK 2.81.UC2 on Solaris 8, for example) and I was planning to use valgrind on the code. In fact, I probably will still do that, just to see whether there is anything egregious that valgrind detects but the rest of the system does not (it just won't be tonight). So, various issues: 1. The band-aids for CSDK 3.00 are imperfect; that alone means I must do a new release of DBD::Informix before long. If/when you run into problems, contact me - but the basic solution is to change ESQLC_VERSION 300 into ESQLC_VERSION 400 in various locations; more than one file, sadly. 2. The exact details of the LVARCHAR misbehaviour are sadly dependent on the version of CSDK and probably on the platform. 3. Despite earlier mention of different versions of DBI, I want to re-emphasize that the only influence I think it has is on the visibility of the problem - some versions of DBI make it easier to spot the trouble than others - probably on a platform-specific basis. Or, IOW, this is one of those hard bugs - I'm having trouble locating the real problem. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBD::Informix test failure for lvarchar
On 6/1/07, Mark Abajian [EMAIL PROTECTED] wrote: In reply to a recent inquiry about my post... I have not resolved the issue. There is no resolution yet from the Guardian of DBD::Informix. Still true - but I will proffer the information that I too have problems now which I clearly didn't when I released 2007.0226 (I don't release the code with known-to-fail tests). I will have to backtrack too, but I'm moderately sure that I'm using the same CSDK and DBD::Informix, but newer versions of DBI. Why this would matter is completely non-obvious - it is most likely that a bug has been uncovered in DBD::Informix rather than anything else. OTOH, you're using DBI 1.47, which is way older than the 1.54..1.56 versions. In my none-too-copious so-called spare time, I will try to resolve this, but I'd also take patches from anyone else who can resolve it. Here is what I have learned on my own... (in all cases, this is using Informix IDS 10.00 on a remote host, and the client is on Solaris 8, DBI is 1.47) DBD-Informix-2007.0226 + CSDK-2.70.UC3 -- 91udts fails so I updated my CSDK: DBD-Informix-2007.0226 + CSDK-2.90.UC4 -- 93lvarchar fails (these are the latest clients, and so I made my bug report based on these) so I went retro on the Perl client: DBD-Informix-2007.0225 + CSDK-2.90.UC4 -- 93lvarchar fails so I went double-retro on the Perl client: DBD-Informix-2005.02 + CSDK-2.90.UC4 -- complete success But, it looks like the only reason that 2005.02 did *not* fail is because it does *not* perform the same tests on LVARCHAR NOT NULL that the 2007.0225 and .0226 clients perform. For now, I am using 2007.0226 (as in my bug report). Since we currently have no LVARCHAR columns in our data base, and we have no intention in the near term of using such, we have decided just to use this latest version. I asked the CPAN shell to do a force install. I hope this information proves useful. -- Mark Abajian On Jun 1, 2007, at 2:38 AM, a colleague wrote: Hi Mark, I saw your recent question on the above, after a web search that I made with the aim of resolving the same problem which I am also having! If you were able to settle it, or work round it without too much fuss, I'd be very interested in the details. If not, I'm afraid I have little to offer you for now, because obviously I am in the same boat. But if you like I'll gladly share any information I can unearth, not that I've had much luck so far. Anyway, I look forward to hearing from you if you get a chance to reply. Cheers On May 14, 2007, at 10:18 PM, Mark Abajian wrote: [This is my second attempt to post. First was refused for overly- long attachment.] Hello. I hope I have enough information here for someone to assist with a DBD::Informix problem. I am installing DBD::Informix on a Solaris 8 host. We have a 32- bit Perl 5.8.6, compiled with gcc 3.4.3. The Informix Client SDK is 2.90UC4 (32-bit SPARC). The Informix server, on a Solaris 9 host, is IDS 10.00.FC4 (64-bit SPARC). I ran into a problem with test t/t93lvarchar.t. It appears that the script is failing to retrieve values for columns of type lvarchar not null. Otherwise, the build and tests seem just fine. What is the status of this anomaly? (I saw similar postings dating from 2002-2005.) Is this anything to be concerned about if I have no columns of type lvarchar not null? Any recommendations? A bug report for D t/t93lvarchar.t is attached. Thank you for your assistance. -- Mark Abajian mabajian-bugreport-20070514-short.out -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Clarification on DBI module
On 5/9/07, ramesh thangamani [EMAIL PROTECTED] wrote: Can you please clarify my doubts regarding DBI perl module used for database connection. In my environment I am using single module to prepare and execute the sql queries. The sql query can have bind variables or they may not have. In order to improve performance i used prepare() and execute() sequence for the queries. Recently I am facing a issue. When i prepare a query with bind variables and pass the bind variables in execute() method it works fine, but second time if i invoke without passing bind variables it returns the previous query results and it is not throwing the error: DBD::Oracle::st execute failed: ORA-01008: not all variables bound (DBD ERROR: OCIStmtExecute) [for Statement Which i believe is the expected behaviour since i should pass bind variables without which the query should fail. How come the execute functions fine without bind variables in the second/multiple query runs. Is there a way to solve this issue other that re preparing the query ?. Tried searching on Web regarding this issue but couldn't find any discussion on this. My reading of 'perldoc DBI' (at http://search.cpan.org/~timb/DBI-1.55/DBI.pm#DBI_STATEMENT_HANDLE_OBJECTS) suggests that the $sth-bind_param() method makes the values bound sticky - the types definitely are sticky - and therefore, once values have been supplied, those values are remembered. The $sth-bind_param_inout() - which isn't supported by all drivers - stores references to variables, so it uses the value at the time the $sth-execute() is called. In other words, what you're seeing is what I'd expect to see. If you want to provoke the error, try (it might not work) supplying one value instead of the half-dozen needed; that might generate an error, though I'd not want to rely on that. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Bar Code
On 5/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I want to barcode label from a serial number. I have a property accountability database using SYBASE. I access the database using perl and cgi, and display the results on the Web Page using Apache. The server is a unix platform running solaris 8. At the present time I can print labels, with the serial number, nomenclature and hand reciept number. I would like to print the serial number on barcode format. So you need to obtain for yourself Perl modules (or other software) that will print a bar-code for you when given the appropriate data. The module is unlikely to be under the DBI or DBD hierarchies, so there's at least some argument that the question is inappropriate for this list. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Getting off the DBI-Users mailing list [was: Re: SQLite 3.3.16 nulls test results]
The email headers say: List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] Send email to [EMAIL PROTECTED] from your registered email acccount, or go to the web site dbi.perl.org and unsubscribe from there. On 5/2/07, OMAR BARADI [EMAIL PROTECTED] wrote: I have been trying to unsubscribe. I followed the directions and sent an email but I still keep on getting emails. How can I get off this list? It would be more helpful if you stated where you sent email - you should expect a confirmation request. Or send to the help address and get more information. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Fwd: Proposal for new $h-{ReadOnly} attribute
Ooops; most of the mailing lists I work with redirect responses to the
list. I forget this one doesn't.
-- Forwarded message --
From: Jonathan Leffler [EMAIL PROTECTED]
Date: May 1, 2007 6:32 AM
Subject: Re: Proposal for new $h-{ReadOnly} attribute
To: H.Merijn Brand [EMAIL PROTECTED]
On 5/1/07, H.Merijn Brand [EMAIL PROTECTED] wrote:
On Mon, 30 Apr 2007 14:56:37 +0100, Tim Bunce [EMAIL PROTECTED] wrote:
I've just added this to the DBI docs:
=item CReadOnly (boolean, inherited)
[...]
=cut
I'd like to see that extended to be able to allow dirty reads or no-lock
reads, whatever the database allows.
It seems to me that the set of permitted statements will be somewhat
specific to the DBMS. I'd expect 'session attributes' to be OK; things like
isolation level and even locking tables should be allowed - as long as the
session doesn't alter the database.
A complex question - probably one to which there isn't an answer - relates
to 'when is an operation read-only'?
Clearly, an INSERT statement is not allowed; ditto UPDATE or DELETE. Also,
DDL statements like CREATE TABLE are not allowed.
But what about a statement that creates a temporary table - only accessible
to the session, only for the duration of the session?
SELECT * FROM SomeTable INTO TEMP NewTable;
Is that supposed to be allowed in a read-only transaction/session? The code
would not allow the corresponding DROP TABLE (or DELETE), so you could only
create the table once and reuse it.
Even more complex - what about executing procedures. Can you trust the
procedure to make no modifications? Unless the system can tell you that the
procedure is 'safe',
I have a program, SQLCMD, for which I recently added (at user request) a new
SQLREAD program (a minor subset of the main program). It had to deal with
these issues: which statements to really allow, stored procedures, and
SELECT INTO TEMP. And I ended up allowing non-modifying statements, the
implicit temporary tables created by SELECT INTO TEMP, and rejecting direct
execution of stored procedures.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Data Format
On 4/8/07, essential quint [EMAIL PROTECTED] wrote: I'm still learning DBI, so please dont hit me too hard. ;) OK. I've noticed, when capturing form input in multiline text boxes, the format (particularly line breaks) is getting lost. Is there a way to preserve such things as line breaks? DBI has no multi-line text boxes (or any other sort of text box, come to that), so I think you are probably asking the question in the wrong forum. It sounds like you might be writing CGI scripts or something similar to collect input from a browser. If so, you should ask in a more general Perl forum - such as one of the comp.lang.perl.* news groups. Alternatively, show the DBI code that is giving problems...but we will not be very interested in debugging the supporting CGI-related bits'n'pieces (which is where it sounds as if your problem is). -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Regarding Perl DBI version issue.
Amen! (And politely put - I'm not sure I could have managed to be so tactful.) On 4/4/07, Peter J. Holzer [EMAIL PROTECTED] wrote: On 2007-04-04 14:00:45 +0530, RaviChandra Chelikam wrote: Yes u r correct. For root user I don't have have /usr/local/bin in the path. For Root user, currently it is showing /usr/bin/perl. And It is pointing to perl, version 5.005_03 built for sun4-solaris. Could u plz tell how to set the path as /usr/local/bin /perl for the Root user so that it points for 5.6.1 version. Read a Unix for beginners style book. This is not a DBI or even perl-related question, and if you don't know how to set the path you shouldn't know the root password of that machine. hp -- _ | Peter J. Holzer| If I wanted to be academically correct, |_|_) | Sysadmin WSR | I'd be programming in Java. | | | [EMAIL PROTECTED] | I don't, and I'm not. __/ | http://www.hjp.at/ | -- Jesse Erlbaum on dbi-users -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never lack amusement.
Re: DBI compile fails in Solaris 10
On 3/30/07, Tim Bunce [EMAIL PROTECTED] wrote: On Thu, Mar 29, 2007 at 07:53:55AM -0500, Nurmi, Michael V wrote: Below is the output I get when I try to do a make on the DBI module in Solaris 10. This works fine on Solaris I was wondering if I need an updated module for solaris10? Is there any DBI module that works with solaris10? Please let me know what is happening. gcc -B/usr/ccs/bin/ -c-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\1.54\ -DXS_VERSION=\1.54\ -fPIC -I/usr/local/lib/perl5/5.8.7/sun4-solaris/CORE -W -Wall -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual -DDBI_NO_THREADS Perl.c In file included from /usr/include/sys/signal.h:34, from /usr/include/signal.h:26, from /usr/local/lib/perl5/5.8.7/sun4-solaris/CORE/unixish.h:106, from /usr/local/lib/perl5/5.8.7/sun4-solaris/CORE/perl.h:2220, from DBIXS.h:19, from Perl.xs:6: /usr/include/sys/siginfo.h:259: syntax error before ctid_t This kind of error indicates that the perl you're using was not built with the compiler you're using. Or the compiler you are using (GCC) was not built for Solaris 10. I've just migrated from Solaris 8 and 9 to Solaris 10, and the headers in Solaris 10 are different from, and weirder than, the headers in Solaris 8 and 9. Actually, they're mostly cleaner, but I had to rebuild GCC on Solaris 10 (using Sun Forte to bootstrap it) because of problems with keywords, etc. I specifically ran across ctid_t at one point - I'd not gotten around to Perl at that point - with the older compiler. You need to use the same compiler that was used to build the perl you're building DBI for. Often that means building and installing your own, separate, perl. Was the gcc you are using built for/on Solaris 10? If not, get one that was. (Use gcc --version to find out.) -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Perl DBI Urgent
On 3/27/07, Sanjay Tripathi [EMAIL PROTECTED] wrote: Here one more thing I want to add that, I am using perl-5.6.1 and DBI-1.48. Whenever I/m trying to install DBI. It display me messages like below. Perl versions below 5.6.1 are no longer supported by the DBI. Perl versions 5.6.x may fail during installation with a complaint about the use of =head3 in the pod documentation. I see you're using perl 5.006001 on sun4-solaris-64int, okay. Remember to actually *read* the README file! Use 'make' to build the software (dmake or nmake on Windows). Then 'make test' to execute self tests. Then 'make install' to install the DBI and then delete this working directory before unpacking and building any DBD::* drivers. Any Idea !! Looks normal - what's your concern? In case of doubt, upgrade to Perl 5.8.8(but leave the system copy of Perl strictly alone - well, I would (and do) leave the system Perl well alone and install my own version of Perl elsewhere). -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Perl-Postgres connection: 'Commit' method not found in DBI. Advice?
On 2/28/07, Martin Gainty [EMAIL PROTECTED] wrote:
yep--
Aparently postgres thinks its smarter than anyone that wants to use it and
has Auto-commit ALWAYS turned on
If you find a way to turn this *feature* off let me know because it is
massively counter intuitive to normal operation of any other db on the
planet
I'm not sure about PostgreSQL, but Informix has a somewhat similar mode - or
two somewhat similar modes. An unlogged (Informix) database has no
transaction support at all; you cannot do transactions, and each statement
is nominally a self-contained transaction (except that if an error occurs
part way through, the changes made so far are not undone - for DML
statements). In a regular logged database, each statement is a separate
transaction - complete with rollback so that if a statement fails part way
through, the database is left as if the statement had never been executed.
In a logged database, you can suppress the auto-commit mode by an explicit
BEGIN WORK statement. This begins a (multi-statement) transaction that is
terminated by COMMIT WORK or ROLLBACK WORK. If something happens to the
client before COMMIT is executed, the transaction is rolled back.
It doesn't take a lot of searching around the PostgreSQL documentation to
find:
BEGIN -- start a transaction blockSynopsis
BEGIN [ WORK | TRANSACTION ] [ *transaction_mode* [, ...] ]
where *transaction_mode* is one of:
ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED
| READ UNCOMMITTED }
READ WRITE | READ ONLY
I suspect you'll find that this 'turns off autocommit' for you.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2007.0226 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
ANNOUNCE: IBM Informix Database Driver for Perl DBI Version 2007.0226 (2007-02-25) release
Miracles never cease - blame it on a snow-storm in Lake Tahoe, CA and wireless connectivity. OTOH, the upload of version 2007.0225 included the wrong Announce file - hence version 2007.0226. IBM Informix Database Driver for Perl DBI Version 2007.0226 (2007-02-25) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.6.1 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.8.8 - or any later version - you should be planning to upgrade). You will need the code for DBI version 1.38 or later as well (v1.54 - or any later version - is recommended). The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at [EMAIL PROTECTED] ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2007.0226: * Support for CSDK 3.00. * Minor bug fixes. * No exploitation of new features in DBI. New in release 2005.02: * The changes here are all related to improved diagnostics during the build process. For example, esqlcc works in debug mode once more. * Fix bug with INT8 handling on 64-bit platforms. * Identify dubious Solaris linker flags (-z ignore is the trouble maker; -z lazyload is the memorable one; -z combreloc usually occurs with them and might or might not be damaging). * Identify dubious AIX compiler flags (-qlanglvl=ansi). * Add DBD_INFORMIX_NO_RESOURCE environment variable for under-privileged Informix users (those with CONNECT privilege only). * Add DBD_INFORMIX_NO_DBCREATE environment variable for a different class of under-privileged users (those not permitted to create databases because of ONCONFIG parameter DBCREATE_PERMISSION). * These mean that if there is a database to which you can connect, you can test DBD::Informix and have good (though not perfect) confidence that all is OK. New in release 2005.01: * Various minor bug fixes made as reported - see ChangeLog. * Release required to handle Informix ClientSDK 2.90, which includes ESQL/C 2.90. The previous release (CSDK 2.81, included ESQL/C 9.51), and the older DBD::Informix compilation based decisions off the ESQL/C version, rejecting 2.90 as obsolete and unusable. * Note that a number of obsolete versions of ESQL/C are no longer supported. Known problem: * t/t91udts.t sometimes warns about an uninitialized variable on subroutine entry. It seems to be harmless - but it is very irksome. Support email address: * This release is supported by Jonathan Leffler [EMAIL PROTECTED]. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to [EMAIL PROTECTED]; they also get sent to [EMAIL PROTECTED], etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) @(#)$Id: Announce,v 2007.1 2007/02/26 00:04:02 jleffler Exp $ -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Problem of installing DBI packages
On 2/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi jonathan, Dear Anupam, First rule of mailing list etiquette - keep discussions on the mailing list unless invited to take the discussion off-list. That way, you might get an answer quicker - and you might not annoy people who have helped by forcing them to admit they've no clue what's up now. See also: http://www.catb.org/~esr/faqs/smart-questions.html Thank you very much for your effort.I have successfully installed DBI packages. Now i am facing a very starnge problem with DBD-Oracle package. My perl version:5.8.0 HP UX version 11 gcc version 3.4.2 i get the following error when i do make bplita3 /tmp/download_for_comverse/DBD-Oracle-1.19 make gcc -c -I/oracle/app/oracle92/product/9.2.0/rdbms/public -I/oracle/app/oracle92/product/9.2.0/rdbms/demo -I/oracle/app/oracle92/product/9.2.0/rdbms/demo -I/oracle/app/oracle92/product/9.2.0/rdbms/public -I/oracle/app/oracle92/product/9.2.0/plsql/public -I/oracle/app/oracle92/product/9.2.0/network/public -I/opt/perl/lib/site_perl/5.8.0/IA64.ARCHREV_0-thread-multi/auto/DBI -D_POSIX_C_SOURCE=199506L -D_REENTRANT -D_HPUX_SOURCE -fPIC -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DVERSION=\1.19\ -DXS_VERSION=\1.19\ -fPIC -I/opt/perl/lib/5.8.0/IA64.ARCHREV_0-thread-multi/CORE -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\9.2.0.6\ Oracle.c In file included from /opt/perl/lib/5.8.0/IA64.ARCHREV_0-thread-multi/CORE/perl.h:3950, from /opt/perl/lib/site_perl/5.8.0/IA64.ARCHREV_0-thread-multi/auto/DBI/DBIXS.h:1 9, from Oracle.h:13, from Oracle.xs:1: /usr/include/sys/ipc.h:51: error: parse error before cid_t /usr/include/sys/ipc.h:56: error: parse error before '}' token Ouch - don't know why, but there's a problem with the way #include sys/ipc.h was used. Maybe #include sys/types.h was left out? In file included from /opt/perl/lib/5.8.0/IA64.ARCHREV_0-thread-multi/CORE/perl.h:3951, from /opt/perl/lib/site_perl/5.8.0/IA64.ARCHREV_0-thread-multi/auto/DBI/DBIXS.h:1 9, from Oracle.h:13, from Oracle.xs:1: /usr/include/sys/sem.h:91: error: field `sem_perm' has incomplete type *** Error exit code 1 sem_perm is likely to be part of sys/ipc.h or related to sys/ipc.h. Fix the first and I expect the second will go away too. Stop. please help in installing this.Thanx in advance.Waiting eagarly for the reply I'm always tempted to leave such mails unanswered for a few days... :-( -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: DBD::Informix and SELECT from MULTISET column
I've been trying to wrap my brain around it (pretty casually, I admit) for a
decade or so.
If you'd like to help out with some code changes, I'm very willing to accept
them.
...more below...
On 2/15/07, tvilliers [EMAIL PROTECTED] wrote:
On 23 Sep 2005, 16:23, [EMAIL PROTECTED] wrote:
I'm looking for a bit more information WRT the returned dataset from
selecting from a MULTISET column in Informix please.
Create a small table:
create table test (col1 int,col2 multiset(int not null))
and insert a couple of rows of test data (eg, 1, {2,3} etc)
When I use this test script:
_BEGIN_
use DBI;
use DBD::Informix qw(:ix_types);
my $dbh = DBI-connect(...);
my $sth = $dbh-prepare('SELECT col2 FROM test');
$sth-execute();
my $col2;
$sth-bind_col(1, \$col2, { TYPE = 'IX_MULTISET'} );
while ( my $row = $sth-fetchrow_hashref() ) {
print $col2\n;}
$sth-finish();
$dbh-disconnect;
_END_
the returned resultset is flat:
MULTISET{1,2}
...
I expected a reference to an object (an array); or how else would I
achieve such a result?
I still don't understand how you're supposed to manipulate dynamic
structures like multi-sets from the client-side without knowing in advance
what the type is. I did get pointed to some documentation earlier this week
-- I just need some time to inwardly digest (and, I'm not convinced it gives
me the answers I need).
It's been a while since the post above, but I'd still appreciate any
pointers.
Also, when the returned MULTISET column exceeds 256 bytes, it gets
truncated, even though the data type is explicitly bound as in the
previous example.
If you go poking in the DBD::Informix code, you'd find some code (written by
someone other than me - and I don't fully understand it) that deals with
these types up to a size of 256 bytes. I have not worked out what it does,
how it does it, why it does it, the extent to which it does work, etc.
The relevant file is dbdimp.ec.
I've tried setting the LongReadLen attribute, but it doesn't seem to
make any difference to the result either.
DBD::Informix pretty thoroughly ignores LongReadLen - it won't make any
difference. A MULTISET is not a LOB type, anyway, so it is far from clear
that LongReadLen should affect it.
You're suffering from an itch I've not been suffering - want to do the Open
Source thing and scratch your itch? Patches (or new maintainers)
gratefully accepted.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: DBD::Informix Make test Problem
- Transactions with autocommit on. I don't recall failures in txacoff - I would expect it pass. Please send the verbose output of the test. t/t43trans..dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED tests 6, 11, 15-16, 19 Failed 5/20 tests, 75.00% okay Another set of transaction tests - please send the verbose output of the test. t/t44txansi.skipped all skipped: MODE ANSI test - database '[EMAIL PROTECTED]' is not MODE ANSI t/t46chpblk.ok t/t50update.skipped all skipped: MODE ANSI test - database '[EMAIL PROTECTED]' is not MODE ANSI t/t51getinfook t/t53types..ok t/t54native.ok t/t55mdata..ok t/t56tabinfook t/t57tables.ok t/t58typeinfoallok t/t60unlog..ok t/t65updcur.dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED tests 7, 15 Failed 2/16 tests, 87.50% okay updcur - Update with the WHERE CURRENT OF clause - again, please send verbose test output. t/t66insert.ok t/t72blob...ok t/t73blobupdok t/t74blob...ok t/t75blob...ok t/t76blob...ok t/t90iusok t/t91udts...ok t/t92rows...ok t/t93lvarchar...ok t/t94bool...ok t/t95int8...ok t/t98podok t/t99clean..ok Failed TestStat Wstat Total Fail List of Failed --- t/t41txacoff.t1 256194 10 14-15 18 t/t43trans.t 1 256205 6 11 15-16 19 t/t65updcur.t 1 256162 7 15 3 tests skipped. Failed 3/55 test scripts. 11/834 subtests failed. Files=55, Tests=834, 17 wallclock secs ( 9.53 cusr + 0.71 csys = 10.24 CPU) Failed 3/55 test programs. 11/834 subtests failed. *** Error code 29 make: Fatal error: Command failed for target `test_dynamic' To get verbose test output of the three tests: sh test.verbose.sh t/t4[13]* t/t65* -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: problem with installing dbi module
On 2/9/07, Jai chandru [EMAIL PROTECTED] wrote: iam using pxperl 5.8.1 on windows and when i tried to install following error was reported . nmake gcc cannot be recoganised as a internal command. fatal error... Why Perl 5.8.1? Use 5.8.8! It appears that your Perl was built with GCC but you don't have GCC on your machine. Install GCC - and then the fun continues... -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: perl DBD and DBI for 64 bit perl
On 2/8/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote: Jonathon, Dear Josaph :-) I'm really in a pinch here: Here's the error I get when I try to compile the DBD:. Can you help me out here. Below you'll find my level of Perl and the dbd and dbi versions I'm attempting to install. gcc -shared DB2.o dbdimp.o -o blib/arch/auto/DBD/DB2/DB2.so -L/opt/IBM/db2/V8.1/lib -ldb2 /usr/bin/ld: skipping incompatible /opt/IBM/db2/V8.1/lib/libdb2.so when searching for -ldb2 Well, it looks like the DB2 client software you have is probably a 32-bit version, so GCC is quite correctly not linking your 64-bit DBD::DB2 module with the 32-bit DB2 client software -- it wouldn't work even if it tried. You have two options: * Find, install, use a 64-bit DB2 client library. * Recompile Perl, DBI and then DBD::DB2 as 32-bit code to use the 32-bit DB2 client. Both would work - which is better for you depends on whether you can find a 64-bit DB2 client library. /usr/bin/ld: cannot find -ldb2 collect2: ld returned 1 exit status make: *** [blib/arch/auto/DBD/DB2/DB2.so] Error 1 [EMAIL PROTECTED] DBD-DB2-0.78]# Here are the versions I'm trying to compile as well as the perl version. DBI-1.51 DBD-DB2-0.78 [EMAIL PROTECTED] DBD-DB2-0.78]# perl -v This is perl, v5.8.5 built for x86_64-linux-thread-multi -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: perl DBD and DBI for 64 bit perl
On 2/8/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote:
You are correct... it is a 32 bit file bear with me...I'm a little
confused by this statement:
You need to distinguish between the database server (which I think your
evidence below shows is the case) and the client software used to connect to
it. The server in question, is the database server.
The parenthetical remark in my sentence wasn't complete - apologies. If you
ignore that, then I said that you simply need to be aware that the
application program (eg Perl + DBI + DBD::DB2) uses a client library to
connect to the database server. It does not include the database server
code in the client program. And that means that the client program can have
a different bittiness from the server. What the parenthetical remark should
have been is (and I think your evidence below shows that the server is a
64-bit server).
Anyway, moving forward, how do I force the compilation of the modules to go
to point to the db2 64bit libraries? Do I need to modify the
Makefile.plscript? Is there an easier way?
Note: the *.1 files are links.
[EMAIL PROTECTED] lib]# locate libdb2.so
/opt/IBM/db2/V8.1/lib/libdb2.so.1
/opt/IBM/db2/V8.1/lib/libdb2.so
/opt/IBM/db2/V8.1/lib64/libdb2.so.1
/opt/IBM/db2/V8.1/lib64/libdb2.so
This is the valuable information...You have the 64-bit libraries; you just
need to persuade Perl to use them.
I don't have the source for DBD::DB2 0.78 on my machine - but I looked at
0.76 instead. In Makefile.PL, there is code to the effect:
# libraries required to build DBD::DB2 driver
if( $os eq 'MSWin32' || $os eq 'MSWin64' || $os eq 'os2' )
{
$sysliblist = qq(-L$DB2/lib db2cli db2api);
my @libpaths = split /;/, $ENV{'LIB'};
my $libpath;
while( @libpaths )
{
( $libpath = shift(@libpaths) ) =~ s///g; # Remove quotes
$libpath =~ s:\\:/:g;
if( $libpath $sysliblist !~ /-L$libpath/i )
{
$sysliblist .= qq( -L$libpath);
}
}
}
else
{
$sysliblist = -L$DB2/lib -ldb2;
}
This needs to be modified, I believe, so the last else clause takes into
account the possibility of a 64-bit Perl. There are various configuration
items that could be used to identify 64-bit Perl:
$Config{use64bitint}
$Config{use64bitall}
$Config{intsize} == 8
$Config{ptrsize} == 8
So, if some suitable values of these are set, you should change $sysliblist
to use -L$DB2/lib64
elsif ($Config{ptrsize} == 8)
{
$sysliblist = -L$DB2/lib -ldb2;
}
With this hacked into Makefile.PL, there's a chance you'll build correctly.
DBD::DB2 Maintenance Team - please note this suggested change; validate and
fix for the next release of DBD::DB2. Thanks!
Thanks again...
Regards, Joe
-Original Message-
*From:* Jonathan Leffler [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, February 08, 2007 1:14 PM
*To:* Wholey, Joseph (GTI)
*Cc:* DBD::DB2 Maintenance Team; DBI Users Mailing List
*Subject:* Re: perl DBD and DBI for 64 bit perl
On 2/8/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote:
OK... we're making progress... that is a 64 bit db2... maybe there is a
problem with their libraries. Anyway, what from that error I'd sent you
indicates that it's going against a 32 bit db2 lib? btw... I really
appreciate your help on this.
You need to distinguish between the database server (which I think your
evidence below shows is the case) and the client software used to connect to
it.
The evidence from your build suggests that the client software installed
in /opt/IBM/db2/V8.1/lib
(the libdb2.so file in there) is a 32-bit library. You can confirm that
by running the 'file' command on it.
For example:
Anubis JL: cd /usr/lib
Anubis JL: file libc.so
libc.so:ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically
linked, not stripped
Anubis JL: cd sparcv9
Anubis JL: file libc.so
libc.so:ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically
linked, not stripped
Anubis JL:
Assuming that this is the problem, you will either need to install the
64-bit client software - probably in a separate location so you don't break
the existing code that uses the 32-bit software (though I'm not sure how
easily you can do that with DB2) - or you have to use a 32-bit Perl and
32-bit DBI to build a 32-bit DBD::DB2 using the 32-bit DB2 client libraries.
If this is not the problem, then we need to understand why GCC is refusing
to play with the libdb2.so library in /opt/IBM/...
rpcjq-mphqa1cjs101;/rpcjqhome/rpcjqexit
[EMAIL PROTECTED] DBD_DBI]# su - rpcjq
mphqa1cjs101
*** db2instance --- rpcjq
*** db2dbdft--- DBRPCJ
*** schema --- RPCJQ
*** UNIX ID --- rpcjq
rpcjq-mphqa1cjs101;/rpcjqhome/rpcjqdb2level
DB21085I Instance rpcjq uses 64 bits and DB2 code release
SQL08025 with
level identifier 03060106.
Informational tokens are DB2 v8.1.3.112, s060429, MI00159, and
FixPak
12.
Product
Re: perl DBD and DBI for 64 bit perl
On 2/8/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote:
Jonathan,
...and finally, are you aware of a version that points to the 64 bit
libraries. If not... no big deal... I'll just hack it. And your help and
responsiveness has been incredible. Better than paid support.
Nope - I'm not aware of it (DBD::DB2 isn't my code). Maybe you should
check the very latest version...
http://search.cpan.org/src/IBMTORDB2/DBD-DB2-1.0/Makefile.PL
Looks like it is in there...You can do that just as well as I can, can't
you?
Use the latest version of the code. It often helps.
(Actually, we can debate whether the test is truly correct - it would work
for you because you are using a 64-bit Perl and therefore want the 64-bit
libraries, but if you had a 32-bit Perl, it would still see the 64-bit
libraries and use those, despite the 32-bittiness of Perl.)
Regards, Joe
-Original Message-
*From:* Jonathan Leffler [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, February 08, 2007 2:38 PM
*To:* Wholey, Joseph (GTI)
*Cc:* DBD::DB2 Maintenance Team; DBI Users Mailing List
*Subject:* Re: perl DBD and DBI for 64 bit perl
On 2/8/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote:
You are correct... it is a 32 bit file bear with me...I'm a little
confused by this statement:
You need to distinguish between the database server (which I think your
evidence below shows is the case) and the client software used to connect to
it. The server in question, is the database server.
The parenthetical remark in my sentence wasn't complete - apologies. If
you ignore that, then I said that you simply need to be aware that the
application program (eg Perl + DBI + DBD::DB2) uses a client library to
connect to the database server. It does not include the database server
code in the client program. And that means that the client program can have
a different bittiness from the server. What the parenthetical remark should
have been is (and I think your evidence below shows that the server is a
64-bit server).
Anyway, moving forward, how do I force the compilation of the modules to
go to point to the db2 64bit libraries? Do I need to modify the
Makefile.pl script? Is there an easier way?
Note: the *.1 files are links.
[EMAIL PROTECTED] lib]# locate libdb2.so
/opt/IBM/db2/V8.1/lib/libdb2.so.1
/opt/IBM/db2/V8.1/lib/libdb2.so
/opt/IBM/db2/V8.1/lib64/libdb2.so.1
/opt/IBM/db2/V8.1/lib64/libdb2.so
This is the valuable information...You have the 64-bit libraries; you just
need to persuade Perl to use them.
I don't have the source for DBD::DB2 0.78 on my machine - but I looked at
0.76 instead. In Makefile.PL, there is code to the effect:
# libraries required to build DBD::DB2 driver
if( $os eq 'MSWin32' || $os eq 'MSWin64' || $os eq 'os2' )
{
$sysliblist = qq(-L$DB2/lib db2cli db2api);
my @libpaths = split /;/, $ENV{'LIB'};
my $libpath;
while( @libpaths )
{
( $libpath = shift(@libpaths) ) =~ s///g; # Remove quotes
$libpath =~ s:\\:/:g;
if( $libpath $sysliblist !~ /-L$libpath/i )
{
$sysliblist .= qq( -L$libpath);
}
}
}
else
{
$sysliblist = -L$DB2/lib -ldb2;
}
This needs to be modified, I believe, so the last else clause takes into
account the possibility of a 64-bit Perl. There are various configuration
items that could be used to identify 64-bit Perl:
$Config{use64bitint}
$Config{use64bitall}
$Config{intsize} == 8
$Config{ptrsize} == 8
So, if some suitable values of these are set, you should change
$sysliblist to use -L$DB2/lib64
elsif ($Config{ptrsize} == 8)
{
$sysliblist = -L$DB2/lib -ldb2;
}
With this hacked into Makefile.PL, there's a chance you'll build
correctly.
DBD::DB2 Maintenance Team - please note this suggested change; validate
and fix for the next release of DBD::DB2. Thanks!
Thanks again...
Regards, Joe
-Original Message-
*From:* Jonathan Leffler [mailto:[EMAIL PROTECTED]
*Sent:* Thursday, February 08, 2007 1:14 PM
*To:* Wholey, Joseph (GTI)
*Cc:* DBD::DB2 Maintenance Team; DBI Users Mailing List
*Subject:* Re: perl DBD and DBI for 64 bit perl
On 2/8/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote:
OK... we're making progress... that is a 64 bit db2... maybe there is
a problem with their libraries. Anyway, what from that error I'd sent you
indicates that it's going against a 32 bit db2 lib? btw... I really
appreciate your help on this.
You need to distinguish between the database server (which I think your
evidence below shows is the case) and the client software used to connect to
it.
The evidence from your build suggests that the client software installed
in /opt/IBM/db2/V8.1/lib
(the libdb2.so file in there) is a 32-bit library. You can confirm that
by running the 'file' command on it.
For example:
Anubis JL: cd /usr/lib
Anubis JL: file libc.so
libc.so:ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically
linked, not stripped
Anubis JL: cd sparcv9
Re: perl DBD and DBI for 64 bit perl
On 2/5/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote: I'm trying to track down DBD and DBI for 64 bit perl. Does it exist? If so, can you point me in the right direction? What are you seeking? It exists if you compile it. Do you need help compiling a 64-bit Perl? Compiling DBI with your pre-built 64-bit Perl? Do you want a pre-built 64-bit Perl? If so, for which platform? The version I have on Solaris 8 may not be all that much use to you. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: perl DBD and DBI for 64 bit perl
On 2/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello Jonathan, at the momment I am searching for a pre-built 64-Bit Perl for Solaris 10 Sparc, too. Do you know where one can be found? Thanks for any hints. Have you looked at the Sun sites - http://sun.com/ and/or http://sunsoft.com? Googling 64-bit perl solaris 10 and going a fair way down the first page gets to docs.sun.com and discussions about Perl 5.8.4 and 64-bit. If you simply need to upgrade, use the 'perl -V' output from 5.8.4 as installed as guidance on how to configure 5.8.8. Failing that, is one built on Solaris 8 any use? It uses GCC, is compiled 64-bit, threaded, ithreads, and multiplicity, and installs into /usr/perl/v5.8.8. But frankly, it is simplest just to build your own - I'd worry whether I've got dependencies on /usr/gnu64, for example, which is a necessity on my machine but most people can use /usr/local instead. My technique for ensuring that a build is 64-bit is to use 'gcc -m64' (or with the Sun compiler, 'cc -xarch=sparcv9') as the compiler name; that way, every use of the compiler invokes 64-bittiness. The residual issues are then down to specifying the correct library directories (/usr/lib/sparcv9, IIRC, for example, instead of /usr/lib). -Ursprüngliche Nachricht- Von: Jonathan Leffler [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 6. Februar 2007 00:56 An: Wholey, Joseph (GTI) Cc: dbi-users@perl.org Betreff: Re: perl DBD and DBI for 64 bit perl On 2/5/07, Wholey, Joseph (GTI) [EMAIL PROTECTED] wrote: I'm trying to track down DBD and DBI for 64 bit perl. Does it exist? If so, can you point me in the right direction? What are you seeking? It exists if you compile it. Do you need help compiling a 64-bit Perl? Compiling DBI with your pre-built 64-bit Perl? Do you want a pre-built 64-bit Perl? If so, for which platform? The version I have on Solaris 8 may not be all that much use to you. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: installing DBD-Informix on fedora 6
On 1/29/07, Oliver Howe [EMAIL PROTECTED] wrote: no i dont see anything from that server when running the esqltest. but on the client i can telnet to the server on port 1526 as the user informix. i have stopped iptables and ip6tables on the client can you snoop on the server to see if any packets reach the interface at all when running esqltest? there is some stuff that reaches it :- [...snip...] which seems to be referring to checking the hostnames? hmmail2.uk1.bibliotech.net is the client (running fedora 6) and dbpmuk2.uk1.bibliotech.net is the db server Can you do CREATE TABLE dbd_ix_esqltest (Col01 INTEGER NOT NULL); from dbaccess on the server in the stores database as the appropriate user? yes This is a key issue (connecting with DB-Access on the server machine). The error 107 (discussed in previous emails in this thread) has me a bit puzzled. Does Fedora Core 6 have an error value (from errno.h) for 107? If so, does the associated message drop any hints? Taken at face value, it appears that someone has the database locked in exclusive mode (though I'd like to think the error would say that more clearly). Did the process (session) that created the database complete yet? Classically, you get exclusive access when you create a database, up until you terminate the session that created the DB. When you connect using DB-Access, you are using the same server name and sqlhosts values; you aren't suddenly switching to shared memory connections or anything like that? You're using CSDK 2.90.UC2; that's good. Close enough to the most recent version that it is unlikely to be the cause of the trouble. You seem to be connecting to IDS as either root or informix - frankly, you should do neither. Treat them both with extreme caution - they are just about equally powerful with respect to IDS. I never do things like building DBD::Informix as either informix or root; I'd find (or create) another user to do the work as. If I actually needed to install DBD::Informix as root, I'd use the privileges then, but only then. [Aside: I'm not sure why you feel having DBANSIWARN set is a good idea.] -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: DBD::DB2 Error
On 1/25/07, Brimacomb, Brent [EMAIL PROTECTED] wrote:
When attempting to run a program to access a remote DB2 DB, which
resides on a z/Os box, I've receiving the following error: I've
installed DB2 V9 Windows client. Any one have any ideas?
C:\Perlperl kelen.pl
Operating System = MSWin32
Perl Binary = c:\Perl\bin\perl.exe
Perl Version = 5.008008
DBI Version = 1.53
DBD::DB2 Version = 1.0
DBI connect('DATABASE=USNETAALDSN2; HOSTNAME=dsn2.prdplexa.sabre.com;
PORT=5002;
PROTOCOL=TCPIP; UID=Z156505; PWD=LUVUNIX0;','Z156505',...) failed:
[IBM][CLI Dr
iver] SQL8002N An attempt to connect to a host failed due to a missing
DB2 Conn
ect product or invalid license. SQLSTATE=42968
at kelen.pl line 21
Connection failed with error: [IBM][CLI Driver] SQL8002N An attempt to
connect
to a host failed due to a missing DB2 Connect product or invalid
license. SQLST
ATE=42968
C:\Perl
Can you connect to the DB without Perl - from that machine? I'm not sure
what you get that you might use to do the testing, but it looks as if you
can't connect period - and Perl + DBI + DBD::DB2 can't connect because you
can't connect period, rather than because there is a problem with DBD::DB2
per se. At the least, that would be my starting point - get Perl + DBI +
DBD::DB2 out of the loop and ensure you can connect to the DB without them.
If you can't, maybe you can go to IBM for support on the installation and
configuration of DB2 Connect - no need to mention DBD::DB2.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: most drivers share error variable for sth/dbh handles?
DBD::Informix is careful about errors.
Each statement handle keeps a copy of its most recent status/error
information out of the global sqlca variable (plus the sqlstate variable).
Each database handle has a copy of the most recently executed statement's
error/status information. Of course, this is made more complex by
AutoCommit which requires extra statements to be executed to simulate the
AutoCommit; you have to ignore the status of the extra statements when they
succeed, but record the error if they fail.
On 1/23/07, Martin Evans [EMAIL PROTECTED] wrote:
From the DBI pod under METHODS COMMON TO ALL HANDLES for err:
The DBI resets $h-err to undef before almost all DBI method calls, so
the value only has a short lifespan. Also, for most drivers, the
statement handles share the same error variable as the parent database
handle, so calling a method on one handle may reset the error on the
related handles.
Given the most drivers above I presume some drivers don't share the
error variable for database and statement handles. Which are these
drivers? If you don't know of any, perhaps you can tell me how to find
out whether they do? I did find the following in DBI.pm:
sub _new_drh { # called by DBD::drivername::driver()
my ($class, $initial_attr, $imp_data) = @_;
# Provide default storage for State,Err and Errstr.
# Note that these are shared by all child handles by default! XXX
# State must be undef to get automatic faking in DBI::var::FETCH
my ($h_state_store, $h_err_store, $h_errstr_store) = (undef, 0, '');
The reason I'd like to know is that I have some circumstances where an
error occurs on a statement handle which goes out of scope immediately
so err is not available. I notice the connection handle (with
DBD::Oracle) also contains the same error number/string and this would
be great except for the fact we use multiple DBDs.
Thanks.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: most drivers share error variable for sth/dbh handles?
On 1/23/07, Martin Evans [EMAIL PROTECTED] wrote:
Thanks Jonathan,
Jonathan Leffler wrote:
DBD::Informix is careful about errors.
I would hope all DBDs are ;-)
Each statement handle keeps a copy of its most recent status/error
information out of the global sqlca variable (plus the sqlstate
variable).
Each database handle has a copy of the most recently executed
statement's
error/status information. Of course, this is made more complex by
AutoCommit which requires extra statements to be executed to simulate
the
AutoCommit; you have to ignore the status of the extra statements when
they
succeed, but record the error if they fail.
The 'you' in you have to ignore is 'the writer of DBD::Informix', not the
programmer using DBD::Informix. Sorry if that misled you.
So, I think you are saying that if you executed the following with
DBD::Informix:
my $dbh = DBI-connect({RaiseError=1});
eval {
$dbh-begin_work;
my $sth = $dbh-prepare(q/insert into table values (1)/);
$sth-execute; # execute fails - say duplicate key error
$dbh-commit;
};
$dbh-err here would be what $sth-err was above in the eval after the
execute (assuming you could have looked at $sth-err which you can't in
this case because RaiseError was set).
Yes?
No. $dbh-err would reflect the last statement executed on the $dbh - that
is, the commit, unless the prepare or execute (or begin_work) raised an
error, in which case it would reflect that error.
To demonstrate what I was referring to, consider this context:
my $st1 = $dbh-prepare(...);
my $st2 = $dbh-prepare(...);
$dbh-do('...');
# $dbh-err reflects the 'do'
$st1-execute;
# $st1-err reflects the execute; so does $dbh-err
$st2-execute;
# $st2-err reflects the second execute; so does $dbh-err; but $st1-err
hasn't changed.
$dbh-do('...');
# $dbh-err reflects the second 'do', but neither $st1-err nor $st2-err
has been affected.
The AutoCommit stuff I mentioned is related to the implicit begin work
before the statement and implicit commit work after the statement that
achieve the effect of AutoCommit in a database that doesn't auto-commit
anyway. (I'll go into the gory details if you want - but only after you've
read the DBD::Informix documentation and have questions arising.)
On 1/23/07, Martin Evans [EMAIL PROTECTED] wrote:
From the DBI pod under METHODS COMMON TO ALL HANDLES for err:
The DBI resets $h-err to undef before almost all DBI method calls, so
the value only has a short lifespan. Also, for most drivers, the
statement handles share the same error variable as the parent database
handle, so calling a method on one handle may reset the error on the
related handles.
Given the most drivers above I presume some drivers don't share the
error variable for database and statement handles. Which are these
drivers? If you don't know of any, perhaps you can tell me how to find
out whether they do? I did find the following in DBI.pm:
sub _new_drh { # called by DBD::drivername::driver()
my ($class, $initial_attr, $imp_data) = @_;
# Provide default storage for State,Err and Errstr.
# Note that these are shared by all child handles by default! XXX
# State must be undef to get automatic faking in DBI::var::FETCH
my ($h_state_store, $h_err_store, $h_errstr_store) = (undef, 0,
'');
The reason I'd like to know is that I have some circumstances where an
error occurs on a statement handle which goes out of scope immediately
so err is not available. I notice the connection handle (with
DBD::Oracle) also contains the same error number/string and this would
be great except for the fact we use multiple DBDs.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: environment variable
The solution I proposed works - and I tested it.
#!/bin/perl -w
$ENV{MY_ENVIRONMENT_VARIABLE} = Quixotic Response;
system(env);
However, this is Perl - TMTOWTDI!
If you want to undo the setting after running the shell, either localize
%ENV or delete the new variable.
{
local(%ENV) = %ENV;
$ENV{MY_ENVIRONMENT_VARIABLE} = Quixotic Response;
system(env);
}
or
#!/bin/perl -w
$ENV{MY_ENVIRONMENT_VARIABLE} = Quixotic Response;
system(env);
delete $ENV{MY_ENVIRONMENT_VARIABLE};
Ron's solution won't work unless you are running a sane shell (C shell
doesn't like export, a true Bourne shell doesn't like export with the
assignment!).
And, if you're using a sane shell, you don't need the export, you can simply
write:
system(VAR=val /path/to/your/shell/script);
Well, that worked nicely for me with Korn Shell (and would work with Bourne
Shell), but won't work with C shell (again). You can have multiple
environment variables set if you need to:
system(VAR1=val1 VAR2=val2 /usr/bin/env);
And Scott's response arrived before I sent this but after I'd typed it.
Find Csh Programming Considered Harmful via Google if you don't understand
why C shell is not a good idea.
On 1/19/07, Reidy, Ron [EMAIL PROTECTED] wrote:
Short answer - you cannot (sort of). This is because your shell script
will execute in a sub shell of your perl program.
However, you can do something like this:
# untested
system(export VAR=val; /path/to/your/shell/script.sh);
I think that might work for you.
--
Ron Reidy
Lead DBA
Array BioPharma, Inc.
-Original Message-
From: Oscar Gomez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 17, 2007 8:59 AM
To: dbi-users@perl.org
Subject: environment variable
how can i export a variable from program perl to shell script through
environment
variable.
Thank you
--
Open WebMail Project (http://openwebmail.org)
This electronic message transmission is a PRIVATE communication which
contains
information which may be confidential or privileged. The information is
intended
to be for the use of the individual or entity named above. If you are not
the
intended recipient, please be aware that any disclosure, copying,
distribution
or use of the contents of this information is prohibited. Please notify
the
sender of the delivery error by replying to this message, or notify us by
telephone (877-633-2436, ext. 0), and then delete it from your system.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: environment variable - Mea Culpa
On 1/19/07, Jonathan Leffler [EMAIL PROTECTED] wrote: The solution I proposed works [...] I sent it on the 17th. Unfortunately, I only sent it to Oscar, not to dbi-users as well. Sorry - my mistake - both then and earlier today. This subject should now be closed. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Help Required:Installing DBI in Perl 5.005
Why don't you do the sensible thing and upgrade to Perl 5.8.8? Presumably, you have a reason that seems sensible to you - though if you've not considered the option, you should do it, and do it now (where 'do' encompasses both 'think about installing Perl 5.8.8' and 'actually install Perl 5.8.8'). Assuming you can't upgrade (what was the reason again? you're kidding - you could upgrade!) you'll probably need to dig through the release notes for DBI to find the last version that supports Perl 5.5, and then obtain that source manually from the CPAN archive (not by trying to use CPAN or CPANPLUS modules). Then you'll need to obtain a compatible version of DBD::Oracle, and install that. You can find DBI modules back to 1.13 at http://www.cpan.org/modules/by-authors/id/TIMB/ The Oracle versions only go back to 1.14 - and may not cover the latest ones either; you can hunt those down yourself. On 1/18/07, Mohd Naim [EMAIL PROTECTED] wrote: Dear Friends, I am not having much experience in Perl except from programming. I have Perl 5.005 in Unix environment.I have no issues with running any PErl Script. But I cant access my Oracle Database(92) through Perl Script. Its throwing error *Can't locate object method connect via package DBI* *Can't locate dbi.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4-solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 .) at PerlDatabaseConnection.pl line 10.* Please let me know which version of DBI shud I install and where can I get this. If we dont have Perl5.005 compatible DBI in market; then what is the other alternative... I also have posted the same in http://www.cpanforum.com/posts/4081 Regards Naim Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris uname='sunos localhost 5.8 sun4u sparc sunw,ultra-1 ' hint=previous, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-xO3 -xdepend', gccversion= cppflags='' ccflags ='' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='' libpth=/lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc -lcrypt libc=/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-R /usr/perl5/5.00503/sun4-solaris/CORE' cccdlflags='-KPIC', lddlflags='-G' Characteristics of this binary (from libperl): Built under solaris Compiled at Dec 22 1999 00:00:57 @INC: /usr/perl5/5.00503/sun4-solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Positively Archaic Versions of DBI and DBD::Oracle
On 1/18/07, Peter J. Holzer [EMAIL PROTECTED] wrote: [...interesting stuff deleted...] You can find DBI modules back to 1.13 at http://www.cpan.org/modules/by-authors/id/TIMB/ The Oracle versions only go back to 1.14 - and may not cover the latest ones either; you can hunt those down yourself. You can find even older versions on BackPAN: http://backpan.cpan.org/authors/Tim_Bunce/ starts with DBI-0.89 and DBD-Oracle-0.47 from 1997. Only that far back? Would they be interested in DBI versions 0.69, 0.73, 0.74, 0.75, 0.77, 0.78, 0.79, and 0.81..0.88 too? I have them stashed away... I also have DBD::Oracle 0.43..0.46 too. I'd be happy to give them - ideas on who to contact? I don't see any information on who or how to submit such stuff at http://backpan.cpan.org/ - that just gives a directory listing. For DBD::Informix, I have all released (and probably some unreleased) versions back to 0.23, but they already seem to have those (or enough that the difference is unlikely to matter). The versions prior to 0.25 are under Alligator Descartes' directory, not mine. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Error returned on Unix 'mv' system call.
If rename works and mv doesn't, use rename everywhere.
It is quicker, simpler, less insecure, and more consistent too. Actually, I
can't think of a reason to keep mv around.
On 1/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
I am migrating an Oracle 9i to Oracle 10g database, and Perl 5.0.4 to
Perl 5.8.7 in Sun Solaris environment.
Using Perl 5.8.7, the following legacy code segment is returning a '-1'
return code on the system call to execute the 'mv' command. Note that
the mv request is across directories.
sub move_inproc
{
print sub move_inproc\n;
`mv $histhome/dat/inbound/$filename $histhome/dat/inproc/$filename`;
if ($? !=0)
{
fatal_error (913, ERROR - Cant Move
$histhome/dat/inbound/$filename to $histhome/dat/inproc);
}
else
{
log_msg(000, File $filename successfully moved to
$histhome/dat/inproc dir);
}
Interestingly, when the code executes the fatal_error routine the Perl
rename function works fine (also across directories).
sub fatal_error
{
...
rename ($histhome/dat/inproc/$filename,
$histhome/dat/inbad/$filename);
if ($? !=0)
{
log_msg (523, WARNING - Cant Move
$histhome/dat/inproc/$filename to $histhome/dat/inbad);
}
else
{
log_msg(000, File $filename moved to $histhome/dat/inbad
dir);
...
}
I can find no reason why the system call to the 'mv' command fails, and
the Perl 'rename' function works, and better yet, why the 'mv' system
call is used in one sub-module, and the Perl 'rename' function in
another sub-module.
I am planning on replacing the 'mv' system call with the Perl 'rename'
function, unless of course you experts out there tell me different.
Comments welcome; thanks,
Mark Cummings
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Type ulong not defined on MacOS X 10.4.8 for DBD::MySQL 4.00
Running [/Users/jleffler/perl/v5.8.8/bin/perl /Users/jleffler/perl/v5.8.8/bin/cpanp-run-perl Makefile.PL ]... I will use the following settings for compiling and testing: cflags(mysql_config) = -I/usr/local/mysql/include -fno-common embedded (mysql_config) = libs (mysql_config) = -L/usr/local/mysql/lib -lmysqlclient -lz -lm mysql_config (guessed ) = mysql_config nocatchstderr (default ) = 0 nofoundrows (default ) = 0 ssl (guessed ) = 0 testdb(default ) = test testhost (default ) = testpassword (default ) = testsocket(default ) = testuser (default ) = To change these settings, see 'perl Makefile.PL --help' and 'perldoc INSTALL'. Checking if your kit is complete... Looks good Using DBI 1.53 (for perl 5.008008 on darwin-2level) installed in /Users/jleffler/perl/v5.8.8/lib/site_perl/5.8.8/darwin-2level/auto/DBI/ Writing Makefile for DBD::mysql Running [/usr/bin/make ]... cp lib/DBD/mysql.pm blib/lib/DBD/mysql.pm cp lib/DBD/mysql/GetInfo.pm blib/lib/DBD/mysql/GetInfo.pm cp lib/DBD/mysql/INSTALL.pod blib/lib/DBD/mysql/INSTALL.pod cp lib/Bundle/DBD/mysql.pm blib/lib/Bundle/DBD/mysql.pm cc -c -I/Users/jleffler/perl/v5.8.8/lib/site_perl/5.8.8/darwin-2level/auto/DBI -I/usr/local/mysql/include -fno-common -DDBD_MYSQL_INSERT_ID_IS_GOOD -g -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -O3 -DVERSION=\4.00\ -DXS_VERSION=\4.00\ -I/Users/jleffler/perl/v5.8.8/lib/5.8.8/darwin-2level/CORE dbdimp.c dbdimp.c: In function 'mysql_dr_connect': dbdimp.c:1710: error: 'ulong' undeclared (first use in this function) dbdimp.c:1710: error: (Each undeclared identifier is reported only once dbdimp.c:1710: error: for each function it appears in.) dbdimp.c:1710: error: parse error before numeric constant make: *** [dbdimp.o] Error 1 Do you need any help identifying which header should be used to get 'ulong' defined? It isn't immediately obvious to me: $ grep -l ulong /usr/include/*.h /usr/include/*/*.h /usr/include/slapi-plugin.h /usr/include/i386/types.h /usr/include/openssl/x509v3.h /usr/include/php/acconfig.h /usr/include/ppc/types.h /usr/include/tidy/fileio.h /usr/include/tidy/platform.h /usr/include/tidy/tidy.h $ -- Jonathan Leffler ([EMAIL PROTECTED]) #include disclaimer.h Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
Re: Unix: Oracle User Identified Externally
On 12/20/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tried this, but still not working. DO you know how to determine which version of DBI you are using? Alternatively (to DBI-installed_versions): perl -MDBI -e 'print $DBI::VERSION\n;' Your original connection notation - with the driver name as the fourth argument - is really old. It was deprecated a long time before the turn of the millennium. I don't know enough about Oracle connection notations to know how to help with slash vs anything else for an externally identified user. It seems logical to me that you'd provide the external user name to the connect string - but that's just what I'm used to on other DBMS. -Original Message- From: Reidy, Ron [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 11:10 AM [...] Shouldn't the password be blank? $dbh = $DBI-connect(dbi:Oracle:, /, , ...); This is what I use for SYS connections, analogous to using the SQL*Plus command 'connect / as sysdba'. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 10:58 AM To: dbi-users@perl.org Subject: Unix: Oracle User Identified Externally I am migrating an Oracle 9i to Oracle 10g database, and Perl 5.0.4 to Perl 5.8.7 in Sun Solaris environment. My old Perl/DBI script was able to connect via this method: use DBI; $dbd = 'Oracle'; $user = '/'; $password = '/'; $dbh = DBI-connect ($dbname, $user, $password, $dbd); This is not working with new version of Perl/DBI. I have changed script to connect correctly: use DBI; $dbd = 'Oracle'; $user = 'scott'; $password = 'tiger'; $dbh = DBI-connect (dbi:$dbd:$dbname,$user, $password); But need to be able to connect with user identified externally (as before). I cannot find documentation on proper syntax or if a fix was made in later version of DBI. Can anyone help? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Perl lib version not match executable version
On 12/11/06, Chong, Wei-Ling [EMAIL PROTECTED] wrote: The same perl script put in other server, does not have this kind of problem, it is not perl script html problem. It sounds like there are two perl versions and conflict with Oraperl. Please help. How can we possibly help? You need to ensure that the correct version of Perl is used by whatever is working with your module. Clearly, there is something different about the setup between the two machines; if there was no difference, you'd get the same behaviour on both. You need to find that difference, and fix the machine where things are broken to match the machine where things work. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Perl lib version not match executable version
On 12/8/06, Hardy Merrill [EMAIL PROTECTED] wrote: You may have more than one problem, [...one problem explained...] On 12/8/2006 at 1:33 AM, Chong, Wei-Ling [EMAIL PROTECTED] wrote: I have Solaris 5.8 (x86) server and running Oracle Application Server, I install perl-5.8.7-sol10-x86-local.gz. When I run my perl script, I am getting error below. How to resolve the problem? [Fri Dec 8 14:18:45 2006] [error] [client 165.204.172.185] [ecid: 1165558725:165.204.178.145:8267 :0:37,0] Premature end of script headers: /oracle/app/oracle/eq/web/cgi/ppcd/ppcd_approval_ora.pl Perl lib version (v5.6.1) doesn't match executable version (v5.8.7) at /oracle/app/oracle/product/ oas10.1.2.0.2/perl/lib/5.6.1/i86pc-solaris/Config.pm line 21. Compilation failed in require at /oracle/app/oracle/product/oas10.1.2.0.2/perl/lib/5.6.1/i86pc-sol aris/DynaLoader.pm line 25. [...] And for the rest, note that 5.6.1 in the Oracle pathway - it isn't the same as 5.8.x that you're using. Either downgrade to Perl 5.6.1 or upgrade the Oracle stuff to Perl 5.8.x. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Retrying a fetch after an error, without restarting the whole loop?
On 11/9/06, Bart Lateur [EMAIL PROTECTED] wrote:
On Wed, 8 Nov 2006 23:26:02 -0800, Jonathan Leffler wrote:
Bart Lateur [EMAIL PROTECTED] asked:
And 2), in a fetch loop, is it possible to adjust a property like
{ReadLongLen}, and retry the same fetch without restarting the whole
loop? Because this error typically happened several minutes into the
loop.
Highly unlikely. The data has been fetched - and truncated. There's not
usually a way to refetch the same row - unless you have a scroll cursor,
and
DBI doesn't have support for those.
I can see that. Well I'm thinking of the following solution next:
retrieve extra data to identify the row that went wrong and collect
them, keep going on with the rest of the records, and individually fetch
the previously failed ones afterwards.
After a failure, I can go on with the next records, can't I? And
changing ReadLongLen, is that acceptable for the remainder of the loop?
That works - I've used it in (non-Perl) code for aeons (dating back to
1986). The primary demerits are (1) two fetches for each row, and (2)
establishing the unique identifier column or columns for the data.
And yes, I can think of no reason why a driver that honours ReadLongLen
would not adapt to changed values as the loop continues. Since
DBD::Informix doesn't pay attention to ReadLongLen in the first place, it
isn't much use looking at that code - and other driver writers would have to
answer for their code.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: Bind variable question
On 11/9/06, Berlage, Steve [EMAIL PROTECTED] wrote: Here is what I am trying to do: $UPDATE_COMPANY_STRING = ccompStreet = ?; $UPDATE_COMPANY_VALUE_STRING = \$tmpccompStreet; $sql=UPDATE clientcomp SET $UPDATE_COMPANY_STRING WHERE ccompid = ?; $sthUpdate = $dbh-prepare($sql); $sthUpdate-execute($UPDATE_COMPANY_VALUE_STRING, $tmpstcompid); Obviously there are many more fields that _may_ be added to the 2 variables that are in all caps (I only showed 1 for simplicity). I only add the fields that need to be updated to those 2 variables. It does what I expect it to do except for the last line. I want the $UPDATE_COMPANY_VALUE_STRING to be expanded to the actual string it contains before the execute is run. I've tried a bunch of different ways to make it happen - all to no avail. I either get errors or end up with $tmpccompStreet in the database (instead of the value that $tmpccompStreet contains). Hopefully it's clear what I'm trying to accomplish here. Please be kind - I'm relatively new to pl/sql :) I think you have the wrong data structure for the value string - what you need is an array of values, with the ccompid value at the end and the other values in sequence. So, build the SQL statement one item at a time and add the corresponding value to an array. You then pass the array to the $sth-execute() call. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Retrying a fetch after an error, without restarting the whole loop?
On 11/8/06, Bart Lateur [EMAIL PROTECTED] wrote:
I've been saving picture files that had been stored in a blob field in
an MS-Access database (aka an OLE Object) to files, and I've bumped
onto some LongReadLen related problems: through trial and error I
finally succeeded in making LongreadLen long enough to reliable extract
all the files. (in Access, the function LEN on such a field reports a
size that's half the number of bytes. Apparently it mistakes it for
Unicode text. I haven't found a better suited function than LEN, though
I haven't searched hard).
Anyway; as this was a process of several minutes, it took some time to
fix the script and start all over.
So I was wondering these two things:
1) What's the best way to temporarily disable RaiseError when I want to
have it enabled for the rest of the script? Say, for one SQL statement?
$sth-{RaiseError} = 0;
Or:
$dbh-{RaiseError} = 0;
$dbh-do(something that might fail);
$dbh-{RaiseError} = 1;
And 2), in a fetch loop, is it possible to adjust a property like
{ReadLongLen}, and retry the same fetch without restarting the whole
loop? Because this error typically happened several minutes into the
loop.
Highly unlikely. The data has been fetched - and truncated. There's not
usually a way to refetch the same row - unless you have a scroll cursor, and
DBI doesn't have support for those.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: DBD::Informix $SIG{ALRM} /etc/services
On 11/3/06, Jay Hannah [EMAIL PROTECTED] wrote: Oops. I noticed my versions were behind. I upgraded DBI and DBD::Informix. I'm still getting the same behavior (14.3 seconds to time out), so I'm still curious about what might be going on. CSDK probably uses alarm itself - for connection timeouts, no less - so your attempt to use alarm at the same time is likely to cause confusion somewhere. You could probably track this with the equivalent of truss (strace on Linux?), looking for alarm system calls in the output. You'd probably be able to identify your own alarm(2) call; you might have to work harder to identify which other alarm() calls are made before you see SIGALRM fire. Interestingly, the manual page for the system call is usually designated alarm(2) as well as you using an alarm function call with the argument value 2. $ perl -MDBI -e'DBI-installed_versions' Perl: 5.008004(i686-linux) OS : linux (2.6.4-52-smp) DBI : 1.53 DBD::Sybase : 1.04 DBD::Sponge : 11.10 DBD::Proxy : install_driver(Proxy) failed: Can't locate RPC/PlClient.pm in @INC DBD::Informix : 2005.02 DBD::File : 0.35 DBD::ExampleP : 11.12 DBD::DBM: 0.03 -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: (Fwd) plzzz help me out
On 9/12/06, Tim Bunce [EMAIL PROTECTED] wrote: - Forwarded message from srilata devineni [EMAIL PROTECTED] - I installed Active perl and DBImodule, DBD:: SQLite, DBD ::odbc, SQLserver 2000 now how to connect to sql server 2000 ,through perl script ,not throudg odbc connection .. is there any way? .. Why do you not want to use ODBC? What would you rather use, and why? The only relevant ways as far as this mailing list are concerned are via DBI and DBD::ODBC. If you want to devise or obtain an alternative, go to http://search.cpan.org/ to investigate your options. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Problem with DBI make
On 9/4/06, John Gallagher [EMAIL PROTECTED] wrote: I've just run make again and included the output The system I'm trying to install DBI on is a hp-ux 11.11 And the version of perl installed is 5.8.7 (Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 422: Unknown option f ignored. (Bundled) cc: warning 480: The +Onolimit option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Opromote_indirect_calls option is available only with the C/ANSI C product; ignored. (Bundled) cc: warning 480: The +Z option is available only with the C/ANSI C product; ignored. cpp: /opt/perl_32/lib/5.8.7/PA-RISC1.1-thread-multi/CORE/perlio.h, line 108: error 4065: Recursion in macro PerlIO. *** Error exit code 1 You're using the bundled C compiler which is not an ANSI C compiler. Your Perl was built with the HP ANSI C compiler. Either: get the HP ANSI C compiler Or: get GCC and build your own Perl with it. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Getting DBD::Oracle tests working
On 9/1/06, Karl Auer [EMAIL PROTECTED] wrote: Is 'scott/tiger' some well-known user/password that is always present in any Oracle install? It is a default login - but sensible Oracle admins either change the password or disable (remove?) the account altogether. See Database Hacker's Handbook for more information. See also Ron Ben-Natan's Implementing Database Security and Auditing. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: GOOD NEWS: Re: perl DBI-1.51 install error .... Math Libraries
Paul, If you need more help, you neded to go back to DBI or a Perl news group. I'm on vacation for the next two weeks, starting in less than an hour. On 7/22/06, Paul Adelaide [EMAIL PROTECTED] wrote: Now I am able to successfully install and compile perl on my box to: /usr/opt/perl5.8.8. perl 5.8.8 64bit ./Configure -de -Dcc=gcc -Duse64bitall make make test make install ---Successful DBI 1.46 !!Make sure you are using the newly installed perl!! check with perl -v it should show : This is perl, v5.8.6 built for aix-64all perl Makefile.PL make make test make install --? Next question: what is the best method to include this path for the DBI module install? Thanks [EMAIL PROTECTED] | mobile: 301.537.5929 - Original Message From: Paul Adelaide [EMAIL PROTECTED] To: Jonathan Leffler [EMAIL PROTECTED] Sent: Saturday, July 22, 2006 7:49:26 AM Subject: Fw: perl DBI-1.51 install error Math Libraries Also, the math libraries? Explain where I need to incorporate it in the2 steps below. [EMAIL PROTECTED] | mobile: 301.537.5929 - Forwarded Message From: Paul Adelaide [EMAIL PROTECTED] To: Jonathan Leffler [EMAIL PROTECTED] Sent: Saturday, July 22, 2006 7:46:47 AM Subject: Re: perl DBI-1.51 install error Ok I will start all over again. The following are the steps I need to take right? I am going to re-compile perl to new location: /usr/opt/perl5.8.8. Two things I would appreciate from you: 1. Can you modify the steps to indicate where I need to change to ensure I create perl in the new location. 2. Ensure that I use the path for the new perl (/usr/opt/perl5.8.8) in the DBI install Thanks. perl 5.8.8 64bit ./Configure -de -Dcc=gcc -Duse64bitall make make test make install DBI 1.46 !!Make sure you are using the newly installed perl!! check with perl -v it should show : This is perl, v5.8.6 built for aix-64all perl Makefile.PL make make test make install [EMAIL PROTECTED] | mobile: 301.537.5929 - Original Message From: Jonathan Leffler [EMAIL PROTECTED] To: Paul Adelaide [EMAIL PROTECTED] Sent: Friday, July 21, 2006 9:37:23 PM Subject: Re: perl DBI-1.51 install error On 7/21/06, Paul Adelaide [EMAIL PROTECTED] wrote: Thanks for the response. So I should use 32bit of perl, right? Also the intent is to access Oracle 10g which is 64bit (I am counting on the DBD that came with Oracle -- so need to include that in the perl module install). OK - I would agree with you that the Perl for a 64-bit Oracle should probably be a 64-bit Perl. And the more I looked at the problem, the more convinced I am that you just needed to add -lm to the list of libraries (and I'm surprised that Perl's Configure script didn't do that anyway). At some point in the configuration, you get to specify libraries and you should add -lm to that list. You could poke around at the Oracle documentation to see what it tells you - about 64-bit vs 32-bit. I don't know enough about Oracle client software to be able to tell what applies with certainty. Jonathan I am new at this... Can you please shed more light on this for me, thanks. [EMAIL PROTECTED] | mobile: 301.537.5929 - Original Message From: Jonathan Leffler [EMAIL PROTECTED] To: Paul Adelaide [EMAIL PROTECTED] Sent: Friday, July 21, 2006 8:14:15 PM Subject: Re: perl DBI-1.51 install error Your original Perl was 32-bit, not 64-bit. That might make things better. The other question is whether you've been able to build any program using the maths functions and not including the -lm (ell, em) flag. They're all maths library functions. Since -lm is not listed, that may be the trouble. On 7/21/06, Paul Adelaide [EMAIL PROTECTED] wrote: perl 5.8.8 64bit -- ./Configure -de -Dcc=/usr/bin/gcc -Duse64bitall - seems OK make -- Failed see below .o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o | sed 's/ op.o / /'` miniperlmain.o opmini.o perl.o -lbind -lnsl -ldl -lld -lcrypt -lc -lbsd ld: 0711-317 ERROR: Undefined symbol: .pow ld: 0711-317 ERROR: Undefined symbol: .floor ld: 0711-317 ERROR: Undefined symbol: .fmod ld: 0711-317 ERROR: Undefined symbol: .atan2 ld: 0711-317 ERROR: Undefined symbol: .sin ld: 0711-317 ERROR: Undefined symbol: .cos ld: 0711-317 ERROR: Undefined symbol: .exp ld: 0711-317 ERROR: Undefined symbol: .log ld: 0711-317 ERROR: Undefined symbol: .sqrt ld: 0711-317 ERROR: Undefined symbol: .ceil ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: 1254-004 The error code from the last command is 1. [EMAIL PROTECTED] | mobile: 301.537.5929 - Original Message From
Re: perl DBI-1.51 install error ....
On 7/19/06, Paul Adelaide [EMAIL PROTECTED] wrote: I am trying to install perl DBI-1.51 on an aix 5+ with oracle 10g client; and I am getting the following error. Please help. thread-multi/CORE Perl.c/bin/sh: cc_r: not found. make: 1254-004 The error code from the last command is 127. This is the first module you've added (that needs a C compiler)? The Perl you're using was built with a compiler you don't have. Either obtain the compiler used to build Perl (possibly by fixing your PATH) or build Perl with the compiler you have. Anything much else won't work. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: (Fwd) dbh handle in forked processes
On 7/19/06, Tim Bunce [EMAIL PROTECTED] wrote: - Forwarded message from Gene Zhang [EMAIL PROTECTED] - I've an issue with programming DBI and could not find a solution in either your DBI slideshow: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/index.htm or your book Programming the Perl DBI; was hoping you could provide some guidance: I have a program that establishes a $dbh, but then forks multiple child processes, all of which use the same $dbh for queries and then terminate (the process). I'd like to use the same $dbh connection handle for each child process but as soon as one child exits, the handle is lost. Is the best solution to use connect_cached? No; the best solution is to connect in each child process. Anything else is unreliable. I'm pretty sure this is covered in 'perldoc DBI' - it certainly should be. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: make error: 127 for DBI module on AIX 5.2 (DBD::Informix)
On 7/20/06, Jordan Smith [EMAIL PROTECTED] wrote: I am attempting my first Perl module install to get my Informix-backed CGI site up and running. The CPAN.pm install failed because of some firewall issue so I have the tarball unpacked but the make command fails with this message: /bin/sh: cc_r not found 1254-004: error code 127 We're running perl 5.8.2, the threaded version and AIX 5.2. No one in the department remembers installing Perl and how they did it or with what options. I am new to Unix, so I'm happy to get more system information if someone will tell me what they need, how to get it, etc. Any assistance would be greatly appreciated. Most likely, your Perl was distributed with AIX - well, if it is in /bin or /usr/bin, that is almost certainly true; if it is in /usr/local/bin or some other location, maybe someone on your team did build it. However it was built, you need to have the same compiler - cc_r - available to you now. If the compiler is on the machine, fix your PATH. If it is not on the machine, install it. If that is not possible, then you'll need to get hold of a different C compiler and build and install your own copy of Perl using that compiler, and then you can build and install DBI and DBD::Informix. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: memory leak in DBI ...
On 7/17/06, Ephraim Dan [EMAIL PROTECTED] wrote:
Can someone else try to reproduce a memory leak in a simple
connect/prepare/execute/disconnect loop using DBI 1.51 and any DBD driver?
I created a test program using the test harness distributed with
DBD::Informix and found a small but gentle leak. Over a period of multiple
thousand connections, the Perl executable grew from 866 KB to 973 KB, and
showed no signs of stopping. Is that what you were looking for? (In an
Informix database, the Systables system catalog table is always present.)
This was tested with DBI 1.50 on Solaris 8 (and Perl 5.8.7 - I won't bore
you with why it wasn't 5.8.8). I upgraded to DBI 1.51 (same DBD::Informix
2005.02) and got the same basic result, with Perl growing from 869 to 903
over 2000 iterations.
#!/bin/perl -w
#
# Memory leak test per Ephraim Dan
use strict;
use DBD::Informix::TestHarness;
my $conn_count = 0;
sub test_connection
{
$conn_count++;
my $dbh = connect_to_test_database({ AutoCommit = 0, RaiseError = 1,
PrintError = 1 });
my $sth = $dbh-prepare(SELECT * FROM Systables);
$sth-execute;
$dbh-disconnect;
}
sub test_subroutine
{
while (1)
{
test_connection;
print Connections: $conn_count\n if ($conn_count % 1000 == 0);
}
}
memory_leak_test(\test_subroutine);
exit;
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: Problem on AIX
.
/usr/include/stdlib.h, line 91.15: 1506-276 (S)
Syntax error: possible missing '{'?
/usr/include/sys/time.h, line 91.9: 1506-045 (S)
Undeclared identifier time_t.
/usr/include/sys/time.h, line 93.9: 1506-045 (S)
Undeclared identifier suseconds_t.
/usr/include/sys/time.h, line 103.5: 1506-046
(S) Syntax error.
/usr/include/sys/time.h, line 105.1: 1506-278
(S) The structure definition must specify a member list.
/usr/include/sys/time.h, line 115.1: 1506-278
(S) The structure definition must specify a member list.
/usr/include/sys/time.h, line 123.25: 1506-007
(S) struct timeval is undefined.
/usr/include/sys/time.h, line 124.25: 1506-007
(S) struct timeval is undefined.
/usr/include/sys/time.h, line 273.9: 1506-046
(S) Syntax error.
/usr/include/sys/time.h, line 275.1: 1506-278
(S) The structure definition must specify a member list.
Failed to compile
esqltest.ec to esqltest.o
#
Cordialement – Kind Regards
Jérôme PELLETIER
Ingénieur projet
Logon S.I. France
16, Avenue des
Châteaupieds
92565
Rueil-Malmaison Cedex
Tél:
+33 (0)1 47 51 97 54
GSM:
+33 (0)6 09 57 52 32
Fax:
+33 (0)1 47 51 94 12
Email:
[EMAIL PROTECTED]
http://www.logonsi.com
Disclamer
Ce message ainsi que les éventuelles
pièces jointes constituent une correspondance privée et confidentielle
à l'attention exclusive du destinataire désigne ci-dessus. Si vous
n'êtes pas le destinataire du présent message ou une personne susceptible de
pouvoir le lui délivrer, il vous est signifié que toute divulgation,
distribution ou copie de cette transmission est strictement interdite. Si
vous avez reçu ce message par erreur, nous vous remercions d'en informer
l'expéditeur par téléphone ou de lui retourner le présent message, puis
d'effacer immédiatement ce message de votre système
***
This e-mail and any
attachments is a confidential correspondence intended only for use of the
individual or entity named above. If you are not the intended recipient or the
agent responsible for delivering the message to the intended recipient, you are
hereby notified that any disclosure, distribution or copying of this
communication is strictly prohibited. If you have received this communication
in error, please notify the sender by phone or by replying this message, and
then delete this message from your system.
-- Jonathan Leffler [EMAIL PROTECTED]#include disclaimer.hGuardian of DBD::Informix - v2005.02
- http://dbi.perl.orgI don't suffer from insanity - I enjoy every minute of it.
Re: [dbi] Execute marks end of transaction?
On 7/11/06, Martin J. Evans [EMAIL PROTECTED] wrote:
On 11-Jul-2006 Jimmy Li wrote:
Can I end a transaction as soon as I call execute()?
Yes
Depends on the statement, of course, and the AutoCommit mode. For something
other than a cursor-based statement (fetch, or sometimes some versions of
SQL function calls), that will terminate the transaction immediately if
AutoCommit is on.
or do I have to wait
until I finish fetching all the rows?
No
For example, I have:
--
$dbh-do(start transaction);
my $groups_query = $dbh-prepare(qq{select id, name from
staff_grp});
$groups_query-execute;
# place1
$groups_query-finish if (want_to_stop_here);
That finishes the statement (or closes the cursor) - it does not directly do
anything to the transaction. To finish the transaction, you call
$dbh-commit or $dbh-rollback. If AutoCommit is on, then maybe the
transaction is completed on finish.
while (my @one_group = $groups_query-fetchrow_array)
{
print @one_group;
}
#place 2
--
Can I end the transaction in #place1 or do I have to wait until #place2?
See above.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: CURSOR WITH UPDATE
$sth-{CursorName} is a key part of it.
See also the docs for DBD::Informix (http://search.cpan.org/) for an example
- the POD has a section CURSORS FOR UPDATE that shows how to do it.
On 7/11/06, pDale [EMAIL PROTECTED] wrote:
From looking around with Google, it would APPEAR that you can
implement a cursor WITH UPDATE in DBI, but I have not been able to
find an example of that. Would anyone happen to have a bare-bones
code framework for such a thing?
Since I should give an example of the kind of operation I hope to do...
__CODE__
my $db; # database connection
my $match = ^H[ae];
my $stmt = SELECT foo,bar,fee FROM baz FOR UPDATE OF bar, fee;
my $sth;
die( \nFailed preparing SELECT:\n$db-errstr\n )
if !( $sth = $db-prepare($stmt) );
die( \nFailed executing SELECT:\n$db-errstr\n )
if !$sth-execute();
while ( my ( $foo, $bar, $fee ) = $sth-fetchrow_array )
{
next if $foo !~ /$match/;
$db-do( UPDATE baz SET bar=3,fee='fie' WHERE CURRENT OF
$sth-cursor)
or die( UPDATE FAILED: $sth-errstr\n);
}
$sth-finish;
__CODE_ENDS__
Of course, $sth-cursor don't really exist (as far as I know).
TIA!
--
pDale Campbell
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: DBD::Informix on Solaris
-ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at Dec 2 2005 01:34:16 @INC: /usr/local/lib/perl5/5.8.7/sun4-solaris /usr/local/lib/perl5/5.8.7 /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl esql -v --- IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.FC4 Software Serial Number AAA#B00 dbaccess -V DB-Access Version 9.21.UC6 Software Serial Number AAD#J179567 Govinda Pfister Remedy Approved Consultant, Clarify Certified Consultant, ITIL-Certified Projectcenter Business Process Solutions Solution Service Center Business Enabling Solutions Global Competence Center T-Systems Enterprise Services GmbH Memmelsdorfer Str. 209a, 96052 Bamberg +49 951 4097-161 (Tel) +49 951 4097-200 (Fax) E-Mail: Govinda.Pfister mailto:[EMAIL PROTECTED] @ t-systems.com Internet: http://www.t-systems.com/ http://www.t-systems.com -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: DBD::Informix on Solaris
On 7/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have a working informix environment with DBI and DBD::Informix. (see
details for version, configuration below).
I do have the problem that I cannot get the serial after a insert
statement is executed.
I always get '0' back. In the database each inserted record gets a unique
number assigned.
Why?
Answer 2...
Looking at the code in t/t10sqlca.t, there is code there that carefully
checks that the serial number stuff works. So, first question, did you run
that test and did it pass? I believe the answer to both will be yes, but
I'll ask anyway.
The other potentially significant detail is that the code in t/t10sqlca.t
tests $dbh-{ix_sqlerrd}[1] and not $sth-{ix_sqlerrd}[1] as in your code.
However, in your defense, the documentation in 'perldoc DBD::Informix'
clearly shows $sth-{ix_sqlerrd}[1] and not the $dbh version, though it says
you can get the information from either. The QA suite does not appear to
validate that; however, the print_sqlca method (part of
DBD::Informix::TestHarness) is called with statement handles. So, we should
validate that what is printed by print_sqlca and a statement handle matches
what is validated by the database handle.
The code is as follows:
--
[...]
else{
my $id = $sth-{ix_sqlerrd}[1];
[...]
--
Bugreport-Info:
perl -V
---
Summary of my perl5 (revision 5 version 8 subversion 7) configuration:
Platform:
osname=solaris, osvers=2.8, archname=sun4-solaris
uname='sunos solaris 5.8 generic_108528-11 sun4u sparc sunw,ultra-5_10
'
config_args='-Dcc=gcc -B/usr/ccs/bin/'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc -B/usr/ccs/bin/', ccflags ='-fno-strict-aliasing -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O',
cppflags='-fno-strict-aliasing -pipe -I/usr/local/include'
ccversion='', gccversion='3.3.2', gccosandvers='solaris2.8'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=8, prototype=define
[...]
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: Possible to get field names and types in a table without executing a query?
On 6/27/06, Matthew Persico [EMAIL PROTECTED] wrote: So now I need one for every database? Yes - and there a DBMS that make you do that the hard way, with raw access to the system catalog. Despite the prior thread entry refering to select * from table where 0 = 1 as a hack in the 'bad' sense, I suggest that this is a hack in the 'good' sense. It is much more easily portable. Suppose you have a real query: select a.foo, b.bar.c.baz from a, b, c where . The 0= 1 method works for that too. Contrast that with parsing the from clause and the where clause to create a tabel catalog query. Yuk. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: DBI/DBD::DB2
On 6/23/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
Hello,
I am trying to write a perl script to connect to our DB2 database and
do some basic SQL queries. But I'm having trouble with making
everything play nice.
I'm on WinXP, and did a manual build of DBI with Visual Studio's
nmake. That all went fine (as far as I can tell). So I downloaded the
DBD::DB2 module and unzipped it to my C:/Perl/lib directory (creating
the blib directory from the use lib line below. Here's the code I'm
trying to test it with...
Normally, you don't compile a module in the Perl install tree - you compile
it some other place and install it into the tree.
So, did you obtain a pre-compiled copy of DBD::DB2?
If so, do you have the necessary support libraries installed?
use lib 'c:/Perl/lib/blib/lib/Bundle';
I'm dubious in the extreme about this line (above).
use DBI;
### Probe DBI for the installed drivers
my @drivers = DBI-available_drivers();
die No drivers found!\n unless @drivers; # should never happen
### Iterate through the drivers and list the data sources for
### each one
foreach my $driver ( @drivers ) {
print Driver: $driver\n;
my @dataSources = DBI-data_sources( $driver );
foreach my $dataSource ( @dataSources ) {
print \tData Source is $dataSource\n;
}
print \n;
}
And here is the output:
DBD::DB2 initialisation failed: Can't locate object method driver via
package DBD::DB2 at c:/Perl/site/lib/DBI.pm line 768.
Perhaps the capitalisation of DBD 'DB2' isn't right. At
C:..dbQueryAutoBatch.pl line 33.
If you have a pre-compiled module, then I think your problem is the absence
of DB2 Connect (IIRC) or its equivalent.
If you don't have a pre-compiled module, then your problem is that you need
to compile and install it - and compile it in any directory that is not
underneath the Perl install directory hierarchy.
Not sure if DBI or DBD::DB2 arne't right or I'm just calling something
wrong. But any help would be appreciated.
There's a chance I misinterpreting the symptoms - I'm not a DB2 expert.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: DBD::Informix FAILURE CLASS A gcc: language arch=v9 not recognize d
Informix Database Driver for Perl DBI Version 2005.02(2005-07-29) (aka DBD::Informix) You are using DBI version 1.51 and Perl version 5.008007 Remember to actually read the README file! Perl: perl v5.008007 sun4-solaris dl_dlopen.xs System: sunos solaris 5.8 generic_108528-11 sun4u sparc sunw,ultra-5_10 Using INFORMIXDIR=/opt/IBM/informix and ESQL/C compiler esql Using IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.FC4from /opt/IBM/informix Beware: DBD::Informix is not yet aware of all the new IUS data types. Assert macro will be disabled! lib/DBD/Informix/Defaults.pm written OK esqlvrsn.h written OK esqlinfo.h written OK Testing whether your Informix test environment will work... ccflag = -fno-strict-aliasing ccflag = -pipe ccflag = -I/usr/local/include ccflag = -D_LARGEFILE_SOURCE ccflag = -D_FILE_OFFSET_BITS=64 cppflag = -DESQLC_VERSION=290 cppflag = -DNDEBUG cppflag = -DUSE_REAL_MALLOC execute_command: esql -c -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DESQLC_VERSION=290 -DNDEBUG -DUSE_REAL_MALLOC esqltest.ec +ec+ esql +ec+ -c +ec+ -fno-strict-aliasing +ec+ -pipe +ec+ -I/usr/local/include +ec+ -D_LARGEFILE_SOURCE +ec+ -D_FILE_OFFSET_BITS=64 +ec+ -DESQLC_VERSION=290 +ec+ -DNDEBUG +ec+ -DUSE_REAL_MALLOC +ec+ esqltest.ec + setenv INFORMIXC = /usr/local/bin/perl esqlcc + setenv ESQLCC = gcc -B/usr/ccs/bin/ gcc: language arch=v9 not recognized gcc: esqltest.c: linker input file unused because linking not done execute_command: esql -c -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DESQLC_VERSION=290 -DNDEBUG -DUSE_REAL_MALLOC esqlc_v6.ec +ec+ esql +ec+ -c +ec+ -fno-strict-aliasing +ec+ -pipe +ec+ -I/usr/local/include +ec+ -D_LARGEFILE_SOURCE +ec+ -D_FILE_OFFSET_BITS=64 +ec+ -DESQLC_VERSION=290 +ec+ -DNDEBUG +ec+ -DUSE_REAL_MALLOC +ec+ esqlc_v6.ec + setenv INFORMIXC = /usr/local/bin/perl esqlcc + setenv ESQLCC = gcc -B/usr/ccs/bin/ gcc: language arch=v9 not recognized gcc: esqlc_v6.c: linker input file unused because linking not done execute_command: esql -o esqltest esqltest.o esqlc_v6.o +ec+ esql +ec+ -o +ec+ esqltest +ec+ esqltest.o +ec+ esqlc_v6.o + setenv INFORMIXC = /usr/local/bin/perl esqlcc + setenv ESQLCC = gcc -B/usr/ccs/bin/ gcc: esqltest.o: No such file or directory gcc: esqlc_v6.o: No such file or directory gcc: language arch=v9 not recognized Failed to link test program esqltest Govinda Pfister Remedy Approved Consultant, Clarify Certified Consultant, ITIL-Certified Projectcenter Business Process Solutions Solution Service Center Business Enabling Solutions Global Competence Center T-Systems Enterprise Services GmbH Memmelsdorfer Str. 209a, 96052 Bamberg +49 951 4097-161 (Tel) +49 951 4097-200 (Fax) E-Mail: Govinda.Pfister mailto:[EMAIL PROTECTED] @ t-systems.com Internet: http://www.t-systems.com/ http://www.t-systems.com -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Speed test for connecting to Oracle for Windows via ODBC
On 6/12/06, Ron Savage [EMAIL PROTECTED] wrote: Using a DSN of dbi:ODBC:xyz, the DBI - connect(...) call takes 16 (sic) seconds with both the Perl script and Oracle running on the same PC under Windows. You have been warned :-(. I've occasionally seen similar outrageously long connection times with other software (not necessarily Perl - but Windows is always part of the mix), and it usually comes down to how the host names are resolved - and there turns out to be some problems (severe problems) with ... well, I'm probably about to use the jargon all wrong, but ... DNS and MS domain controllers and the like. Sometimes, DHCP gets in the way too. So, I'd be more inclined to label it a network or PC client setup problem than a Perl + DBI _ DBD::Anything problem. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: perl- dbi
On 6/5/06, Rutherdale, Will [EMAIL PROTECTED] wrote: If one wanted to get up to date for a while on a Perl-DBI-Informix combo, would this be a good set of versions: Perl 5.8.8 DBI 1.50 DBD::Informix 2005.02 We're not changing Informix itself at this point. Just wanted to recap versions for Perl and libraries based on what's been mentioned in this list and what I've seen on CPAN. The OS is Sun. Those are all the most recent versions, though Tim is preparing a DBI 1.51 release. That's what I have on my Solaris machine at the office. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: perl- dbi
On 6/1/06, R, Rajsekar [EMAIL PROTECTED] wrote: I am getting this error . please let me know.. what needs to be done further perl -MDBI -e 'print $DBI::VERSION\n' Can't locate DBI.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4-solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 .). BEGIN failed--compilation aborted. Download, compile and install DBI. And the driver for the DBMS you plan to use. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: perl- dbi
On 6/1/06, Jonathan Leffler [EMAIL PROTECTED] wrote: On 6/1/06, R, Rajsekar [EMAIL PROTECTED] wrote: I am getting this error . please let me know.. what needs to be done further perl -MDBI -e 'print $DBI::VERSION\n' Can't locate DBI.pm in @INC (@INC contains: /usr/perl5/5.00503/sun4-solaris /usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 .). BEGIN failed--compilation aborted. Download, compile and install DBI. And the driver for the DBMS you plan to use. And, since you're using a seriously down-version of Perl, you need to get yourself a sufficiently *old* version of DBI - one that will work with Perl 5.5.3; the current version requires 5.6.1. You'd be best off getting Perl 5.8.8 and redoing all the modules. It'll be harder in the short term, but you might not need to do it again for another 3 years. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: perl- dbi
On 5/31/06, R, Rajsekar [EMAIL PROTECTED] wrote: how do i ensure that DBI is installed in my machine.. will it be automatically installed when perl is installed... i am getiing error when i start using use DBI; and i need to connet to ORACLE DATABASE. You've received a few workable answers - but there's a better one. perl -MDBI -e 'print $DBI::VERSION\n' This tells you which version of DBI you have installed - which can be even more valuable than simply knowing that DBI is installed. Similarly: perl -MDBD::Oracle -e 'print $DBD::Oracle::VERSION\n' Similarly for any other (civilized) module - whether in the DBI/DBD collection or not. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: oracle array interface
On 5/29/06, Shreedhar Natarajan [EMAIL PROTECTED] wrote: I saw on the web that the Oracle array interface has not been implemented properly. I am new to DBI. Has the implementation been made more efficient? Would you care to provide a reference (URL) to justify the assertion? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Column names when using selectall_arrayref
On 5/3/06, Bill Moseley [EMAIL PROTECTED] wrote:
How do I get the column names as a list to match the order of the
rows returned when using select/fetchall_arrayref and using an ARRAY
slice? I'm not having luck finding it in the docs.
I don't know the column names ahead of time -- I'm passed a query and
want to return the data in the column order specified in the query.
And also return the list of column names.
Doesn't fetchall_arrayref return you a reference to an array of rows, each
row of which is itself an array. So, you fall back on $sth-{NAMES} for the
list of column names.
Your subject line only mentions selectall_arrayref - so maybe you're really
planning to use that. If so, you need to read the fine print about if
selectall_arrayref being passed a prepared statement handle - and then use
that and $sth-{NAMES} again.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: how to set a DEFAULT value !!
On 4/26/06, Greg Sabino Mullane [EMAIL PROTECTED] wrote: DBI is complex enough, and AIUI the DBI philosophy opposes adding features to the core that will cause implementation headaches for driver authors. The standard perl idiom for default values is You misunderstand. The DEFAULT is on the database side, not the client, and is represented by sending the literal string 'DEFAULT' to the backend, similar to the way that null values are sent by the literal string 'NULL'. The database then populates the column with whatever the default has been set as, which may be a constant, or may be (in PostgreSQL's case) an arbitrarily complex expression or call to a stored procedure. Is it a string that's sent, or the identifier? For NULL, it is either an identifier (not quoted) or Perl undef that denotes NULL in the DBMS. I'm not sure how you'd represent DEFAULT in Perl, or as a string rather than an identifier. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Checking if a table exist
On 4/27/06, Loo, Peter # PHX [EMAIL PROTECTED] wrote:
Does anyone know of a good way to check if a table exist disregarding
whether the table has data or not?
Simplest is:
my $sth = $dbh-prepare(SELECT * FROM $tablename);
if ($sth) { ...table exists...probably; you might need to do $sth-execute
to be sure as different DBMS differ... }
else { ...table probably doesn't exist, or it exists but you don't have
select permission on it... }
Or you can play with table_info, etc.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.
Re: Problem on Solaris 8 64-bit.
On 3/30/06, Rhugga Harper [EMAIL PROTECTED] wrote: I'm running Oracle 10.2.0.1 on Solaris 8 64-bit. I running DBI 1.50, DBD::Oracle 1.16, and Perl 5.8.7. When I run a script that uses DBD::Oracle, it complains about wrong ELF class: Can't load '/usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: snapshot_tracker: fatal: /u01/app/oracle/product/10.2/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64 at /usr/local/lib/perl5/5.8.7/sun4-solaris/DynaLoader.pm line 230. at ./snapshot_tracker line 10 Compilation failed in require at ./snapshot_tracker line 10. BEGIN failed--compilation aborted at ./snapshot_tracker line 10 Even if I set LD_LIBRARY_PATH=/u01/app/oracle/product/10.2/lib32 in my shell environment and also explicitly set this using $ENV inside my script it still complains. If I copy the 32-bit client library into the /u01/app/oracle/product/10.2/lib directory my perl scripts work but then sqlplus is broken. (and subsequently all my shell scripts) Have I built DBD::Oracle incorrectly or how can I get DBI/DBD to use the library under lib32? (I would like to get DBD::Oracle to use the 64-bit library) Thanks for any help Is your Perl a 32-bit or a 64-bit version? If you want to use the 64-bit Oracle libraries, you'll need a 64-bit Perl. If you'd included the output of 'perl -V', we could have told you what you've got - you didn't, so we can't. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: bug in a OpenPower IBM 720 B
On 3/25/06, Jorge Valenzuela [EMAIL PROTECTED] wrote: Hello, I hava a bug/error in a OpenPower IBM 720 with Power5 processor and with LINUX SUSE Enterprise Server 9.0 Can you help me? As I noted in the rt.cpan.org response - given the total lack of meaningful information, no-one can help you. Given some meaningful information about the problem, then maybe we can help you. As to what information I need, please see the DBD::Informix README and related materials. At this stage, I'm assuming that you have a problem with Perl and DBI and DBD::Informix, but the only information that tells me this is that you posted to a collection of email addresses where such a problem might be relevant. The subject line does not indicate anything to do with Perl or Informix. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Problem with perl 5.8.8 with Oracle 9.0
On 3/24/06, Ron Savage [EMAIL PROTECTED] wrote: On Fri, 24 Mar 2006 08:37:37 -0700, Reidy, Ron wrote: Google is my friend. I can be your friend also: http://codecomments.com/PERL_DBI/message824574.html http://codecomments.com/ is unreachable. Any other source? Works for me...now... -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: SFTP error..
On 3/7/06, Vamsi_Doddapaneni [EMAIL PROTECTED] wrote: I have a problem with SFTP It looks as though the first problem is that you forgot to write: use DBI; -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: unsuscribe
On 08 Mar 2006 09:45:05 +0100, Loic Paillotin [EMAIL PROTECTED] wrote: -- Loïc Paillotin Chef de Projet Qualimucho Média, 10 rue Ballu 75009 Paris Tel: 01.56.98.16.51 From the mail headers in the message you posted: List-Post: mailto:dbi-users@perl.org List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Id: dbi-users.perl.org -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Flaw reported in DBI::ProxyServer - is it something we knew about?
- Message from Marc Deslauriers [EMAIL PROTECTED] on Wed, 01 Mar 2006 20:22:16 -0500 - To:bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk Subject:[Full-disclosure] [FLSA-2006:178989] Updated perl-DBI package fixes security issue - Fedora Legacy Update Advisory Synopsis: Updated perl-DBI package fixes security issue Advisory ID: FLSA:178989 Issue date:2006-03-01 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0077 - - 1. Topic: An updated perl-DBI package that fixes a temporary file flaw in DBI::ProxyServer is now available. DBI is a database access Application Programming Interface (API) for the Perl programming language. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: The Debian Security Audit Project discovered that the DBI library creates a temporary PID file in an insecure manner. A local user could overwrite or create files as a different user who happens to run an application which uses DBI::ProxyServer. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0077 to this issue. Users should update to this erratum package which disables the temporary PID file unless configured. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, [...] 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178989 [...] -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: Flaw reported in DBI::ProxyServer - is it something we knew about?
On 3/2/06, Tim Bunce [EMAIL PROTECTED] wrote: Isn't that the same as this?: Changes in DBI 1.47 (svn rev 854), 2nd February 2005 Fixed DBI::ProxyServer to not create pid files by default. References: Ubuntu Security Notice USN-70-1, CAN-2005-0077 Thanks to Javier Fernández-Sanguino Peña from the Debian Security Audit Project, and Jonathan Leffler. Yes - it just seems to have taken a while to get (re?)fixed in this particular version of Linux (Fedora Legacy). On Thu, Mar 02, 2006 at 10:14:16AM -0800, Jonathan Leffler wrote: - Message from Marc Deslauriers [EMAIL PROTECTED] on Wed, 01 Mar 2006 20:22:16 -0500 - To:bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk Subject:[Full-disclosure] [FLSA-2006:178989] Updated perl-DBI package fixes security issue - Fedora Legacy Update Advisory Synopsis: Updated perl-DBI package fixes security issue Advisory ID: FLSA:178989 Issue date:2006-03-01 Product: Red Hat Linux, Fedora Core Keywords: Bugfix CVE Names: CVE-2005-0077 - - 1. Topic: An updated perl-DBI package that fixes a temporary file flaw in DBI::ProxyServer is now available. DBI is a database access Application Programming Interface (API) for the Perl programming language. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 9 - i386 Fedora Core 1 - i386 Fedora Core 2 - i386 3. Problem description: The Debian Security Audit Project discovered that the DBI library creates a temporary PID file in an insecure manner. A local user could overwrite or create files as a different user who happens to run an application which uses DBI::ProxyServer. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2005-0077 to this issue. Users should update to this erratum package which disables the temporary PID file unless configured. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, [...] 5. Bug IDs fixed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178989 [...] -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
