Re: PERL - DBI MODULE
On Thu, Jun 4, 2020 at 13:32 Pramod Mv wrote: > Could you please let me know how to use the DBI module without a DBD > module installed ? . can you suggest any alternative. > For most practical purposes, you can't use the DBI without a DBD module — it's reason for existing is to provide a uniform interface to different databases. There are some drivers available with just DBI installed. But they are rather specialized and usually not what you need. -- Jonathan Leffler #include Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
ANNOUNCE: Informix Database Driver for Perl DBI Version 2018.1031 (2018-10-31) released
Informix Database Driver for Perl DBI Version 2018.1031 (2018-10-31) has been uploaded to CPAN. Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.008001 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.026002, or a later version, you should be planning to upgrade Perl). You will need to install DBI version 1.607 or later as well (version 1.642, or any later version, is recommended) before installing DBD::Informix. The code for DBD::Informix is available for download via: http://www.cpan.org/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at dbd.infor...@gmail.com. ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2018.1031 * Latest DBI is 1.642. * Fix other botched version number references. * Besides, Halloween is a good day for a release. * Read the changes for the 2018.0511 release too. New in release 2018.1029 * Minor tweaks to Announce and ChangeLog for general release. New in release 2018.0513 (limited trial release): * Revise guidance in Notes/nonroot.install for modern ExtUtils::MakeMaker. New in release 2018.0511 (limited trial release): * Remove support for versions of ESQL/C prior to 3.00 for Informix 11.10. * Remove support for compilation with C4GL instead of ESQL/C. * Rework the linking process to exploit 'esql -libs' always. * Remove support for DG-UX and DEC OSF/1. * Remove support for 'Windows NT' (t was never shown to work on XP, let alone Vista, Windows 7, 8 or 10) * Simplify support for HP-UX and Solaris. * Stop using the esqlcc, esqlld, esqlsed scripts. * Remove source code added solely to support unsupported versions of ESQL/C. * Remove many conditional compilation fragments for unsupported versions of ESQL/C. * Change work email address to jonathan.leff...@hcl.com New in release 2015.1101: * Trivial bug fix for the 2015.1031 release. * The ghosties and ghoulies crept in! New in release 2015.1031: * This is basically a minor bug-fix release. * RT#108030 about mismanaging the name of the Perl binary in Makefile.PL is fixed. * RT#108031 is about a missing (actually, misnamed) file in the MANIFEST. New in release 2015.0826: * Automatically deal with Perl and DBI minimum versions since the previous releases had a mish-mash of version numbers scattered through the code. * Fix DBD::Informix::TechSupport module, thereby fixing the TechSupport and ItWorks scripts too. * Note that with effect from the first release from 2016-01-01 onwards, DBD::Informix will no longer support any version of ClientSDK prior to version 3.50, the oldest version currently supported by IBM. The support code for some of the older versions of ESQL/C will be removed over time. You're welcome to try using older versions, but if anything goes wrong, you will need to upgrade. Support email address: * This release is supported by Jonathan Leffler . * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to bug-dbd-infor...@rt.cpan.org; they also get sent to dbd.infor...@gmail.com, etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler (jonathan.leff...@hcl.com, jonathan.leff...@gmail.com) @(#)$Id: Announce,v 2018.6 2018/10/31 03:19:43 jleffler Exp $ -- Jonathan Leffler #include Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
ANNOUNCE: Informix Database Driver for Perl DBI Version 2015.1101 (2015-11-01) released
Informix Database Driver for Perl DBI Version 2015.1101 (2015-11-01) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.008001 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.022000 - or a later version - you should be planning to upgrade Perl). You will to install DBI version 1.607 or later as well (version 1.634, or any later version, is recommended) before installing DBD::Informix. The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at dbd.infor...@gmail.com. ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2015.1101: * Pure bug-fix release (fixing glitches in release process, and documenting the correct process so maybe the glitches won't reoccur). New in release 2015.1031: * This is basically a minor bug-fix release. * RT#108030 about mismanaging the name of the Perl binary in Makefile.PL is fixed. * RT#108031 is about a missing (actually, misnamed) file in the MANIFEST. New in release 2015.0826: * Automatically deal with Perl and DBI minimum versions since the previous releases had a mish-mash of version numbers scattered through the code. * Fix DBD::Informix::TechSupport module, thereby fixing the TechSupport and ItWorks scripts too. * Note that with effect from the first release from 2016-01-01 onwards, DBD::Informix will no longer support any version of ClientSDK prior to version 3.50, the oldest version currently supported by IBM. The support code for some of the older versions of ESQL/C will be removed over time. You're welcome to try using older versions, but if anything goes wrong, you will need to upgrade. New in release 2015.0825: * Deal with changes to ExtUtils::MakeMaker that broke the build. * Update to require Perl 5.8.1 and DBI 1.607. * Change work email address back to jleff...@us.ibm.com New in release 2013.0521: * Support CSDK 4.10 for IDS 12.10 * Change work email address to jleff...@google.com Support email address: * This release is supported by Jonathan Leffler <dbd.infor...@gmail.com>. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to bug-dbd-infor...@rt.cpan.org; they also get sent to dbd.infor...@gmail.com, etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler (jleff...@us.ibm.com, jonathan.leff...@gmail.com) @(#)$Id: Announce,v 2015.6 2015/11/01 07:31:31 jleffler Exp $ -- Jonathan Leffler <jonathan.leff...@gmail.com> #include Guardian of DBD::Informix - v2015.0826 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
Re: /bin/sh: cc_r: not found
The problem is definitely that you are missing the compiler, cc_r, that was used to build Perl. It is not so clear that it is GCC that's missing. You're on AIX, and the IBM-provided compilers tend to have names with extensions like _r. And often names such as xlc_r. These might conceivably be in /usr/vac/bin if you have the software installed at all. If you can't find cc_r and can't afford to get it, you may be able to get away with faking it. However, options such as -qnoansialias are going to cause problems with most compilers other than the IBM ones. AFAIK, GCC won't support those options even on AIX. Frankly, you may be best off rebuilding Perl yourself with a compiler of your choosing, and then adding DBI and so on. On Thu, Oct 29, 2015 at 2:29 AM, Abhishek Mohanty1 <amoha...@in.ibm.com> wrote: > Hello Team , > > We are facing an issue while trying to install DBI-1.634. > > Perl Version we use : v5.8.8 built for aix-thread-multi > Server Version:AIX IMCBLRDMZSR1237 1 6 00C6FD554C00 > > I downloaded *DBI-1.634* . It had 2 dependencies which i installed > succesfullly ExUtils:MakeMaker and Test:Simple . > Now it throws error as > > *Running Mkbootstrap for DBI ()* > *chmod 644 "DBI.bs"* > *cc_r -c-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE > -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q32 > -D_LARGE_FILES -qlonglong -O-DVERSION=\"1.634\" -DXS_VERSION=\"1.634\" > "-I/usr/opt/perl5/lib/5.8.8/aix-thread-multi/CORE" Perl.c* > */bin/sh: cc_r: not found.* > *make: 1254-004 The error code from the last command is 127. * > > I still searched for some more gcc related rpm and installed on the system > . > RPMs i installed are: > libgcc-4.2.0-3 > gcc-java-4.2.0-3 > gcc-4.2.0-3 > gcc-locale-4.2.0-3 > gcc-c++-4.2.0-3 > libgcj-4.2.0-3 > gcc-gij-4.2.0-3 > > But still i am facing the same issue . > All forums have suggested that this issue is due to missing gcc compiler . > > Please do let me know how do i resolve it or steps to install cc_r /gcc > compiler. > > Thanks > Abhishek > -- Jonathan Leffler <jonathan.leff...@gmail.com> #include Guardian of DBD::Informix - v2015.0826 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
ANNOUNCE: Informix Database Driver for Perl DBI Version 2015.0826 (2015-08-26) released
On the eighth birthday of the 2007.0826 release of DBD::Informix… Informix Database Driver for Perl DBI Version 2015.0826 (2015-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.008001 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.022000 - or a later version - you should be planning to upgrade Perl). You will to install DBI version 1.607 or later as well (version 1.634 - or any later version - is recommended) before installing DBD::Informix. The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at dbd.infor...@gmail.com. ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2015.0826: * Automatically deal with Perl and DBI minimum versions since the previous releases had a mish-mash of version numbers scattered through the code. * Fix DBD::Informix::TechSupport module, thereby fixing the TechSupport and ItWorks scripts too. * Note that with effect from the first release from 2016-01-01 onwards, DBD::Informix will no longer support any version of ClientSDK prior to version 3.50, the oldest version currently supported by IBM. The support code for some of the older versions of ESQL/C will be removed over time. You're welcome to try using older versions, but if anything goes wrong, you will need to upgrade. New in release 2015.0825: * Deal with changes to ExtUtils::MakeMaker that broke the build. * Update to require Perl 5.8.1 and DBI 1.607. * Change work email address back to jleff...@us.ibm.com New in release 2013.0521: * Support CSDK 4.10 for IDS 12.10 * Change work email address to jleff...@google.com New in release 2013.0206: * Bug fix release (not generally available). * Properly handle the new ESQL/C version 4.10. New in release 2013.0113: * Bug fix release. * Workaround for bug in ESQL/C 3.70 and earlier that generates error -1820 when reopening a cursor that previously fetched LVARCHAR data. * Fix for INFORMIXDIR containing Perl regex metacharacters. * Other minor improvements as documented in the ChangeLog. * Formal support for ESQL/C 7.x and 8.x (don't ask why the current version numbers are smaller) will be dropped after this release. The code won't go away yet, but it is beyond time to get off those versions. ESQL/C 5.20 is nominally supported for those still using Informix OnLine 5.20, but there is no testing on that platform. Support email address: * This release is supported by Jonathan Leffler dbd.infor...@gmail.com. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to bug-dbd-infor...@rt.cpan.org; they also get sent to dbd.infor...@gmail.com, etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler (jleff...@us.ibm.com, jonathan.leff...@gmail.com) @(#)$Id: Announce,v 2015.3 2015/08/27 02:28:24 jleffler Exp $ PS: I'm not sure the CSDK 3.50 is still supported by IBM — anything older most definitely isn't. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2015.0825 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
ANNOUNCE: Informix Database Driver for Perl DBI Version 2015.0825 (2015-08-25) released
Informix Database Driver for Perl DBI Version 2015.0825 (2015-08-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.8.1 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.22.0 - or a later version - you should be planning to upgrade Perl). You will to install DBI version 1.607 or later as well (v1.634 - or any later version - is recommended) before installing DBD::Informix. The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at dbd.infor...@gmail.com. ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2015.0821 * Deal with changes to ExtUtils::MakeMaker that broke the build. * Update to require Perl 5.8.1 and DBI 1.607. * Change work email address back to jleff...@us.ibm.com New in release 2013.0521 * Support CSDK 4.10 for IDS 12.10 * Change work email address to jleff...@google.com New in release 2013.0206: * Bug fix release (not generally available). * Properly handle the new ESQL/C version 4.10. New in release 2013.0113: * Bug fix release. * Workaround for bug in ESQL/C 3.70 and earlier that generates error -1820 when reopening a cursor that previously fetched LVARCHAR data. * Fix for INFORMIXDIR containing Perl regex metacharacters. * Other minor improvements as documented in the ChangeLog. * Formal support for ESQL/C 7.x and 8.x (don't ask why the current version numbers are smaller) will be dropped after this release. The code won't go away yet, but it is beyond time to get off those versions. ESQL/C 5.20 is nominally supported for those still using Informix OnLine 5.20, but there is no testing on that platform. Support email address: * This release is supported by Jonathan Leffler dbd.infor...@gmail.com. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to bug-dbd-infor...@rt.cpan.org; they also get sent to dbd.infor...@gmail.com, etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler (jleff...@us.ibm.com, jonathan.leff...@gmail.com) @(#)$Id: Announce,v 2015.1 2015/08/22 00:03:41 jleffler Exp $ -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: (Fwd) DBI Dilemma
On Mon, Aug 17, 2015 at 5:02 PM, Wm Mussatto mussa...@csz.com wrote: On Mon, August 17, 2015 14:42, tim.bu...@pobox.com wrote: - Forwarded message from Adkins, Blake blake.adk...@intel.com - Date: Mon, 17 Aug 2015 17:51:41 + From: Adkins, Blake blake.adk...@intel.com To: tim.bu...@pobox.com tim.bu...@pobox.com […] Of the 140 columns in the database, one is named DESC, short for description. […] If I try to do a SELECT using that column, the script dies, or quietly passes DESC in the column header and all the rows. I've tried to figure out how to get around it without success. Do you have any suggestions aside from renaming the column? (I was thinking along the lines of escaping the name) Put back tick (i.e., `) around DESC. `DESC` DESC is a reserved word and this will tell mySQL that its a Column name NOT the reserved word. Using back-ticks only works if the DBMS is MySQL. Standard SQL uses double quotes around delimited identifiers. MS SQL Server uses square brackets. Other systems have other techniques. (Informix mostly manages to treat keywords that appear in the context of an identifier as an identifier instead of a keyword.) -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Escaping placeholders
Many, many years ago, DBD::Informix had to give up on the DBI-provided parsing for placeholders because there were too many contexts in which it was wrong for Informix. It may have improved since then, but: INSERT INTO SomeTable(DateTimeCol) VALUES(DATETIME(2014-12-31 23:59:59) YEAR TO SECOND); is valid Informix-dialect SQL with no placeholders whatsoever. The Standard SQL notation would be: VALUES(TIMESTAMP '2014-12-31 23:59:59') and many systems would likely get away without needing the TIMESTAMP (automatically coercing the string into the correct type). Indeed, Informix accepts the string notation (without the TIMESTAMP prefix), but the other notation is also valid and therefore DBD::Informix must support it. The standard notation avoids problems because the colons are embedded within strings, whereas the Informix DATETIME literal notation uses parentheses instead of quotes around what is otherwise effectively a string. I could also insert INTERVAL(23 13:45:19) DAY TO SECOND with similar comments about its behaviour. Also, Informix uses the notation: dbase@server:owner.table for a fully qualified table name, with no placeholders present. You can omit the '@server' to reference the current server (hence dbase:owner.table is valid too); you can omit the 'owner.' if you want to refer to a table (depending on context) owned by the current user or uniquely named belonging to an arbitrary user (so dbase:table is valid too). You can omit the dbase altogether, but then the colon isn't present and it is no longer relevant to the handling of placeholders prefixed by colon. This leads to the synoptic notation: [dbase[@server]:][owner.]table I think I raised this as an issue back in the 1996-1998 timeframe (I said 'many years ago' and meant it). I'd have to dig through my release notes to be more precise. Informix only supports natively the `?` placeholders. It doesn't yet have the complexities introduced by the PostgreSQL operators. I don't know whether this can be handled at all. It may be that DBD::Informix has to stay out in isolation — but it would be nice if it wasn't necessary. On Sat, Dec 20, 2014 at 8:35 AM, Alexander Foken alexan...@foken.de wrote: On 20.12.2014 15:38, Tim Bunce wrote: On Fri, Dec 19, 2014 at 01:12:16PM +0100, Alexander Foken wrote: Hello all, this reminds me of a similar problem I had in 2000 with DBI, DBD::Oracle, and Oracle. See http://marc.info/?t=9506395904r=1w=2, http://173.79.223.25/?l=dbi-devm=95077716125217w=2. Problem was using named placeholders (:foo) in DBI and at the same time use PL/SQL code containing variables (:bar), DBI considered both :foo and :bar to be placeholders instead of leaving :bar alone and pass it to Oracle. A set of patches from Michael A. Chase allowed disabling parts or all of the placeholder parsing, so using unnamed placeholders (?) allowed using PL/SQL variables in SQL statements. But the fundamental problem was not solved, there was and still is no way to escape placeholders. Can you, or anyone else, think of any situation where a backslash before a ? or :foo (or even $1) style placeholder might be valid SQL? I found two situations for PostgreSQL: (1) PostgreSQL allows almost any character as escape character in Unicode string constants (http://www.postgresql.org/docs/current/static/sql- syntax-lexical.html#SQL-SYNTAX-STRINGS-UESCAPE). With that, I can construct an expression containing \:foo that is valid SQL as understood by PostgreSQL: U'foo\:bar' UESCAPE ':' This expression represents the string foo\Xbar, where X is the Unicode character U+ (TAI VIET LETTER LOW VO). (2) PostgreSQL also allows Dollar quoting (http://www.postgresql.org/ docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-DOLLAR-QUOTING). With that, I can construct an expression containing \$1 that is valid SQL as understood by PostgreSQL: $1$foo\$1$ This expression represents the string foo\, quoted by dollar signs using the character 1 as tag. So far no one has come up with one, so I'm getting more comfortable with the idea that a backslash before a placeholder is a safe change. I.e., there's a near-zero risk that upgrading a DBI driver to support backslashes would cause breakage in existing code. Do you plan to escape the escape character, i.e. use a double backslash at DBI level to represent a single backslash at database level? Alexander Tim. -- Alexander Foken mailto:alexan...@foken.de http://www.foken.de/alexander/ -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Escaping placeholders
Gmail hid the line you gave (as if it was the same as something I'd sent — curious behaviour by Gmail): INSERT INTO SomeTable(DateTimeCol) VALUES(DATETIME(2014-12-31 23\:59\:59) YEAR TO SECOND); I really won't want people have to futz with their legitimate Informix SQL in order to pass it through DBD::Informix. Whatever is provided, whether by DBI or DBD::Informix, must accept the code without the backslashes in front of the colons. It is simply not acceptable to have to modify valid SQL to get it past the gatekeeper code. At the moment, the unescaped code works fine. It will continue to work fine. As long as DBI does not break the currently working code, I will survive — like I have for the last decade and more. Just make sure that whatever you do does not break working valid Informix SQL code. On Sat, Dec 20, 2014 at 2:17 PM, Tim Bunce tim.bu...@pobox.com wrote: On Sat, Dec 20, 2014 at 01:14:29PM -0800, Jonathan Leffler wrote: Many, many years ago, DBD::Informix had to give up on the DBI-provided parsing for placeholders because there were too many contexts in which it was wrong for Informix. It may have improved since then, but: INSERT INTO SomeTable(DateTimeCol) VALUES(DATETIME(2014-12-31 23:59:59) YEAR TO SECOND); I think I raised this as an issue back in the 1996-1998 timeframe (I said 'many years ago' and meant it). I'd have to dig through my release notes to be more precise. Informix only supports natively the `?` placeholders. It doesn't yet have the complexities introduced by the PostgreSQL operators. I don't know whether this can be handled at all. It may be that DBD::Informix has to stay out in isolation but it would be nice if it wasn't necessary. The `?` placeholders are 'standard' (for some definition) so DBD::Informix isn't really 'in isolation'. There are quite a few drivers that only support `?` placeholders. In theory, if this proposal goes ahead, and is applied to `:` placeholders as seems likely, then you'd be able to write the above as: INSERT INTO SomeTable(DateTimeCol) VALUES(DATETIME(2014-12-31 23\:59\:59) YEAR TO SECOND); Tim. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Informinx Perl Module Installation Issues
-sdcitnm DBD-Informix-2013.0521]# perl -v *This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux* Copyright 1987-2013, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. *Customer Server* [root@CRPVLX1NETCOOLITNM ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release *5.5 (Tikanga)* [root@CRPVLX1NETCOOLITNM ~]# gcc --version *gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)* Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [root@CRPVLX1NETCOOLITNM]# perl -v *This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux* Copyright 1987-2013, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. = Could you please let me know what would be the solution to resolve the issue. Thanks, Sagar On Fri, Aug 8, 2014 at 6:42 PM, Jonathan Leffler jonathan.leff...@gmail.com wrote: It means there is a mismatch between the code used in compiling DBD::Informix and the code used in compiling Perl. You've not given explicit platform information (it seems to be a 64-bit RedHat Linux), nor the version of Perl. This problem occurred semi-regularly…oh, about ten years ago. It hasn't often been a problem since. It might be that you're using a threaded Perl, but it isn't supposed to be a problem. Please look at the bug reporting instructions in the file Notes/bug.reports and use the script BugReport. It'll be a couple of days or so before I can look at the problem in any detail. On Thu, Aug 7, 2014 at 11:00 AM, sagar nch sagar...@gmail.com wrote: Hi Team, I am facing issues while running make command while installing the Informix perl module. Here is the error snippet. INFORMIXC='/usr/local/bin/perl esqlld' ESQLLD='cc -shared -O2 -L/usr/local/lib -fstack-protector' esql -shared -O2 -L/usr/local/lib -fstack-protector Informix.o dbdimp.o dbdattr.o sqltoken.o sqltype.o ixblob.o odbctype.o kludge.o link.o esqlcver.o esqlc_v6.o -o blib/arch/auto/DBD/Informix/Informix.so \ \ /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' Informix.o: In function `dbi_get_state': Informix.c:(.text+0x1b): undefined reference to `PL_thr_key' Informix.c:(.text+0x48): undefined reference to `PL_thr_key' Informix.c:(.text+0x61): undefined reference to `Perl_get_cv' Informix.c:(.text+0x82): undefined reference to `Perl_croak_nocontext' Informix.o: In function `boot_DBD__Informix': Informix.c:(.text+0x9f): undefined reference to `PL_thr_key' Informix.c:(.text+0x116): undefined reference to `Perl_xs_apiversion_bootcheck' Informix.c:(.text+0x139): undefined reference to `Perl_xs_version_bootcheck' Informix.c:(.text+0x168): undefined reference to `Perl_newXS_flags' Informix.c:(.text+0x1a1): undefined reference to `Perl_newXS_flags' Informix.c:(.text+0x1da): undefined reference to `Perl_newXS_flags' Informix.c:(.text+0x213): undefined reference to `Perl_newXS_flags' Informix.c:(.text+0x24c): undefined reference to `Perl_newXS_flags' Informix.o:Informix.c:(.text+0x285): more undefined references to `Perl_newXS_flags' follow Informix.o: In function `boot_DBD__Informix': Informix.c:(.text+0x87e): undefined reference to `Perl_newXS' Informix.c:(.text+0x8a3): undefined reference to `Perl_newXS' Informix.c:(.text+0x8d2): undefined reference to `Perl_newXS' Informix.c:(.text+0x901): undefined reference to `Perl_newXS' Informix.c:(.text+0x926): undefined reference to `Perl_newXS' bdattr.o: In function `dbd_ix_db_STORE_attrib': dbdattr.c:(.text+0x190b): undefined reference to `Perl_sv_2pv_flags' dbdattr.c:(.text+0x1a33): undefined reference to `PL_thr_key' dbdattr.c:(.text+0x1a4a): undefined reference to `Perl_sv_2bool_flags' dbdattr.c:(.text+0x1ad1): undefined reference to `PL_thr_key' dbdattr.c:(.text+0x1ae5): undefined reference to `Perl_sv_2bool_flags' dbdattr.c:(.text+0x1cc8): undefined reference to `PL_thr_key' dbdattr.c:(.text+0x1cdf): undefined reference to `Perl_sv_2bool_flags' dbdattr.c:(.text+0x1d49): undefined reference to `PL_thr_key' dbdattr.c:(.text+0x1d60): undefined reference to `Perl_sv_2bool_flags
Re: DBD::Informix
You may need to get an extra compilation flag, -ldl, added to the link line, though it is a little surprising to find that's necessary. That might solve dlopen, dlclose, dlerror, dlsym. Missing crypt is more puzzling; maybe there's a library -lcrypt or something that's needed. It is very odd, though; those are not normally a problem. The Perl configuration shows -ldl and -lcrypt are used. The debug output does not show a linking operation, but it is a linking operation which is failing, which is very puzzling. I'll see what I can do to reproduce it. On Wed, Jul 9, 2014 at 7:58 AM, Helmut h...@hzlabs.de wrote: Hi all, i have problems building DBD::Informix. Running Makefile.pl ends up with .. /opt/IBM/informix/lib/libifasf.so: undefined reference to `dlopen' /opt/IBM/informix/lib/esql/libifos.so: undefined reference to `crypt' /opt/IBM/informix/lib/libifasf.so: undefined reference to `dlclose' /opt/IBM/informix/lib/libifasf.so: undefined reference to `dlerror' /opt/IBM/informix/lib/libifasf.so: undefined reference to `dlsym' collect2: Fehler: ld gab 1 als Ende-Status zurück Failed to link test program esqltest running on configuration at lib/DBD/Informix/TechSupport.pm line 225. System: ArchLinux x86-64 Perl: v5.18.2 Informix: clientsdk.4.10.FC4DE.LINUX DBD-Informix-2013.0521 The bug report perl -Ilib BugReport A is below / attached. What can i do to track the problem down? Thank you Helmut -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: CPAN DBI make make test error
On Thu, Apr 3, 2014 at 6:14 AM, Karthi Keyan01 karthi_keya...@infosys.comwrote: I'm trying to install the DBI module in the below mentioned steps as a root user. xlc_r -q32 -c-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O-DVERSION=\1.631\ -DXS_VERSION=\1.631\ -I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE Perl.c /bin/sh: xlc_r: not found. make: 1254-004 The error code from the last command is 127. Maybe you don't have the xlc_r installed on your machine at all, or maybe it is not on your path when you are logged in as root. Either way, the primary fix is to ensure that root has access to the xlc_r compiler. The secondary problem is that you're compiling as root. Personally, I recommend doing the compilation and testing as a regular user. Only if you're sure you want to mess with the system installation of Perl do you do the install as 'root'. Minimize the use of root privileges; it reduces the risks of doing damage if something goes wrong. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBD::Informix test failures
John and I have had some off-list discussion.
The problem is ultimately a test error; the code written a decade or more
ago doesn't take into account a database server configuration option
introduced in the last five years or so.
The relevant Informix configuration parameter is TEMPTAB_NOLOG. If set,
the test that relies on being able to rollback changes in a temporary table
will fail because the configuration parameter removes the ability to
rollback changes in temporary tables.
The test will be updated and a new DBD::Informix released, probably before
Christmas; the build is working OK and is safe to use in production (or as
safe as it ever was).
This comment covers both of John's emails to dbi-users mailing list.
On Tue, Nov 12, 2013 at 2:01 AM, John Beranek j...@redux.org.uk wrote:
On 12/11/2013 08:59, John Beranek wrote:
I'm trying to compile DBD::Informix on a Linux server (or alternatively
on a Solaris 10 server, but this shows the same problems) but I'm
getting failures in the test suite.
Firstly, I've fixed the subject, that is the subject I had initially
intended to use.
I boiled down the tests into a simple test script, to convince myself of
the results:
use DBI;
my $database = 'testdb';
my $username = 'informix';
my $password = 'somepassword';
my $test_table = 'test_jb';
my $dbh = DBI-connect(dbi:Informix:$database, $username, $password,
{AutoCommit = 0});
$dbh-do(CREATE TEMP TABLE $test_table
(
Col01 SERIAL NOT NULL PRIMARY KEY,
Col02 CHAR(20) NOT NULL,
Col03 DATE NOT NULL,
Col04 DATETIME YEAR TO FRACTION(5) NOT NULL
)) or die CREATE TEMP TABLE failed\n;
$dbh-commit();
my $date = '25/12/1996';
my $time = '2004-02-29 23:59:54.32109';
$dbh-do(INSERT INTO $test_table VALUES(0, 'data', '$date', '$time'));
$dbh-rollback();
my $sth = $dbh-prepare(SELECT * from $test_table);
$sth-execute();
use Data::Dumper;
print Dumper($sth-fetchall_arrayref);
$dbh-disconnect();
The results of this script are:
$VAR1 = [
[
'1',
'data',
'25/12/1996',
'2004-02-29 23:59:54.32109'
]
];
i.e. the rollback appears not to have worked. From the output of the
test suite, the database is a logged database, and there doesn't appear to
be any errors setting autocommit off. So, what would cause transaction
rollbacks not to work?
Cheers,
John
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Installing DBI and getting a fatal error.
My interpretation of that output would be that your version of GCC is not
using the same linker as the version of GCC used to build the Perl you're
using.
Either get the original version of GCC onto your machine, or build Perl
with the GCC you've got. Look at the output of 'perl -V' to see what the
linker was.
On Wed, Sep 18, 2013 at 8:42 PM, Callegari, Nick
nick.calleg...@au.fujitsu.com wrote:
Hi All,
** **
Just having the following issue when we try to install DBI in a Solaris 10
zone. Any help with this issue would be appreciated.
** **
When we run the ‘make’ it comes up with a fatal error see below:
** **
root@nevdisdev:/var/tmp/gia/DBI/DBI-1.628# make
/usr/local/bin/perl -MExtUtils::Command -e 'mkpath' -- blib/lib/DBI
rm -f blib/lib/DBI/Changes.pm
{snip…..snip}
Running Mkbootstrap for DBI ()
chmod 644 DBI.bs
rm -f blib/arch/auto/DBI/DBI.so
gcc -B/usr/ccs/bin/ -Wl,-E -shared -L/usr/local/lib DBI.o -o
blib/arch/auto/DBI/DBI.so\
\
** **
ld: fatal: unrecognized option '-E'
ld: fatal: use the -z help option for usage information
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `blib/arch/auto/DBI/DBI.so'**
**
** **
The attached file has the ‘perl –V’ and the full printouts.
** **
Kind regards,
*Nick Callegari
*nick.calleg...@au.fujitsu.com
au.fujitsu.com
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: SQL: -208: Memory allocation failed during query processing
AFAICR, the DBD::Informix driver does not report error -208 when client-side memory allocation fails in DBD::Informix code, so the problem is almost certainly in the server, not in Perl, DBI or DBD::Informix. It might conceivably be in the ESQL/C code. You say it works in another environment; please can you provide details of that other environment? That is, is it the same database server (the same Informix instance) or a different one? And which tools are you using in that other environment. If the second environment is access the same database server, then there are lots of questions to ask, such as: What exactly is the query? What size are the tables (row size, number of rows)? What are the table schemas? What is the version of Informix that you're using? Which version of ESQL/C or CSDK? Are you hacking the system's copy of Perl? Or are you installing the extra software in your own directory? Is there a reason you can't move to, say, Perl 5.8.9 (or even 5.16.2 or 5.18.0)? Did this query ever work on this machine, or is this new development work? Andrew Snyder asked a salient question: are you reading all the rows at once ($sth-fetchall_arrayref() or something similar)? If so, your comparison environment must also be Perl + DBI + DBD::Informix to be of much relevance. Are you using a 32-bit or 64-bit version of Perl? As you can tell from the sheer number of questions, you've not really characterized your problem very clearly yet, so no-one can really help you with solving it. On Mon, Jul 1, 2013 at 3:20 PM, KOTAGIRI, RAMPRASAD rp5...@att.com wrote: Environment: Perl v5.8.4 built for sun4-solaris-64int [SunOS 5.10] ** ** Perl DBI uses Informix DBD, DBI connect and prepare statement are successful, execute routine returns error: SQL: -208: Memory allocation failed during query processing ** ** The same SQL query works fine and returns results in other environment. Can you please suggest if the issue is with DB engine or Informix driver in Perl? ** ** Thanks, Ram -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBD::Informix
On Sun, Jun 30, 2013 at 2:38 AM, Dr. Helmut Zeilinger h...@hzlabs.de wrote:
I have Problems to build DBD::Informix (DBD-Informix-2013.0521).
The output of bug_report ('B') is attached..
I'm sorry you've run into problems. Thank you for using the bug reporting
tools provided.
The problem lines in the output are (split to avoid grossly overlong lines
— but mail clients may do more damage to them):
INFORMIXC='/usr/bin/perl5.16.3 esqlld' ESQLLD='x86_64-pc-linux-gnu-gcc
-shared -march=core2 -mtune=generic -O2 -pipe -Wl,-O1 -Wl,--as-needed'
esql -shared -march=core2 -mtune=generic -O2 -pipe -Wl,-O1 -Wl,--as-needed
Informix.o dbdimp.o dbdattr.o sqltoken.o sqltype.o ixblob.o odbctype.o
kludge.o link.o esqlcver.o esqlc_v6.o -o
blib/arch/auto/DBD/Informix/Informix.so \
\
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
Informix.o: In function `XS_DBD__Informix__dr_driver_init':
Informix.c:(.text+0x1e): undefined reference to `PL_thr_key'
followed by many, many more similar undefined references. The reference to
`main` is interesting; it tells me that things have gone horribly wrong,
but in a fairly tightly-constrained area of the code, namely the linking of
the shared library.
Further debugging information is going to be necessary; I recommend keeping
it off the DBI Users mailing list.
Please run the build phase (no need to redo the configuration phase; no
need to remove the object files) with these environment variables set:
DBD_INFORMIX_DEBUG_ESQLLD=1 \
DBD_INFORMIX_DEBUG_ESQLCC=1 \
make 21 | tee dbdix.log
This should give information about what is going on inside the esqlld and
esqlcc scripts. Send the output file dbdix.log to dbd.infor...@gmail.com,
please.
At this stage, my best guess is that the Makefile.PL has clobbered some
important flag so that the shared object build thinks it is trying to build
a program and not a shared library. However, this may well involve
tinkering inside Makefile.PL in the medium term, which is not a pleasant
thought — it is ugly code! And some of the 15 year old hacks may well have
outlived their usefulness, and the ways used to tweak ExtUtils::MakeMaker
settings may be ... sub-optimal, shall we say.
Do you still have the source for DBI around? If so, I may end up asking
you to build that and send (some of) the output from that, simply to
provide a comparison between 'working' (DBI) and 'not working'
(DBD::Informix) shared library build command lines.
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: ODBC Driver failing?
On Wed, Jun 26, 2013 at 9:28 AM, Dan Bent db...@comcast.net wrote: I suddenly lost the ability to connect to my ODBC database yesterday, after years of using the same function to establish a connection: So, the question you must ask yourself is: What changed yesterday? Or, if not yesterday, since the previous time when you successfully used the code. Something crucial changed. If it wasn't the Perl plus ODBC infrastructure, then what changed outside that? The DBMS? The networking? Change analysis is likely to get you to the answer quicker than anything else. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBI Driver.xst and DBD::cego
Since the only place 'plural' is used is the statement immediately after the assignment, it is much simpler and perfectly safe to use const char *plural = ... than to futz around with the myp array as in the second patch (or to cast away constness as in the first patch). On Mon, May 27, 2013 at 8:16 AM, Kurt Jaeger dbi-us...@opsec.eu wrote: Hi! Tim wrote: On Sun, May 26, 2013 at 08:13:58PM +0200, Kurt Jaeger wrote: https://rt.cpan.org/Ticket/Display.html?id=84285 error: invalid conversion from 'const char*' to 'char*' I'm surprised the compiler treats this as an error, it's normally a warning. -char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? : s; +char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? (char*) : (char*)s; clang++ is more strict 8-} Can someone have a look at it ? Is that patch the right way to do it ? It would be better to put the const on the declaration in this case. I.e.: -char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? : s; +const char *plural = (DBIc_ACTIVE_KIDS(imp_dbh)==1) ? : s; but that may trigger other errors/warnings in later code which will need attending to. (Same goes for the other hunk in the patch.) Could you give that a go? Have you seen my second attempt ? It's going along the clang line and seems much cleaner. -- p...@opsec.eu+49 171 3101372 7 years to go ! -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBD installtion 11G R2 (64Bit) 32 bit perl version
-D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -qlanglvl=extended -I/usr/local/include -q32 -D_LARGE_FILES -qlonglong -O -DVERSION=\1.62\ -DXS_VERSION=\1.62\ -I/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE -DUTF8_SUPPORT -DORA_OCI_VERSION=\11.2.0.3\ -DORA_OCI_102 -DORA_OCI_112 oci8.c Running Mkbootstrap for DBD::Oracle () chmod 644 Oracle.bs rm -f blib/arch/auto/DBD/Oracle/Oracle.so LD_RUN_PATH=/u01/app/oracle/product/11.2.0/dbhome_1/lib:/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib ld -bhalt:4 -G -bI:/usr/opt/perl5/lib/5.10.1/aix-thread-multi/CORE/perl.exp -bE:Oracle.exp -bnoentry -lpthreads -lc -lm -L/usr/local/lib Oracle.o dbdimp.o oci8.o /lib/crt0_64.o -o blib/arch/auto/DBD/Oracle/Oracle.so -L/u01/app/oracle/product/11.2.0/dbhome_1/lib/ -lclntsh -lld -lm -ldl -lc -lm -lpthreads -lodm -lbsd_r -lld -lperfstat -lm -lpthreads ld: 0711-736 ERROR: Input file /lib/crt0_64.o: XCOFF64 object files are not allowed in 32-bit mode. make: 1254-004 The error code from the last command is 8. Stop. bash-3.2# echo $ LD_RUN_PATH $ LD_RUN_PATH bash-3.2# echo $LD_RUN_PATH bash-3.2# This e-mail including any attachment is intended only for the recipient(s) named. It may contain confidential information and should not be read, copied or otherwise used by any other person. If you are not a named recipient, please contact the sender and delete the e-mail from your system. The sender does not accept any liability for errors or omissions in the content of this message or for viruses, or any damage due to the e-mail. The recipient is advised to have appropriate virus check software -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
ANNOUNCE: Informix Database Driver for Perl DBI Version 2013.0521 (2013-05-21) released
Informix Database Driver for Perl DBI Version 2013.0521 (2013-05-21) has been uploaded to CPAN. IBM Informix Database Driver for Perl (also known as DBD::Informix) is the driver code that enables Perl 5.6.1 or later to access Informix databases via the DBI module (but if you are not already using Perl 5.10.0 - or any later version - you should be planning to upgrade to Perl 5.16.2 or later). You will need the code for DBI version 1.38 or later as well (v1.623 - or any later version - is recommended). The code for DBD::Informix is available for download via: http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces http://dbi.perl.org/ ** When you successfully build this module, use the ItWorks (Perl) ** script to report your configuration to the maintenance team (meaning ** Jonathan Leffler) at dbd.infor...@gmail.com. ** The ItWorks script does not send email to anybody; you have to do ** that yourself. New in release 2013.0521 * Support CSDK 4.10 for IDS 12.10 * Change work email address to jleff...@google.com New in release 2013.0206: * Bug fix release (not generally available). * Properly handle the new ESQL/C version 4.10. New in release 2013.0113: * Bug fix release. * Workaround for bug in ESQL/C 3.70 and earlier that generates error -1820 when reopening a cursor that previously fetched LVARCHAR data. * Fix for INFORMIXDIR containing Perl regex metacharacters. * Other minor improvements as documented in the ChangeLog. * Formal support for ESQL/C 7.x and 8.x (don't ask why the current version numbers are smaller) will be dropped after this release. The code won't go away yet, but it is beyond time to get off those versions. ESQL/C 5.20 is nominally supported for those still using Informix OnLine 5.20, but there is no testing on that platform. New in release 2011.0612: * Minor bug fix release. * Main change is related to Perl internals and avoids the need for PERL_POLLUTE. This change is not visible to users except that Perl 5.14.x can use the fixed code. * Fixed problem with string that is not null terminated by ESQL/C library. * Clean up some 64-bit compilation warnings. * Build on AIX. * Evade problem with a DISTINCT type of LVARCHAR with NOT NULL (probably ESQL/C bug). * Fewer versions of Informix products are supported. You may try building DBD::Informix with other versions. If it works, great; if not, please upgrade to a supported Informix version. Support email address: * This release is supported by Jonathan Leffler dbd.infor...@gmail.com. * You may also report your bugs via the CPAN resolution tracking system: http://rt.cpan.org/ * Such bug reports can be sent by email to bug-dbd-infor...@rt.cpan.org; they also get sent to dbd.infor...@gmail.com, etc. As always, see the ChangeLog file for details about what has changed. Jonathan Leffler (jleff...@google.com, jonathan.leff...@gmail.com) @(#)$Id: Announce,v 2013.6 2013/05/22 05:41:29 jleffler Exp $ -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0521 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Reg: Help required installing dbi on AIX Server
When you use 'sudo', your PATH is changed. Try: sudo sh -c 'echo $PATH' (a) Don't compile as 'root' (install as root if you must, but personally, I leave the system's Perl strictly untouched and create my own copy of Perl every time). (b) If you must compile as 'root', you'll have to reset root's path to include /usr/vac/bin. Good luck. On Thu, Apr 11, 2013 at 4:56 PM, Manimegalai Visvanathan mvisvanat...@wsgc.com wrote: Dear Team, I need your help installing DBI on AIX Server. It's may be a compiler issue. But, am able to find cc and cc_r installed under /usr/vac/bin path. GCC -4 is also installed on this server. Eventhough, am unable to install dbi. Kindly help me to fix this issue. $ cd DBI-1.625 $ sudo perl Makefile.PL Creating test wrappers for DBD::Gofer: t/zvg_01basics.t t/zvg_02dbidrv.t [...] t/zvxgnp_85gofer.t I see you're using perl 5.008008 on aix-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. Another reason for building your own Perl is that you could use a less archaic version — like 5.16.2 instead of 5.8.8! Writing Makefile for DBI $ sudo make cc_r -c-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q32 -D_LARGE_FILES -qlonglong -O-DVERSION=\1.625\ -DXS_VERSION=\1.625\ -I/usr/opt/perl5/lib/5.8.8/aix-thread-multi/CORE Perl.c /bin/sh: cc_r: not found make: The error code from the last command is 127. Stop. $ $ perl -v This is perl, v5.8.8 built for aix-thread-multi Copyright 1987-2006, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. $ uname -a AIX abidevrk2p 1 6 00F694884C00 $ cd /usr/vac/bin $ ls CreateExportList c89_r7c99_r7cc_r7 xlc c89 c99 cccleanpdf xlc128 c89_128 c99_128 cc128 fixpkg_vacndi xlc128_r c89_128_r c99_128_r cc128_r gxlc xlc128_r4 c89_128_r4c99_128_r4cc128_r4 mergepdf xlc128_r7 c89_128_r7c99_128_r7cc128_r7 resetpdf xlc_r c89_r c99_r cc_r showpdf xlc_r4 c89_r4c99_r4cc_r4 vacndi xlc_r7 $ gcc -v Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld --disable-nls --enable-languages=c,c++ --prefix=/opt/freeware --enable-threads --enable-version-specific-runtime-libs --host=powerpc-ibm-aix5.3.0.0 Thread model: aix gcc version 4.0.0 Don't try using GCC unless you build your own Perl with it. You will be in for a world of pain. Please consider the impact to the environment before printing this email -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2013.0118 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: install_driver(DB2) failed:
Do you have the DB2 client software installed too? It probably doesn't
require just the DBD::DB2 driver library; it also requires the supporting
libraries from ... is it DB2 Connect? And without those libraries, loading
the DBD::DB2 driver library fails (but because a supporting module couldn't
be found, not because the main DB2.dll module could not be found).
Basically, could you connect to DB2 without Perl from you machine? If not,
neither can the Perl DBD::DB2 driver. If so, have you set the environment
correctly so that Perl is picking up the DB2 libraries.
On Wed, Apr 10, 2013 at 3:51 PM, Harry Jamieson ha...@persoftware.comwrote:
Hi.
I'm running XP SP3
Active Perl 5.14.2.1402
PPM 4.14
DBI 1.625
DBD::DB2 1.85
My connection -
$dbh = DBI-connect (dbi:DB2:Sort, $ID, $PW,
{
RaiseError = 1,
PrintError = 1,
AutoCommit = 1,
}
) or die $DBI::errstr;
fails with -
install_driver(DB2) failed: Can't load
'c:/Perl/site/lib/auto/DBD/**DB2/DB2.dll'
for module DBD::DB2: load_file:The specified module could not be found at
c:/Perl/lib/DynaLoader.pm line 191.
at (eval 6) line 3
Compilation failed in require at (eval 6) line 3.
Perhaps a required shared library or dll isn't installed where expected
at HyperMail/Includes.pm line 74
but c:/Perl/site/lib/auto/DBD/DB2/**DB2.dll exists with today's date on
it. I have DB2_HOME set to C:\Program Files\IBM\SQLLIB\lib. Does anyone
know what I'm missing here?
Harry
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2013.0118 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Problems installing DBI on AIX5
On Mon, Aug 6, 2012 at 9:50 AM, Don Walters donrwalt...@gmail.com wrote: Oops: Makefile.PL output was truncated. Here's the full output: srvdfj239 /DBI-1.622 # perl Makefile.PL *** You are using a perl configured with threading enabled. *** You should be aware that using multiple threads is *** not recommended for production environments. Creating test wrappers for DBD::Gofer: t/zvg_01basics.t t/zvg_02dbidrv.t [...] Creating test wrappers for DBD::Gofer + DBI::SQL::Nano + DBI::PurePerl: t/zvxgnp_48dbi_dbd_sqlengine.t t/zvxgnp_49dbd_file.t t/zvxgnp_50dbm_simple.t t/zvxgnp_51dbm_file.t t/zvxgnp_52dbm_complex.t t/zvxgnp_85gofer.t I see you're using perl 5.008008 on aix-thread-multi-64all, 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 Writing MYMETA.yml and MYMETA.json srvdfj239 /DBI-1.622 # I had to go digging in amongst deleted messages to find this message which I sent you (and not the mailing list) on Friday: On Fri, Aug 3, 2012 at 8:34 AM, Don Walters donrwalt...@gmail.com wrote: [...] -Dprefix=/usr/opt/perl5 -Dcc=xlc_r -Duseshrplib -Dusethreads' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc_r', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=-1 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q64 -DUSE_64_BIT_ALL -q64', [...] Compilers is not really my thing. Currently I'm using /usr/ccs/lib/cpp. Is that not the same thing? /usr/ccs/lib/cpp is the C pre-processor, not the C compiler. DBI.o will not be created by running cpp on a .c file. As already indicated, you will need to install xlc (notice that the names used in the configuration are 'cc_r' and 'xlc_r'). Or, as an alternative but somewhat long winded process, install GCC and build your own Perl using that (and then install DBI). The output from 'perl Makefile.PL' looks fine. We now need to see how you invoke the build (it should be just 'make'), and the output from the build. The part of most interest is the compilation of DBI.o. If you're still using /usr/ccs/lib/cpp, you still have a problem. Assuming you're not doing that, we need to see how DBI.o is being compiled (so we can perhaps guess why the compilation is failing to produce DBI.o). And for those, like me, who don't necessarily keep every message, the original problem was reported as: I'm running Perl in 64bit on AIX5.3. [...] Here is the last part of the output before it fails: Running Mkbootstrap for DBI () chmod 644 DBI.bs rm -f blib/arch/auto/DBI/DBI.so ld -b64 -bhalt:4 -bexpall -G -bnoentry -lpthreads -lc DBI.o -o blib/arch/auto/DBI/DBI.so ld: 0706-005 Cannot find or open file: DBI.o ld:open(): A file or directory in the path name does not exist. make: 1254-004 The error code from the last command is 255. Stop. /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBI-1.57 compile errors
On Thu, Feb 23, 2012 at 09:10, Sergey Prilutsky sprilut...@hotmail.comwrote: Ran into the problem compiling DBI-1.57 over Perl 5.14.2 on SuSE SLES11 SP1 server running on x86 64bit. DBI 1.57 was released in mid-2007, if my records are accurate. The current version is 1.617. It is likely just time you updated to a more recent DBI. Please also note, that the base Perl is 5.10.2 and Perl 5.14.2 is installed in /usr/local/perl5/5.14.2 -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: strawberry perl dbd-informix build
Congratulations, Crispin, and thank you for sharing this. On Mon, Feb 6, 2012 at 09:15, Boylan, Crispin crispin.boy...@logica.comwrote: I’ve managed to build dbd-informix 2011.0612 on Win32 with Strawberry Perl 5.12.3 and Informix CSDK 3.50.TC8 ** ** I’m attaching the changes I had to make here, in case anyone finds it useful. ** ** Any pointers or improvements welcome! it seems to work fine for what I use it for... ** ** To use copy the attached to the same directory as the dbd-informix distribution: ** ** set INFORMIXDIR to the correct place (ie c:\progra~1\ibm\informix\client-sdk) perl strawberrybuild.pl (applies the attached patch and mods the makefiles) gmake gmake install I will look into incorporating this into the official product. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Need help with DBI connect
You have module Apache::DBI which ain't DBI. You need to install DBI (and DBD::Oracle), probably after compiling them. JL --Original Message-- From: Chokhani, Khushboo To: dbi-users@perl.org Subject: Need help with DBI connect Sent: Sep 12, 2011 08:18 Hi, I have been stuck with this error since long now, and have tried almost everything available on web but no luckL Any help would be greatly appreciated. When I try to execute a PERL scripts I am getting an error: ORACLE_HOME=/u01/app/oracle/product/10.2.0 TNS_ADMIN=/usr/local/tns Can't locate object method connect via package DBI at /opt/mabl/agg/dgt/batch-proc/contentdownload/PROD-BBY/bin/DeltaFlag.pm line 67. Before getting this error, I was getting an error where the script was not able to locate the DBI.pm module, hence I pointed my script to use the below path to locate DBI.pm: /u01/app/oracle/product/10.2.0/perl/lib/site_perl/5.8.3/Apache We are migrating from HPUX system to Linux, hence the scripts which we have been using since long are not working as is and they require some changes. Pls help! Thanks! Khushboo Chokhani Wipro Technologies Mobile : +1 (612)-354-1243 Sent from my BlackBerry® smartphone, powered by CREDO Mobile.
Re: Apache:DBI DBD::Informix and dbping
On Thu, Sep 1, 2011 at 02:10, Clive Eisen cl...@serendipita.com wrote: I'm using mod_perl and Informix, and therefore Apache::DBI and DBD::Informix It seems I am running into stale database handles That is to say a connect in my code 'works' but any operation on the dbh fails with a can't call method 'blah' on an undefined value after a time. Reading http://search.cpan.org/~phred/**Apache-DBI-1.10/lib/Apache/** DBI.pm http://search.cpan.org/%7Ephred/Apache-DBI-1.10/lib/Apache/DBI.pm suggests that I need a dbping method and an example is supplied What 'simple' piece of sql do the team suggest? select 1 from systables where tabid =1 That is the simplest one that works in (almost) any Informix database. To be safe against 'MODE ANSI' databases, you'd use: SELECT 1 FROM informix.systables WHERE TabID = 1 This is safe in a MODE ANSI databases, and any version from 4.00 onwards. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2011.0612 - 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 2011.0612 (2011-06-12) released
After 3 years and 1 month bar 1 day, a new version of DBD::Informix hits the
streets - well, CPAN, anyway.
The primary change - support for Perl 5.14.0.
IBM Informix Database Driver for Perl DBI Version 2011.0612 (2011-06-12) has
been uploaded to CPAN.
IBM Informix Database Driver for Perl (also known as DBD::Informix) is
the driver code that enables Perl 5.6.1 or later to access Informix
databases via the DBI module (but if you are not already using Perl
5.10.0 - or any later version - you should be planning to upgrade to
Perl 5.14.0 or later). You will need the code for DBI version 1.38 or
later as well (v1.616 - or any later version - is recommended). The
code for DBD::Informix is available for download via:
http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces
http://dbi.perl.org/
** When you successfully build this module, use the ItWorks (Perl)
** script to report your configuration to the maintenance team (meaning
** Jonathan Leffler) at dbd.infor...@gmail.com.
** The ItWorks script does not send email to anybody; you have to do
** that yourself.
New in release :PRODVER::
* Minor bug fix release.
* Main change is related to Perl internals and avoids the need for
PERL_POLLUTE. This change is not visible to users except that Perl
5.14.x can use the fixed code.
* Fixed problem with string that is not null terminated by ESQL/C library.
* Clean up some 64-bit compilation warnings.
* Build on AIX.
* Evade problem with a DISTINCT type of LVARCHAR with NOT NULL (probably
ESQL/C bug).
* Fewer versions of Informix products are supported. You may try
building DBD::Informix with other versions. If it works, great; if
not, please upgrade to a supported Informix version.
New in release 2008.0513:
* Fix $sth-{TYPE}: return 9 (SQL_DATE) not -1 (SQL_LVARCHAR), fixing an
11-year old bug.
* Add support for BIGINT in ESQL/C 3.50, including $h-{ix_bigserial}.
* CPAN Testers reporting issues because Makefile.PL not exiting
successfully when pre-requisites not met.
* ESQL/C 3.50 (for IDS 11.50) typedefs ifx_loc_t - update dumpesql.h to
cope (Joe R Plugge jrplu...@west.com).
* ESQL/C test fails during configuration when $Config{ccflags} has
leading spaces. Records show this problem also affected Dr Guenther
Seifert guenther-h.seif...@t-systems.com in June 2007. Apologies
for not getting it fixed sooner.
Support email address:
* This release is supported by Jonathan Leffler dbd.infor...@gmail.com.
* You may also report your bugs via the CPAN resolution tracking system:
http://rt.cpan.org/
* Such bug reports can be sent by email to bug-dbd-infor...@rt.cpan.org;
they also get sent to dbd.infor...@gmail.com, etc.
As always, see the ChangeLog file for details about what has changed.
Jonathan Leffler (jleff...@us.ibm.com, jleff...@earthlink.net)
@(#)$Id: Announce,v 2011.1 2011/06/12 22:14:47 jleffler Exp $
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: can $dbh-do take a prepared statement handle?
On Fri, Jun 3, 2011 at 12:06, Jeff Macdonald macfisher...@gmail.com wrote: can $dbh-do take a prepared statement handle? No. See 'perldoc DBI'. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBI and DBD module for perl 5.8.7 and mysql4.1.13
On Thu, May 19, 2011 at 14:41, tim.p...@cox.com wrote: We have an old server that needs to install BDI and DBD module. The server is running with Perl 5.8.7 and MySQL 4.1.13 We have DBI-1.41 and DBD-mysql-2.9003. However, it was failed when I installed these modules. These are the outputs for DBI and DBD: The outputs show that DBI installed OK. They also show DBD::MySQL failed because of /usr/bin/perl /usr/local/lib/perl5/5.8.7/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.8.7/ExtUtils/typemap mysql.xs mysql.xsc mv mysql.xsc mysql.c Warning: duplicate function definition 'do' detected in mysql.xs, line 192 Warning: duplicate function definition 'rows' detected in mysql.xs, line 290 cc -c -I/usr/local/lib/perl5/site_perl/5.8.7/mach/auto/DBI -I/usr/local/include/mysql -O -pipe -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.7/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include -O -pipe-DVERSION=\2.9003\ -DXS_VERSION=\2.9003\ -DPIC -fPIC -I/usr/local/lib/perl5/5.8.7/mach/CORE mysql.c mysql.xs: In function `XS_DBD__mysql__dr__admin_internal': mysql.xs:100: error: too few arguments to function `mysql_shutdown' I don't know what the solution to that is, but there is at least an outside chance that you need to go to a version of DBD::MySQL that supports MySQL 4.x instead of 5.x. At the least, you need to read the release notes with the version you have to see which versions of MySQL are supported. I also tried the latest versions and still failed Did you try a newer version of Perl? -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: (Fwd) Perl DBI on Mac OS X
On Tue, May 3, 2011 at 10:53, david_st...@mcafee.com wrote:
Comments in-line
Now you have to get down to - which ODBC drivers do you have installed?
How can I check?
I don't know. The chances are that if you're using iODBC, it has a way to
do that - maybe via the isql tool.
Do you need the FreeTDS driver, for example?
Probably not. Right now I am using ‘sqlcmd’ from Clapper Software. I may
have installed FreeTDS when I was initially trying to get DB access working.
However, I don’t want to do anything that disables ‘sqlcmd’.
So the Clapper SQLCMD program is able to connect? Can you see the DSN
(connection information) it is using? If so, can you use that, or minor
variations on that, to connect via other programs?
If you're using iODBC, the isql program should allow you to test
connections.
What is the recommended course of action? Do I need to install/uninstall
something? Or is it an ODBC configuration setting I need to change?
In my view (not by any means definitive since I've not actually done it for
the setup you have), you should ensure that you can connect to the DBMS (DB)
using just the ODBC software -- probably using isql or something similar.
Only when you have that ironed out should you try bringing Perl into the
picture.
My general rule of thumb is:
* Get the DB connection working without Perl (+ DBI + DBD::WhatEver)
* Then get it working with Perl (+ DBI + DBD::WhatEver)
The DBD::Informix Makefile.PL enshrines that viewpoint - it compiles a test
program to ensure that you have the software it needs and that you can
connect to some test database before it creates the Makefile needed to build
DBD::Informix. It has saved me endless grief as we separate database
connectivity issues in general from connectivity via Perl. If you can't
connect without Perl, there's no reason to think you'll be successful with
Perl. If you can connect without Perl, then the scope of the problems with
Perl is generally simpler.
Good luck,
Jonathan
*From:* Jonathan Leffler [mailto:jonathan.leff...@gmail.com]
*Sent:* Tuesday, May 03, 2011 11:47 AM
*To:* Stiff, David
*Cc:* dbi-users@perl.org
*Subject:* Re: (Fwd) Perl DBI on Mac OS X
On Tue, May 3, 2011 at 08:15, david_st...@mcafee.com wrote:
Sorry. I meant to say Leopard, not Ubuntu.
MacOS X it is, then...
I am running a test script that lists the drivers and then connects to list
the tables. I get this:
*$ perl testdbi.pl *
Driver: DBM
Driver: ExampleP
Driver: File
Driver: Gofer
Driver: ODBC
Driver: Proxy
Driver: Sponge
That says you've got the Perl + DBI + DBD::ODBC combination installed. You
even have an ODBC driver manager installed.
Now you have to get down to - which ODBC drivers do you have installed?
Do you need the FreeTDS driver, for example?
DBI connect('Driver={SQL
Server};Server=database.domain.com;Database=MyDB','readonly',...)
failed: [iODBC][Driver Manager]Specified driver could not be loaded
(SQL-IM003) [state was IM003 now 0]
[iODBC][Driver Manager]dlopen({SQL Server}, 6): image not found (SQL-0)
at testdbi.pl line 14
Can't connect to DBI:ODBC:Driver={SQL
Server};Server=database.domain.com;Database=MyDB:
[iODBC][Driver Manager]Specified driver could not be loaded (SQL-IM003)
[state was IM003 now 0]
[iODBC][Driver Manager]dlopen({SQL Server}, 6): image not found (SQL-0)
at testdbi.pl line 14.
Thanks,
David
*From:* Jonathan Leffler [mailto:jonathan.leff...@gmail.com]
*Sent:* Tuesday, May 03, 2011 10:27 AM
*To:* Stiff, David; dbi-users@perl.org
*Subject:* Re: (Fwd) Perl DBI on Mac OS X (or Ubuntu?)
On Mon, May 2, 2011 at 19:47, Tim Bunce tim.bu...@pobox.com wrote:
- Forwarded message from david_st...@mcafee.com -
Date: Mon, 2 May 2011 18:40:11 -0700
From: david_st...@mcafee.com
To: tim.bu...@pobox.com
Subject: Perl DBI on Mac OS X
[...] I am new to Perl DBI. I have it working fine on my Windows 7 box.
I have installed the module on Ubuntu and tried running the same test
script but get a connection error:
Your subject line says 'MacOS X'; your comment here says 'Ubuntu'. AFAIK,
those are not synonyms.
Which platform are you actually having the problems on?
DBI connect('Driver={SQL Server};Server=[dsn];Database=[db]','[pwd]',...)
failed: [iODBC][Driver
Manager]Specified driver could not be loaded (SQL-IM003) [state was IM003
now 0]
[iODBC][Driver Manager]dlopen({SQL Server}, 6): image not found
(SQL-0) at testDBI.pl line 14
Can't connect to DBI:ODBC:Driver={SQL Server};Server=[dsn];Database=[db]:
[iODBC][Driver
Manager]Specified driver could not be loaded (SQL-IM003) [state was IM003
now 0]
[iODBC][Driver Manager]dlopen({SQL Server}, 6): image not found
(SQL-0) at testDBI.pl line 14.
Do I need to install another module? Or configure ODBC?
Can you write a pure ODBC program that connects to your database? If so,
what DSN do you use
Re: DB2-DBD error messages
On Thu, Mar 17, 2011 at 04:03, computacenter.geisselbre...@daimler.comwrote: do anyone has experience with such messages when i try to install DB2-DBD driver ? It happens after perl Makefile.PL command was executed. zwtxbt05@videv263perl Makefile.PL Usage: Cwd::fastcwd() at /usr/opt/perl5/lib/5.8.8/aix-thread-multi/DynaLoader.pm line 253. BEGIN failed--compilation aborted at /usr/opt/perl5/lib/site_perl/5.8.8/aix-thread-multi/DBI.pm line 268. Compilation failed in require at Makefile.PL line 13. BEGIN failed--compilation aborted at Makefile.PL line 13. DB2_Home was exported to /home/zwtxbt05/sqllib I've not seen that message, but it appears that something tried to use the function 'fastcwd()' from a package 'Cwd' that is not available with your Perl. You appear to be using Perl 5.8.8. The module is part of the Perl core (and fastcwd() is part of the module) according to http://perldoc.perl.org/Cwd.html. However, was it in 5.8.8? Which version of DBI do you have installed? Did you install it with the same version of Perl? Does the DBI.pm file mentioned reference Cwd::fastcwd (or perhaps just fastcwd) at line 268 or very close by? It is always worth quoting the versions of the software that you are using/installing - Perl, DBI, DBD::DB2 (in this case), and the platform (32-bit AIX, it seems). -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: When might DBI v2 be released
On Tue, Jan 25, 2011 at 07:28, John Scoles sco...@pythian.com wrote: On 25/01/2011 10:25 AM, Jonathan Leffler wrote: Please change the subject line to match the content of the question! (Old subject: DBI 1.611 + DBD::mysql 4.016 = segfaults on Ubuntu 10.10 amd64 ? On Tue, Jan 25, 2011 at 06:54, Tony Espositotony1234567...@yahoo.co.uk wrote: Hello Tim, Just curious, Tim, when is DBI 2.0 to be released? Thanks for all your hard work, by the way. DBI-great_stuff()! IIRC, the plan (if the term is justified for it) is for DBI v2 to be released some time (shortly) after Perl 6 is released. Ah sometime before Easter then;) Is Perl 6 at that stage, or was there no year specified with that Easter (like there hasn't been a year specified for Perl 6 for a while). I gave up tracking Perl 6 a few years ago. I know that Parrot and Rakudo are around and related, but ... (http://dev.perl.org/perl6/faq.html doesn't give any indication of which Easter - and previous announcements from 2009 about 2010 show up with a Google search for 'perl6 release date'). There was (is?) a DBI v2 mailing list - I don't think I've seen any messages on it for about 5 years, and there never were more than a very few. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: compile dbi in aix with gcc
On Mon, Jan 24, 2011 at 07:09, yves.gue...@muhc.mcgill.ca wrote: Dear, I try to compile the dbi module on aix but I got an error (see the build.log). I am not a perl expert (I do not know this language), I have to migrate an application using perl+dbi::mysql Version: DBI-1.616 ExtUtils-MakeMaker-6.57_06 Text-SimpleTable-2.03 perl5 (revision 5 version 8 subversion 9) (see build.log for complete info) aix: AIX axap30 1 6 00C02AC44C00 The key part of the 180 K trace is that (a) the build phase worked without obvious issues, and (b) the test summary gives: Failed TestStat Wstat Total Fail List of Failed --- t/06attrs.t 255 65280 148 294 2-148 t/10examp.t 255 65280 210 420 1-210 t/48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/49dbd_file.t 255 65280?? ?? ?? t/50dbm_simple.t 2 512?? ?? ?? t/51dbm_file.t2 512?? ?? ?? t/52dbm_complex.t 2 512?? ?? ?? t/85gofer.t 255 65280?? ?? ?? t/zvg_06attrs.t 255 65280 148 294 2-148 t/zvg_10examp.t 255 65280 210 420 1-210 t/zvg_48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/zvg_49dbd_file.t 255 65280?? ?? ?? t/zvg_50dbm_simple.t255 65280?? ?? ?? t/zvg_51dbm_file.t2 512?? ?? ?? t/zvg_52dbm_complex.t 2 512?? ?? ?? t/zvg_85gofer.t 255 65280?? ?? ?? t/zvn_48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/zvn_49dbd_file.t 255 65280?? ?? ?? t/zvn_50dbm_simple.t 2 512?? ?? ?? t/zvn_51dbm_file.t2 512?? ?? ?? t/zvn_52dbm_complex.t 2 512?? ?? ?? t/zvn_85gofer.t 255 65280?? ?? ?? t/zvp_06attrs.t 255 65280 148 294 2-148 t/zvp_10examp.t 255 65280 210 420 1-210 t/zvp_48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/zvp_49dbd_file.t 255 65280?? ?? ?? t/zvp_50dbm_simple.t 2 512?? ?? ?? t/zvp_51dbm_file.t2 512?? ?? ?? t/zvp_52dbm_complex.t 2 512?? ?? ?? t/zvp_85gofer.t 255 65280?? ?? ?? t/zvxgn_48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/zvxgn_49dbd_file.t255 65280?? ?? ?? t/zvxgn_50dbm_simple.t 255 65280?? ?? ?? t/zvxgn_51dbm_file.t 2 512?? ?? ?? t/zvxgn_52dbm_complex.t 2 512?? ?? ?? t/zvxgn_85gofer.t 255 65280?? ?? ?? t/zvxgnp_48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/zvxgnp_49dbd_file.t 255 65280?? ?? ?? t/zvxgnp_50dbm_simple.t 255 65280?? ?? ?? t/zvxgnp_51dbm_file.t 2 512?? ?? ?? t/zvxgnp_52dbm_complex.t 2 512?? ?? ?? t/zvxgnp_85gofer.t 255 65280?? ?? ?? t/zvxgp_06attrs.t 255 65280 148 294 2-148 t/zvxgp_10examp.t 255 65280 210 420 1-210 t/zvxgp_48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/zvxgp_49dbd_file.t255 65280?? ?? ?? t/zvxgp_50dbm_simple.t 255 65280?? ?? ?? t/zvxgp_51dbm_file.t 2 512?? ?? ?? t/zvxgp_52dbm_complex.t 2 512?? ?? ?? t/zvxgp_85gofer.t 255 65280?? ?? ?? t/zvxnp_48dbi_dbd_sqlengine.t 255 65280?? ?? ?? t/zvxnp_49dbd_file.t255 65280?? ?? ?? t/zvxnp_50dbm_simple.t2 512?? ?? ?? t/zvxnp_51dbm_file.t 2 512?? ?? ?? t/zvxnp_52dbm_complex.t 2 512?? ?? ?? t/zvxnp_85gofer.t 255 65280?? ?? ?? 30 tests and 225 subtests skipped. Failed 56/178 test scripts. 1428/5109 subtests failed. The section of output for t/06attrs.t is: ok 41 - Simple Hash - Neat numeric ok t/06attrs...1..148 ok 1 - use DBI; dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 2-148 Failed 147/148 tests, 0.68% okay t/07kids1..20 ok 1 - The object isa DBI::db The very start of the log contains: *** You are using a perl configured with threading enabled. Your perl was compiled with gcc (version 4.2.0), okay. I've not seen a failure like that...but maybe this synopsis will help those who have. Possibilities: * Use (build) a non-threaded Perl * Don't use an underscore'd version of ExtUtils::MakeMaker * Update to a more recent Perl (5.12.2, for example) However, I don't think any of those is a prticularly plausible candidate for the source of the trouble. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http
Re: Error on Make command - gcc: odule_wrap.o: No such file or directory
On Thu, Nov 25, 2010 at 00:05, Robert Roggenbuck rrogg...@uni-osnabrueck.de wrote: It looks like a typo to me. Have You tried to look for module_wrap.*? Another possibility - someone mistyped a macro somewhere in the makefile... $module_wrap.c looks for a macro 'm=???', probably doesn't find it (so it maps to an empty string) and then continues with odule_wrap... Am 24.11.2010 19:56, schrieb Mike Towery: Here is what I get when I do that. [r...@l2rac2 DBI-1.615]# gcc -shared -L/usr/local/lib odule_wrap.o -o blib/arch/auto/odule/module.so gcc: odule_wrap.o: No such file or directory gcc: no input files You are absolute correct, it cannot find odule_wrap.o I did a search [r...@l2rac2 /]# find . -name odule_wrap.o not found then I tried odule* [r...@l2rac2 /]# find . -name odule* ./root/perl_db_upgrade/DBI-1.615/blib/arch/auto/odule ./root/perl_db_upgrade/DBI-1.615/blib/lib/auto/odule Thanks for the assistance. What should I do now? On 11/24/2010 12:41 PM, KirovAirShip wrote: Try copy the line gcc -shared -L/usr/local/lib odule_wrap.o -o blib/arch/auto/odule/module.so to your console run it. Can gcc find the file odule_wrap.o ? On Wed, Nov 24, 2010 at 1:30 PM, Mike Towery mtow...@gmail.com mailto:mtow...@gmail.com wrote: I got the following error on the make command. Any help would be appreciated r...@l2rac2 perl_db_upgrade]# cd DBI* [r...@l2rac2 DBI-1.615]# perl /usr/lib/swig1.3/perl5/Makefile.pl Checking if your kit is complete... Looks good Writing Makefile for $module [r...@l2rac2 DBI-1.615]# make cp lib/DBD/Proxy.pm blib/lib/DBD/Proxy.pm [...\ -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Fwd: DBD::Informix -- Failure with make test
Resend - hoping to evade the 50KB limit (and HTML/quoted formatting probably had something to do with breaching that limit). [Eg: gt; =A0Platform:brgt; =A0 =A0osname=3Daix, osvers=3D5.3.0.0, archname= =3Daix-thread-multi-64allbr gt; =A0 =A0uname=3D#39;aix luchda06 3 5 000a= 97d8d600 #39;brgt; =A0 =A0config_args=3D#39;-d -Dcc=3Dcc_r -Duseshrpli= b -Dusethreads -Duse64bitall -Dprefix=3D/usr/opt/perl5_64#39;br ] -- Forwarded message -- From: Jonathan Leffler jonathan.leff...@gmail.com Date: Wed, Jul 21, 2010 at 7:21 AM Subject: Re: DBD::Informix -- Failure with make test To: Julie Bouillon ju...@geekgirls.org Cc: dbi-users@perl.org Sorry for the slow response... On Tue, Jul 20, 2010 at 3:28 AM, Julie Bouillon ju...@geekgirls.org wrote: I'm trying to build DBD::Informix on AIX but when I'm executing a make test, it fails at every test with an unresolved symbol error (ifx_checkAPI). This comes from checkapi.o - or should do. What's puzzling is that the 'library' list correctly includes the object file. ... We are going to use the library list: -lifsql -lifasf -lifgen -lifos -lifgls -ltli -lc_r -lmsaa -lbsd -ldl -lm_r /opt/informix/11.50/lib/esql/checkapi.o -lifglx And the library build command includes the object file: ld -b64 -bhalt:4 -G -bI:/usr/opt/perl5_64/lib/5.12.0/aix-thread-multi-64all/CORE/perl.exp -bE:Informix.exp -bnoentry -lpthreads -lc -lm Informix.o dbdimp.o dbdattr.o sqltoken.o sqltype.o ixblob.o odbctype.o kludge.o link.o esqlcver.o esqlc_v6.o -L/opt/informix/11.50/lib -L/opt/informix/11.50/lib/esql -lifsql -lifasf -lifgen -lifos -lifgls -ltli -lc_r -lmsaa -lbsd -ldl -lm_r /opt/informix/11.50/lib/esql/checkapi.o -lifglx -o blib/arch/auto/DBD/Informix/Informix.so It can't readily be something weird like 'the checkapi.o file does not contain ifx_checkAPI' because the test program compiled and ran. I would take a look at the output of: file dbdimp.o /opt/informix/11.50/lib/esql/checkapi.o If the types quoted are not the same, that may account for some of the problem. Thank you for the thorough and detailed report - it does help cut down the possible problems. For example, I can see that your Perl was built with the latest XLC compiler - I can confidently assert that the CSDK you are using was not. There is seldom a problem because of that - not least because we know the test program worked. So, why isn't the ifx_checkAPI() function found in the library when it is in the object file linked into the library? That is puzzling! [...megasnip...] -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Active State DBI Help!
On Fri, Jul 2, 2010 at 1:57 PM, Jean Lafleur lafj...@gmail.com wrote: I just have Active Perl set up. I need to do some database development. Does it have a DB engine? How do I use it? Please help! If possible, please call me at 203-667-6832. Just by having use DBI; by itself, the perl application would not run. You need Perl and DBI, but you also need the database driver for the DBMS you choose to access, and you need the relevant software to access the DBMS, and the DBMS itself. Without all those bits, you are unlikely to succeed. So, choose your DBMS - install and configure it. Install the client software for your DBMS - and confiugure that. Then get the relevant DBD::your-dbms-here driver and install that. Now you might be able to get Perl to talk to the DBMS - if you got everything right. If you're familiar with your DBMS and its setup, then the first two steps aren't painful; if you're new to the DBMS, the first steps tend to be more painful. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Building 32-Bit ONLY Perl on Mac OSX
On Tue, Jun 15, 2010 at 1:48 PM, kai.schwerm...@bill-x.de wrote: my question isn't directly related to DBI, but i need to compile a 386/32 Bit ONLY Perl Binary on Mac OSX 10.6 (SnowLeopard), not only but also because we only have a 32 Bit Oracle Instant Client... No Matter what Config-Params i tried, the only thing i get is the following: ...file was built for i386 which is not the architecture being linked (x86_64)... Does anyone have an idea or a good link? The way I've always built Perl with specific bittiness is by specifying that the compiler is 'cc -m32' or 'cc -m64'. Just to check that it still works, I've just built Perl 5.12.1 on MacOS X 10.6.4 (released earlier this week), direct from source. It took me 3 or 4 goes to get the config right because I got return-happy and missed the questions that need a non-standard answer. /Users/jleffler/perl/v5.12.1-32bit/bin/perl: Mach-O executable i386 /Users/jleffler/perl/v5.12.1/bin/perl: Mach-O 64-bit executable x86_64 /usr/bin/perl: Mach-O universal binary with 3 architectures /usr/bin/perl (for architecture x86_64):Mach-O 64-bit executable x86_64 /usr/bin/perl (for architecture i386):Mach-O executable i386 /usr/bin/perl (for architecture ppc7400):Mach-O executable ppc The really tricky question was the one about building shared libraries - it was: What command should be used to create dynamic libraries? [env MACOSX_DEPLOYMENT_TARGET=10.3 cc] I had to add '-m32' to that by typing '$1 $2 $3 -m32'. For the rest, I ensured that the software was installed where I wanted it (/Users/jleffler/perl/v5.12.1-32bit) and almost everything else was left at default - I decline to use vfork(). It took, oh, 20 minutes to build and test - probably less; I set it running while I went swimming with the kids, and it was done long before I got back. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: (Fwd) Help in installing DBD - DB2 for Perl
On Wed, Jun 2, 2010 at 1:36 AM, Tim Bunce tim.bu...@pobox.com wrote: - Forwarded message from raghav sridharan raghava...@yahoo.co.in - Date: Wed, 2 Jun 2010 06:56:01 +0530 (IST) From: raghav sridharan raghava...@yahoo.co.in To: tim.bu...@pobox.com Subject: Help in installing DBD - DB2 for Perl HelloTim, I am trying to install DBD-DB2 using the command ppm install DBD-DB2.ppd But I am getting the below error: ppm install failed The PPDdoes not provide code to install for this platform Can you please help ? I think that means that there is no pre-compiled version of DBD::DB2; you will need to be able to compile it for yourself. Alternatively, it means your network configuration is such that PPM/PPD does not work. However, it is much more likely that the module is not available. Use CPAN to obtain it. The current version appears to be 1.78, from January 2010. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: How to set LD_LIBRARY_PATH
On Sun, May 30, 2010 at 10:47 AM, Marilyn Sander marilyn-san...@earthlink.net wrote: [...] My reasoning was that the thing being loaded is a shared object (.so file). The system loader (ld) has to be invoked for loading a shared object. That seems to me to require a separate process, with an environment stack inherited from the Perl process that invokes it. There's a problem here. What you describe is not what happens. The system loader, ld, is used to create executables and shared objects. It indeed is a separate program that is most often invoked automatically by a compiler - GCC for example. There is a wholly separate module, often with a name such as ld.so.1, which is the dynamic library loader. It is actually a part of the program you are running - Perl in the current context. It is responsible for loading other shared libraries into the current process. Dynamically loading a shared library adds the code to the current process; it does not invoke a separate program/process. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: How to set LD_LIBRARY_PATH
The dynamic loader read LD_LIBRARY_PATH when (before?) Perl gets going. AFAIK,
it doesn't reread it, so changing it in Perl code is too late unless you set
it and exec your code again (which is basically saying it is too late).
I'm tolerably certain this applies to Solaris; I think it applies elsewhere too.
JL
Sent from my BlackBerry® smartphone, powered by CREDO Mobile.
-Original Message-
From: newbie01 perl newbie01.p...@gmail.com
Date: Fri, 28 May 2010 19:45:14
To: beginnersbeginn...@perl.org; dbi-usersdbi-users@perl.org
Subject: How to set LD_LIBRARY_PATH
Hi all,
Can someone advise how to set LD_LIBRARY_PATH from within the Perl scripts?
If I set LD_LIBRARY_PATH from the command line, all is okay
[oracle ~]$ perl -e 'use DBD::Oracle; print $DBD::Oracle::VERSION,\n;'
Can't load
'/oracle/product/db/11.1/perl/lib/site_perl/5.8.3/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so'
for module DBD::Oracle: libclntsh.so.11.1: cannot open shared object file:
No such file or directory at
/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi/DynaLoader.pm line 230.
at -e line 1
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
[oracle ~]$ export LD_LIBRARY_PATH=/oracle/product/db/11.1/lib
[oracle ~]$ perl -e 'use DBD::Oracle; print $DBD::Oracle::VERSION,\n;'
1.15
But if I do the following instead in the Perl script, it does not work? How
to set the LD_LIBRARY_PATH then?
$ENV{ORACLE_HOME}=$ORACLE_HOME;
$ENV{ORACLE_SID}=$ORACLE_SID;
$ENV{PATH}=$ORACLE_HOME/bin:$PATH;
$ENV{LD_LIBRARY_PATH}=$ORACLE_HOME/lib;
FYI, the script is to run from a cron which is why am setting
LD_LIBRARY_PATH in the script.
Any response will be very much appreciated. Thanks in advance.
Re: Trying to safely compare user input name against database
As it stands, you have a major SQL injection vulnerability; consider a name
such as
O'or 1=1
This will modify your SQL so that many rows match. Putting the string into a
call to UPPER changes what is required to break in, but gives no real extra
protection.
Using placeholders is crucial.
Sent from my BlackBerry® smartphone, powered by CREDO Mobile.
-Original Message-
From: Larry W. Virden lvir...@gmail.com
Date: Mon, 3 May 2010 11:30:28
To: dbi-users@perl.org
Subject: Trying to safely compare user input name against database
I've a case where a function is called with a string provided by a
user, and some legacy code then puts that string into a select
statement for dbi. The code currently reads:
my ($query) = $dbconn-prepare(
Select * from my_table where last_name LIKE
'$SearchName');
$query-execute() or return \...@retval; #problem return empty array
Now, one of the issues that comes up is the situation where the user's
string doesn't match the case of the name in the table.
For instance, if they pass a McDonnel as the string, but in the
table, it is Mcdonnel, of course there is no match.
So, I was thinking of modifying this to read
my ($query) = $dbconn-prepare(
Select * from my_table where UPPER(last_name) LIKE
UPPER('$SearchName'));
Are there any gotchas in going this route? Is there a better way of
doing this?
Re: DBI/DBD question
On Tue, Apr 27, 2010 at 11:17 AM, Royce Miller royce...@pacbell.net wrote:
I am taking over the Perl stuff for someone that was laid off. The
previous guy built Perl with CGI, DBI and DBD modules for use with a
Informix database and IBM IHS web server. He then tar'd it all up and
copied it to a different server and where thing do not all working. I know,
sounds obvious. There are some scripts that are interactive or run by Unix
CRON scheduler on the system and others that are web pages used for
reporting. The interactive stuff works fine on the new system, but the web
pages fail.
The error is:
Software error:
install_driver(Informix) failed: Can't load
'/home/users/polling/perl/lib/site_perl/5.8.8/sun4-solaris-64/auto/DBD/Informix/Informix.so'
for module DBD::Informix: ld.so.1: SdtQuery.pl: fatal: libifsql.so: open
failed: No such file or directory at
/home/users/polling/perl/lib/5.8.8/sun4-solaris-64/DynaLoader.pm line 230.
at (eval 32) line 3 Compilation failed in require at (eval 32) line 3.
Perhaps a required shared library or dll isn't installed where expected
at /home/users/polling/SDT-2.0/SDT/SDTDB.pm line 443
This is Perl 5.8.8 running on Solaris 2.8 on V490 Hardware. All is 64 bit.
I am considering rebuilding these modules. I have the source for DBI and
DBD but don't seem to have the source for CGI. I figured I would check with
the pros before I start doing things.
Any ideas or suggestions?
Thank you for your time!
Royce
Dear Royce,
This is all about Informix and nothing to do with CGI per se - as others
have said. In future, please include DBD::Informix in the subject line - it
helps me spot that the question is about Informix. Or copy the email
address dbd.infor...@gmail.com with the request too. This information is in
the README file for DBD::Informix.
You should find under one of the DBD/Informix directories (probably
/home/users/polling/perl/lib/site_perl/5.10.1/sun4-solaris-64/DBD/Informix)
you should a file Defaults.pm. In there, you should find a value for
INFORMIXDIR.
sub default_INFORMIXDIR
{
return '/usr/informix/11.50.FC3';
}
sub default_INFORMIXSERVER
{
return 'black_19';
}
This is from my machine (Solaris 10, Perl 5.10.1).
You need to ensure that the LD_LIBRARY_PATH (or LD_LIBRARY_PATH_64) includes
the directories:
$INFORMIXDIR/lib
$INFORMIXDIR/lib/esql
If the specified directory does not exist, then you need to review what to
do next. Options include (1) creating a symlink at the official location
pointing to the current in-service $INFORMIXDIR, (2) poking around the
ld.so.1 configuration with crle (intuitive name!) to add Informix
directories to the system list of directories, or (3) rebuilding
DBD::Informix to use the new location of $INFORMIXDIR.
Option (3) may be the 'best' solution. You can also build DBD::Informix
with the environment variable DBD_INFORMIX_RELOCATABLE_INFORMIXDIR set to 1
or yes or anything else that Perl will evaluate as 'true' (so not empty, nor
0). This means that the libraries will be linked solely via the
LD_LIBRARY_PATH or crle settings - rather than having a path built in. This
is more typically a nuisance (especially in contexts such as web servers -
because web servers reset their environment completely and zap the inherited
value for LD_LIBRARY_PATH) and is not the default behaviour.
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: (Fwd) How to loop through a database, row by row, and select and update one row at a time
On Tue, Apr 13, 2010 at 1:56 AM, Tim Bunce tim.bu...@pobox.com wrote:
- Forwarded message from Troy Mulder mulde...@gmail.com -
Date: Mon, 12 Apr 2010 17:48:37 -0400
From: Troy Mulder mulde...@gmail.com
To: tim.bu...@pobox.com
Subject: How to loop through a database, row by row, and select and update
one row at a time
Hello Tim (is it Dr. Bunce?),
My name is Troy Mulder, and I am trying to get a perl script to interface
with a PostgreSQL database. I
am trying to step through each row of the database, and read one column
of the row, and update another
column of the row.
When I follow the online tutorial and use the $sth =
$dbh-fetchrow_array() method in a while condition,
as follows:
while ( @xml_content = $sth-fetchrow_array() ) {
I am able to select the two columns of interest. And I can do this for
LIMIT 10 rows with no problem,
just using the select command as in:
while ( @xml_content = $sth-fetchrow_array() ) {
$sth = $dbh-prepare(SELECT msgid, xmlcontent FROM messages WHERE msgid
= 1892362);
print Message ID = $msgid\n;
$sth-execute();
}
However, when I put any sort of an update command after that, as in:
while ( @xml_content = $sth-fetchrow_array() ) {
$sth = $dbh-prepare(SELECT msgid, xmlcontent FROM messages WHERE msgid
= 1892362);
print Message ID = $msgid\n;
$sth-execute();
$update_cmd = UPDATE messages SET alteredcontent = '$alteredmsg' WHERE
msgid = $msg_id;
$sth = $dbh-do($update_cmd);
Here is the problem.
You clobber $sth - so it doesn't work.
In fact, $dbh-do(..) doesn't return a statement handle at all.
}
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Official DBI module for Solaris Box
On Tue, Mar 23, 2010 at 2:49 PM, Parag Kalra paragka...@gmail.com wrote: Surprised to see no response yet. :-) Well, the question is a bit odd too...I'll attempt to address the original too. Anyways few more questions - For which version of Perl on Solaris, does DBI comes integrated with Perl or is it like on Solaris we always explicitly need to install DBI module externally. DBI is not distributed as standard on Solaris. If the customer has valid support contract, can Sun Support help to get DBI installed? Unlikely. On Sat, Mar 20, 2010 at 7:31 PM, Parag Kalra paragka...@gmail.com wrote: I am facing this situation where I have coded a Perl framework on Windows and its all working fine. The framework mostly uses DBI and ODBC module to connect to both Oracle server, execute SQL queries, fetch Rows etc etc. OK - so far, so good. Now the customer wants to use the framework on a Solaris machine (it has Perl installed - 5.8.4). However that Solaris machine doesn't have DBI module as a result of which I can't use my framework. But it has Oracle client installed using which (sqlplus, sqlldr etc) I am able to connect to the Oracle DB Server (located remotely) This is perfectly normal - Perl on Sun does not come with DBI. Since Perl is provided by the o/s, I regard it is dubious, if not dangerous, to tinker with the system Perl. Besides, its usually archaic - so I always install the version of Perl I want on the machine, out of the way of the main system-provided Perl. That way, the o/s can use its version unmolested by me, and I can use my version unrestrained by the o/s. The best solution here seems to get the DBI module installed using Sun Support. Does Sun provide support for Perl modules (particulary DBI) on its own OS - Solaris? Doubtful. Ask Sun. But assume the answer is no. Customer doesn't want to install anything third party that didn't come pre-installed with Solaris box. This is weird...so, how is your application ever going to run? And how did Oracle get installed? It is not a part of base Solaris. However he may give a thought to installing new version of standalone Perl which will have DBI module integrated. I guess Perl 5.10.1 has DBI present by default. Could someone please confirm. Guess again. You have to add DBI to Perl. In addition to DBI do I need any other module to connect to Oracle DB from a Solaris machine? You're going to need a DBD module - presumably DBD::Oracle. Is there any other way I can convince the client that Perl is good OpenSource tool and certainly not a malacious software. Probably not. Also more solutions to install DBI module on Solaris are most wellcome. Either you're allowed to install software or you are not. If you are allowed, go ahead and install what you need. If you are not allowed, then leave the customer gently stewing in their own juice. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Perl 5.6.1 supports DBI module
On Thu, Mar 18, 2010 at 8:32 AM, Peram, Sudhakara sudhakara.pe...@pfizer.com wrote: I am working on Perl 5.6.1 version for my web application. Why? Why not 5.6.2, 5.8.8 or 5.8.9, or even (bravado) 5.10.1? I want to know whether perl5.6.1 supports the DBI module or not, if it supports the what is the version of DBI module. If you choose an old enough version of DBI, then yes. You might have to go to the BackPan though, instead of CPAN. Hmm; 1.49 dropped support for 5.6.0 (only supporting 5.6.1 or later). Up to 1.609, I can see no mention of not supporting 5.6.1. So, DBI 1.609 should work for you. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: (Fwd) DBD::Oracle - Issues Compiling DBI
On Mon, Feb 1, 2010 at 2:43 PM, Prindle, Douglas E douglas.e.prin...@citi.com wrote: Being first time through this process when I did the make it was looking for the gcc compiler. My company has made that End Of Life due to it being a sunsetted product. So I switched to the Forte 11 compiler from Sun which we have had no issues with compiling other existing c code. As others noted, it is odd to think that GCC is 'EOL'. Maybe they just meant the specific antique version? Anyway... However, when I try to make the DBI after pointing it to the new Forte compiler I am getting a series of errors that seem to point to the DBI.c and DBI.xs files as having issues. The problem is that you are using a C++ compiler (CC in all caps is the C++ compiler; cc in lower case is the C compiler). How did you build Perl with CC? If you didn't (as I expect you didn't), then don't compile modules with CC either. Actually, don't build modules with a C++ compiler; they are C code and not C++ code. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Missing informix error messages
On Thu, Jan 14, 2010 at 8:49 AM, m. allan noah kitno...@gmail.com wrote: I have a problem with some fastcgi scripts which use DBD::Informix. I trust this is DBD::Informix 2008.0513 and not some earlier version. Which version of Perl are you using? Which platform are you running on? Which version of Informix ClientSDK (ESQL/C) are you using? Fastcgi is like regular cgi, except the script does not exit after the request is complete, it loops back to the beginning, and waits for a new request. This significantly improves performance for scripts with large startup penalties. The scripts are single threaded, with apache spawning new copies as required. I am connecting and disconnecting from the db on each request. Everything works fine, except that sql error messages can only be found on the first pass thru the fastcgi loop. e.g. DBD::Informix::st execute failed: SQL: -268: Unique constraint (informix.u116_31) violated. ISAM: -100: ISAM error: duplicate value for a record with unique key. On the subsequent passes i get: DBD::Informix::st execute failed: SQL: -268: Failed to locate SQL error message ISAM: -100: Failed to locate ISAM error message I've not seen that behaviour before that I recall. How reliable is it? 100%? Sometimes? Seldom but often enough to be annoying? I have dumped the environment on both passes, and they are identical, including all the informix vars. I cannot reproduce this issue with a command line script, so I might have to ask some apache/fastcgi hackers too, but I thought I would start here. Normally, once the code has found the error messages once, there is no further problem. It is very unusual - indeed, I'm not sure I have any explanation of a mechanism by which it can happen. The best I can come up with as a 'debugging' mechanism is to suggest that you add tracing to the system - DBI_TRACE=3 (or higher) in the environment or an equivalent. Offhand, I'm not sure where the output would go with FastCGI in the system; you might need to work on the output file too. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBI failure on OSX 10.6.2
definition 'rows' detected in mysql.xs, line
650
/usr/bin/gcc-4.2 -c
-I/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBI
-I/usr/local/mysql/include -g -Os -arch i386 -fno-common
-D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ
-DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL
-DDBD_MYSQL_INSERT_ID_IS_GOOD -g -fno-common -DPERL_DARWIN
-I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe
-I/usr/local/include -I/opt/local/include -O3 -DVERSION=\4.013\
-DXS_VERSION=\4.013\ -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE
mysql.c
Running Mkbootstrap for DBD::mysql ()
chmod 644 mysql.bs
rm -f blib/arch/auto/DBD/mysql/mysql.bundle
LD_RUN_PATH=/usr/local/mysql/lib /opt/local/bin/perl myld env
MACOSX_DEPLOYMENT_TARGET=10.3 /usr/bin/gcc-4.2 -L/opt/local/lib -bundle
-undefined dynamic_lookup -L/usr/local/lib dbdimp.o mysql.o -o
blib/arch/auto/DBD/mysql/mysql.bundle \
-L/usr/local/mysql/lib -lmysqlclient -lz -lm -lmygcc \
chmod 755 blib/arch/auto/DBD/mysql/mysql.bundle
cp mysql.bs blib/arch/auto/DBD/mysql/mysql.bs
chmod 644 blib/arch/auto/DBD/mysql/mysql.bs
Manifying blib/man3/DBD::mysql.3pm
Manifying blib/man3/DBD::mysql::INSTALL.3pm
Manifying blib/man3/Bundle::DBD::mysql.3pm
# Ooops. Test not so good.
peter-hesps-macbook:DBD-mysql-4.013 peterhesp$ make test
PERL_DL_NONLAZY=1 /opt/local/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'blib/lib', 'blib/arch') t/*.t
t/00baseok 1/6
# Failed test 'use DBD::mysql;'
# at t/00base.t line 21.
# Tried to use 'DBD::mysql'.
# Error: Can't find 'boot_DBD__mysql' symbol in
/Users/peterhesp/Downloads/DBD-mysql-4.013/blib/arch/auto/DBD/mysql/mysql.bundle
# at (eval 5) line 2
# Compilation failed in require at (eval 5) line 2.
# BEGIN failed--compilation aborted at (eval 5) line 2.
t/00baseNOK 2/6FAILED--Further testing stopped: Unable
to load DBD::mysql
make: *** [test_dynamic] Error 255
peter-hesps-macbook:DBD-mysql-4.013 peterhesp$
On Tue, Dec 22, 2009 at 10:03 PM, Peter Hesp pe...@peterhesp.com
wrote:
Hi and merry Xmas,,
I have been trying install DBI for mysql on my, recently upgraded to
'snow
leopard', Mac Book with no luck.
I have included the requested output from the installation process,
which
appeared to me to be OK but when tried my test script also included I
could not connect to the database.
If you can check this out and advise of a solution or direct me to on it
would be greatly appreciated.
Thanks
Peter Hesp.
peter-hesps-macbook:DBI-1.609 peterhesp$ perl Makefile.PL
Your perl was compiled with gcc (version 4.2.1 (Apple Inc. build 5646)),
okay.
[...log of successful build of DBI stripped...]
All tests successful, 34 tests and 379 subtests skipped.
Files=130, Tests=5825, 46 wallclock secs (36.79 cusr + 6.54 csys =
43.33
CPU)
___
A TEST SCRIPT TO CONNECT TO THE DB
#!/opt/local/bin/perl -w
use strict;
use DBI;
my ( $user, $passwd, $connString);
($connString, $user, $passwd) =
(dbi:mysql:database=contacts;host=localhost, 'root','***');
my $dbh = DBI-connect($connString)
or die Couldn't connect to database: . DBI-errstr;
my $sth = $dbh-prepare('SELECT * FROM people ')
or die Couldn't prepare statement: . $dbh-errstr;
$sth-execute() ;
AND ITS OUTPUT
peter-hesps-macbook:cgi-bin peterhesp$ ./th_db.pl
dyld: lazy symbol binding failed: Symbol not found: _mysql_init
Referenced from:
/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBD/mysql/mysql.bundle
Expected in: dynamic lookup
dyld: Symbol not found: _mysql_init
Referenced from:
/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBD/mysql/mysql.bundle
Expected in: dynamic lookup
Trace/BPT trap
Now show us the successful build of DBD::MySQL?
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: DBI failure on OSX 10.6.2
On Tue, Dec 22, 2009 at 10:03 PM, Peter Hesp pe...@peterhesp.com wrote:
Hi and merry Xmas,,
I have been trying install DBI for mysql on my, recently upgraded to 'snow
leopard', Mac Book with no luck.
I have included the requested output from the installation process, which
appeared to me to be OK but when tried my test script also included I
could not connect to the database.
If you can check this out and advise of a solution or direct me to on it
would be greatly appreciated.
Thanks
Peter Hesp.
peter-hesps-macbook:DBI-1.609 peterhesp$ perl Makefile.PL
Your perl was compiled with gcc (version 4.2.1 (Apple Inc. build 5646)),
okay.
[...log of successful build of DBI stripped...]
All tests successful, 34 tests and 379 subtests skipped.
Files=130, Tests=5825, 46 wallclock secs (36.79 cusr + 6.54 csys = 43.33
CPU)
___
A TEST SCRIPT TO CONNECT TO THE DB
#!/opt/local/bin/perl -w
use strict;
use DBI;
my ( $user, $passwd, $connString);
($connString, $user, $passwd) =
(dbi:mysql:database=contacts;host=localhost, 'root','***');
my $dbh = DBI-connect($connString)
or die Couldn't connect to database: . DBI-errstr;
my $sth = $dbh-prepare('SELECT * FROM people ')
or die Couldn't prepare statement: . $dbh-errstr;
$sth-execute() ;
AND ITS OUTPUT
peter-hesps-macbook:cgi-bin peterhesp$ ./th_db.pl
dyld: lazy symbol binding failed: Symbol not found: _mysql_init
Referenced from:
/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBD/mysql/mysql.bundle
Expected in: dynamic lookup
dyld: Symbol not found: _mysql_init
Referenced from:
/opt/local/lib/perl5/site_perl/5.8.9/darwin-2level/auto/DBD/mysql/mysql.bundle
Expected in: dynamic lookup
Trace/BPT trap
Now show us the successful build of DBD::MySQL?
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: dbi installation fail
On Mon, Oct 5, 2009 at 10:09 PM, F.A.I.Z.A.L sac.fai...@gmail.com wrote: hi Leffer.. Hi Faial...names look funny with missing letters, don't they? gcc version output *andd141# perl -V:gccversion* gccversion='3.4.6'; *andd141# gcc --version* gcc (GCC) 3.3.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I was try to upgrade this version using gcc-3.4.6 but its not updating.. any idea? Ummm... what does trying to upgrade but it is not updating mean? When I try to upgrade GCC, one of two things happens: (1) I download the source and build it, install it, and then make sure I use the new version instead of the old. (2) I download a pre-built version, install it, and then make sure I use the new version instead of the old. In case of doubt, I remove the old version too - but I don't often have doubts and the old versions are not on my PATH and hence are not findable (because they aren't in easily predictable places like under /usr/local/). In fact, I have versions 3.4.6, 4.2.3, 4.3.3 and 4.4.1 on my Solaris box at the moment - and other people have a stray copy of 3.4.6 and a 3.4.3 on there too (what fun; I didn't know about those two until I went looking). Clearly, you have to ensure that your PATH is set up to pull in the correct version of GCC once it is installed. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBD- Oracle installation on HP-UX machine
On Tue, Oct 6, 2009 at 9:30 PM, Umaparvathy Krishnan umaparvathy.krish...@oracle.com wrote: Need a favour from you.I am trying to install DBD::Oracle module in the machine of HP-UX. Facing the error as below.Please help me $ make rm -f blib/arch/auto/DBD/Oracle/Oracle.so /usr/bin/ld -Wl,+b/oracle/ora10g/OraHome/lib32:/usr/lib/hpux32 -b +vnocompatwarnings -L/usr/lib/hpux32 Oracle.o dbdimp.o oci8.o -o blib/arch/auto/DBD/Oracle/Oracle.so -L/oracle/ora10g/OraHome/lib32 -lclntsh -lm -lpthread -lunwind -lnsl ld: Unrecognized argument: -Wl,+b/oracle/ora10g/OraHome/lib32:/usr/lib/hpux32 Fatal error. *** Error exit code 1 Stop. This strongly suggests to me that you are using a pre-built Perl that was not built with the toolchain (C compiler, assembler and loader) you have installed. So, where did you get Perl from? Did you build it yourself? (I'm 99% positive the answer to that is no. And for the residual 1%, almost all of that says Yes, I built it on machine A but I'm now building DBD::Oracle on machine B.) You need to look at the output from 'perl -V' and look at the compiler and linker sections. Since Perl was built with a loader (linker) that should recognize the -Wl,+b... notation - or with a C compiler which knows how to translate that into a '+b/oracle/ora10g/...' argument for the loader - what you've got is not the same as what was used to build Perl. Your choices are simple: * Build Perl with what you've got. * Get the tools used to build Perl and build the DBD::Oracle module with them. And, in future, please ask the list the question - not me directly. I might still answer... -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: make: 1254-004 The error code from the last command is 127.
YOu have to build extensions with the compiler used to build Perl. Either get the AIX C compiler or rebuild Perl with GCC. On Tue, Sep 8, 2009 at 3:36 AM, Putrino Nunzio ABRAXAS INFORMATIK AG nunzio.putr...@abraxas.ch wrote: I've to install DBI and DBD::Oracle http://www.pythian.com/news/dbd-oracle on AIX (see APPENDIX for all details) version 6.1. [...snip...] Unfortunately, we don't have the cc-Compiler. Therefore, whe I launch the make utility I get the error: cc_r -c-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -qnoansialias -DUSE_NATIVE_DLOPENDNEED_PTHREAD_INIT -q32 -D_LARGE_FILES -qlonglong -O-DVERSION=\1.609\ -DXS_VERSION=\1.609\ -I/u sr/opt/perl5/lib/5.8.2/aix-thread-multi/CORE Perl.c /bin/sh: cc_r: not found. make: 1254-004 The error code from the last command is 127. Because we have only gcc-4.2.0-3 installed, I'd modify the current make-file and use the macro make MAKERULES=/my_pathname/nunzio_make by modifying the value for CC=cc to CC=gcc-4.2.0-3 The problem and therefore the reason for this mails is: Do you possible have the compiler option for gcc such that I can substitute the cc-comand? cc_r -c-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -qnoansialias -DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -q32 -D_LARGE_FILES -qlonglong -O-DVERSION=\1.609\ -DXS_VERSION=\1.609\ -I/u sr/opt/perl5/lib/5.8.2/aix-thread-multi/CORE Perl.c No - you can't realistically persuade GCC to behave as a surrogate for the AIX compiler. It is incredibly hard to do, and the alternatives are much simpler. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBI compiling error on solaris box
On Mon, Sep 7, 2009 at 4:24 AM, chethan@wipro.com wrote: I am trying to install DBI on a solaris box hosting oracle. [...] sh: cc: not found You need to install the Sun C compiler. (No, using GCC is not a serious option.) -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Announce: DBI 1.609
CPAN Terminal i DBI [MSG] Checking if source files are up to date [MSG] Updating source file '01mailrc.txt.gz' [MSG] Trying to get ' ftp://mirrors.kernel.org/pub/CPAN/authors/01mailrc.txt.gz' [MSG] Updating source file '03modlist.data.gz' [MSG] Trying to get ' ftp://mirrors.kernel.org/pub/CPAN/modules/03modlist.data.gz' [MSG] Updating source file '02packages.details.txt.gz' [MSG] Trying to get ' ftp://mirrors.kernel.org/pub/CPAN/modules/02packages.details.txt.gz' [MSG] No '/work1/jleffler/.cpanplus/custom-sources' dir, skipping custom sources [MSG] Rebuilding author tree, this might take a while [MSG] Rebuilding module tree, this might take a while [MSG] No '/work1/jleffler/.cpanplus/custom-sources' dir, skipping custom sources [MSG] No '/work1/jleffler/.cpanplus/custom-sources' dir, skipping custom sources [MSG] Writing compiled source information to disk. This might take a little while. Installing DBI (1.609) [MSG] Module 'DBI' already up to date, won't install without force *** Install log written to: /work1/jleffler/.cpanplus/install-logs/DBI-1.609-1245036108.log Module 'DBI' installed successfully No errors installing all modules CPAN Terminal So, at my CPAN mirror (mirrors.kernel.org), DBI 1.609 is already available - I installed it before today (like the day it was announced, I think). I suggest checking your CPAN mirror, and maybe trying a different one. On Sun, Jun 14, 2009 at 8:06 PM, Greg Eldridge g...@ie-entertainment.comwrote: Hello, On Fri, 2009-06-12 at 17:10 -0500, Scott T. Hildreth wrote: On Fri, 2009-06-12 at 14:38 -0700, Greg Eldridge wrote: How long until it moves into cpan[0] install DBD ?? typo? should be 'install DBI' or 'install Bundle::DBI' On Tue, 2009-06-09 at 16:46 +0100, Tim Bunce wrote: file: $CPAN/authors/id/T/TI/TIMB/DBI-1.609.tar.gz size: 510309 bytes md5: e4689870b3f7ce503022a076c53284ed cut Thanks for correcting a typo.. My question still stands - given the following: as of Sun Jun 14 13:34:01 PDT 2009 cpan[3] install DBI DBI is up to date (1.608). == !=1.609 What is the general/average lead/follow-up time for the install to be rolled up into cpan[n] install ?? Yes, I do know that I can get and build from: Thanks in advance. Greg Eldridge -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: DBI Make error
On Thu, May 14, 2009 at 2:28 PM, Ritesh patel rpatel...@yahoo.com wrote: I am trying to install DBI module on AIX 5.3 for perl 5.8.2 64bit. During software build I am getting error. Does anyone has any idea? /bin/sh: cc_r: not found. You don't have a C compiler (or the correct C compiler) installed. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Can selectrow_array() et al detect non-select statements?
Question on StackOverflow:
http://stackoverflow.com/questions/834712/perl-dbi-and-dbdinformix-error/834856
--
$db_handle=DBI-connect($dbstr, , ,
{RaiseError = 0, AutoCommit = 0, PrintError = 1})
|| die Connect error: $DBI::errstr ;
$result=$db_handle-selectrow_array(set isolation to dirty read);
--
Note:$dbstr is a valid database name.
I am not a Database programmer.
What am I doing wrong which is causing the perl script fail saying:
*DBD::Informix::db selectrow_array failed: SQL: -400: Fetch attempted on
unopen cursor.*
Verrsion information not given - but not dreadfully material.
Can/should the selectrow_array() method provided by DBI detect that the
statement is not one that returns values and generate a more meaningful
error, rather than just letting/making the driver fabricate an error?
I'm thinking that it should check NUM_OF_FIELDS for a non-zero value after
the successful execute. In one sense, the damage may already be done
(suppose it was a DELETE statement?).
--
Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: [Slight OT] DBD/DBIx::Chart need patent protection, know any contacts ?
On Thu, Feb 19, 2009 at 2:16 PM, Dean Arnold darn...@presicient.com wrote: (Sorry if this is OT, but I'm hoping someone can point me in the right direction) Someone has just alerted me to the following patent attempt by our friends at IBM: Data Plotting Extension for Structured Query Language (http://www.freepatentsonline.com/y2008/0215554.html) Given that DBD::Chart predates the filing by at least 7 years (in fact, you can still get a version from CPAN from 2002, and I think BackPAN may have stuff from 2000/2001), I'd like to make sure this thing gets killed. Does anyone know an open source patent holding group, or someplace I can submit prior art claims ? From the link you gave... Title: * Data Plotting Extension for Structured Query Language * Document Type and Number: United States Patent Application 20080215554 Kind Code: A1 Abstract: Information is typically obtained from a relational database using a query in structured query language (SQL). An extension to the SQL standard is described which permits plotting the results of a query. SQL keywords are provided for specifying a format for graphing selected data, and syntax for recognizing those keywords, thereby causing the data to be presented as a graph according to the specified format. This extension of SQL maintains the syntax and style of conventional SQL queries. This permits automated systems, such as database driven websites, to issue extended SQL queries directly to a relational database and have the results returned as formatted graphical content. In what sense does DBIx::Chart modify the SQL recognized by the DBMS that it is built on? Prima facie, there is not much connection between what DBIx::Chart does in presenting data by using standard SQL to fetch it and then transform the data into a chart and what the patent abstract suggests - modify the SQL language recognized by the DBMS. OK - I'm one of the bad guys - I work for IBM, and I do work related to patents some of the time. But IANAL (and especially not a patent lawyer). However, DBIx::Chart is in no mortal danger from this patent, and DBIx::Chart is not a threat to this patent. Now, I've not read the patent in more detail than the information above - so I could be being misled by the description. But that is my immediate take on it. Two ships passing in the night, coincidentally headed to the same place (charting data from SQL databases) but getting there by different courses and not interfering with each other. If you would like me to trawl through my records, I may be able to find some organizations that handle issued patents and prior art. However, you would have to demonstrate in considerable detail how DBIx::Chart covers what this invention claims. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: (Fwd) Views on DBI 2.0
Date: Mon, 29 Dec 2008 05:14:17 -0800 (PST) From: Marcin Guzowski mar...@guzowski.info We have developed a distributed system written in Perl that needs to maintain multiple db connections across multiple threads (across multiple processes). Unfortunately, we can't use current DBI 1.x module, because it's not threading-safe. AFAIR DBI 2.0 should fix this problem and could be used in multi-threaded apps, is that true? Have you any idea when DBI 2.0 will be out? I think the plan, to the extent there is a plan, is 'sometime after Perl 6 is available'. It is interesting to speculate 'When will Perl 6 be available'. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Question on Multi-threading and Perl, DBI, DBD::Oracle at StackOverflow.com
I've just given an answer to this question at StackOverflow.com: http://stackoverflow.com/questions/370425/perl-oracle-multithreaded If you disagree with what I said (Tim, or anyone involved with DBD::Oracle), either correct me on SO, or add your own answer, or just let me know and I'll correct it. -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Commiting changes [Was: Re: What is the meaning of the rows value after a select?
On Fri, Dec 5, 2008 at 7:12 AM, Larry W. Virden [EMAIL PROTECTED] wrote:
On Dec 1, 10:54 am, [EMAIL PROTECTED] (Larry W. Virden) wrote:
I inherited some perl code that mostly works, but which I've a couple
questions about what it is doing.
Skipping miscellaneous comments, etc. the code sets some variables
from a file, sets its oracle environment, and then does the following:
$oraProdDBH = DBI-connect(dbi:Oracle:, $user_name, $password)
or die Failed to connect to $DBI:errstr\n;
$oraProdDBH-{RaiseError} = 1;
$oraProdDBH-{AutoCommit} = 0;
Earlier I mentioned the above in the thread about understanding the
rows variable. Today, as I am studying the code, I have a question
about this line about AutoCommit.
If I understand that right, that should mean that an explicit commit
is needed for any action taken by the handle?
Because AutoCommit is set to zero (off), you need to manually commit
transactions.
Later in the code, a SQL DELETE statement is done using that handle,
and, afterwards, all I see is a
$oraProdDBH-disconnect statement.
The situation doesn't come up frequently, so I am just wanting to find
out what DBI is going to do when it does. I checked the logs of the
program and for every delete that the program reports that it
attempted, those records are no longer present in the database. So I
am trying to get a clearer understanding of what is going on in this
case.
DBI disconnects. What the DBMS does depends on the DBMS.
I believe Oracle commits; Informix definitely rolls back incomplete
transactions.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Mailing list
On Sat, Nov 29, 2008 at 3:54 AM, Sureshkumar M (HCL Financial Services) [EMAIL PROTECTED] wrote: Can someone send the maid's for Perl forum where I can clear all my doubts? I would like to discuss lot of doubts and get answer and get quick answers. What do you mean by 'maid'? Subscribe to dbi-users@perl.org if you have questions about Perl and DBI, as I think you must have done to be able to send this request. Then you can send questions for which you've made a reasonable stab at trying to find the answer on your own. Your questions will show that you've done a reasonable amount of work. In case of doubt, see http://www.catb.org/~esr/faqs/smart-questions.html for guidelines on how to ask questions sensibly. You can also search the mail list archives - see the http://dbi.perl.org/web site. I don't know the [EMAIL PROTECTED] mailing list. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: date format search insdie the files
On Sat, Nov 29, 2008 at 3:46 AM, Sureshkumar M (HCL Financial Services) [EMAIL PROTECTED] wrote: Can someone help me on this The script does not contain 'use DBI;' which almost automatically makes it an inappropriate question for the dbi-users@perl.org mailing list. You definitely need to read http://www.catb.org/~esr/faqs/smart-questions.html before posting to dbi-users@perl.org again. You might consider using Date::Manip or the DateTime::* family of modules. There are also a myriad other date and time modules on CPAN ( http://search.cpan.org/). The chances are someone has implemented what you want. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Error in installing perl DBI Module on sun 0s box
On Sat, Nov 15, 2008 at 1:22 AM, Sureshkumar M (HCL Financial Services) [EMAIL PROTECTED] wrote: When I tried to install the Perl DBI module in my machine (sun OS 5.8) I am getting below error messages ,Could you please some one help me on this... C)/home/XYZ/TEST/suresh/modules/DBI/DBI-1.607$ perl Makefile.PL Perl 5.008001 required--this is only version 5.00503, stopped at Makefile.PL line 10. This is your problem. Install your own build of Perl (5.10.0, or 5.8.8 at least) and then add DBI to it. Or, if that is politically impossible, then you'll need to install a down-level version of DBI. But, frankly, you're better off with an up to date version of Perl. Leave /usr/bin/perl for the system -- and install your own working version in a directory ahead of /usr/bin (or /bin) on your PATH. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Problems while installing PERL (DBD::DB2 module)
On Tue, Nov 4, 2008 at 9:34 PM, Vineet Kaimal [EMAIL PROTECTED]wrote: I was trying to install PERL in Linux OS. I was successful in installing the DBI module. Are you sure? But on installing the DBD module, i am facing the following errors There are lots of DBD modules - you are talking about DBD::DB2. Please be precise in your thinking, and in your email subject lines. on the issuance of make command. In file included from DB2.xs:7: DB2.h:18:67: DBIXS.h: No such file or directory This says that the header file installed with DBI wasn't found when you tried to compile DBD::DB2. So, either you installed DBI somewhere off the beaten track and didn't tell DBD::DB2 where it was, or you didn't successfully install DBI (or something went radically wrong, but that's pretty unlikely). I also note that Linux covers a rather wide range of platforms; some more precision in the platform (x86 vs x86_64 vs PPC vs SPARC vs zSeries vs ...) version/distribution would not go amiss. Also, in general, the version of Perl is relevant. This time, the answer does not depend on this information (probably). But get in the habit of identifying what you are using succinctly but accurately. In file included from DB2.h:22, from DB2.xs:7: dbdimp.h:15: error: syntax error before dbih_drc_t dbdimp.h:15: warning: no semicolon at end of struct or union dbdimp.h:18: error: syntax error before '*' token dbdimp.h:18: warning: data definition has no type or storage class dbdimp.h:19: error: syntax error before '}' token dbdimp.h:23: error: syntax error before dbih_dbc_t dbdimp.h:23: warning: no semicolon at end of struct or union dbdimp.h:27: error: syntax error before '}' token dbdimp.h:32: error: syntax error before dbih_stc_t dbdimp.h:32: warning: no semicolon at end of struct or union dbdimp.h:39: error: syntax error before '*' token dbdimp.h:39: warning: data definition has no type or storage class dbdimp.h:55: error: syntax error before '}' token dbdimp.h:60: error: syntax error before imp_sth_t dbdimp.h:60: warning: no semicolon at end of struct or union dbdimp.h:77: error: syntax error before '}' token dbdimp.h:83: error: syntax error before SV These are just some of the errors the errors in DB2.c,DB2.xs and DB2.h files. I have installed the DB2 client in this machine and have run the export DB2_HOME command. Can anyone help me in this? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Problems while installing PERL (DBD::DB2 module)
On Wed, Nov 5, 2008 at 9:58 AM, Vineet Kaimal [EMAIL PROTECTED]wrote: Jonathan , Thanks for your reply Please keep the list in the loop -- you might have gotten the answer by now if you had. We installed DBI-1.607 i ran the following commands perl Makefile.pl make make test make install i think this installs the DBI module It certainly should do. You're going to have to do some tracking down. Is there a DBIXS.h in an appropriate place? Could there be several DBI directory locations under your Perl's library -- and the DBIXS.h file is missing from one? Could the permissions be set wrong? What is the exact location of DBI? What are the command line options when you build the failing code? After this i tried DBD-DB2-1.1 module i ran perl Makefile.pl after this i tried running make for which it gaves the errors Hope this information helps you in providing some tips inorder to provide a solution to help me? Regards, Vineet. On 11/5/08, Jonathan Leffler [EMAIL PROTECTED] wrote: On Tue, Nov 4, 2008 at 9:34 PM, Vineet Kaimal [EMAIL PROTECTED]wrote: I was trying to install PERL in Linux OS. I was successful in installing the DBI module. Are you sure? But on installing the DBD module, i am facing the following errors There are lots of DBD modules - you are talking about DBD::DB2. Please be precise in your thinking, and in your email subject lines. on the issuance of make command. In file included from DB2.xs:7: DB2.h:18:67: DBIXS.h: No such file or directory This says that the header file installed with DBI wasn't found when you tried to compile DBD::DB2. So, either you installed DBI somewhere off the beaten track and didn't tell DBD::DB2 where it was, or you didn't successfully install DBI (or something went radically wrong, but that's pretty unlikely). I also note that Linux covers a rather wide range of platforms; some more precision in the platform (x86 vs x86_64 vs PPC vs SPARC vs zSeries vs ...) version/distribution would not go amiss. Also, in general, the version of Perl is relevant. This time, the answer does not depend on this information (probably). But get in the habit of identifying what you are using succinctly but accurately. In file included from DB2.h:22, from DB2.xs:7: dbdimp.h:15: error: syntax error before dbih_drc_t dbdimp.h:15: warning: no semicolon at end of struct or union dbdimp.h:18: error: syntax error before '*' token dbdimp.h:18: warning: data definition has no type or storage class dbdimp.h:19: error: syntax error before '}' token dbdimp.h:23: error: syntax error before dbih_dbc_t dbdimp.h:23: warning: no semicolon at end of struct or union dbdimp.h:27: error: syntax error before '}' token dbdimp.h:32: error: syntax error before dbih_stc_t dbdimp.h:32: warning: no semicolon at end of struct or union dbdimp.h:39: error: syntax error before '*' token dbdimp.h:39: warning: data definition has no type or storage class dbdimp.h:55: error: syntax error before '}' token dbdimp.h:60: error: syntax error before imp_sth_t dbdimp.h:60: warning: no semicolon at end of struct or union dbdimp.h:77: error: syntax error before '}' token dbdimp.h:83: error: syntax error before SV These are just some of the errors the errors in DB2.c,DB2.xs and DB2.h files. I have installed the DB2 client in this machine and have run the export DB2_HOME command. Can anyone help me in this? -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Issues installing DBD::DB2 v1.1
On Mon, Nov 3, 2008 at 10:20 AM, Vineet Kaimal [EMAIL PROTECTED]wrote: I was trying to install DBD-DB2-1.1 in a 64 bit machine, in the Please include the full module name in the subject line - it makes it easier for others. process i am able to run the perl Makefile.pl command But after this when i try running the make command, i encountered the following error. make[1]: Entering directory `/data01/home/wasuser/perlModules/DBD-DB2-1.1/Constants' make[1]: Leaving directory `/data01/home/wasuser/perlModules/DBD-DB2-1.1/Constants' gcc -c -I/db2home/db2inst1/sqllib/include -I/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI -I/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -m64 -DVERSION=\1.1\ -DXS_VERSION=\1.1\ -fPIC -I/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi/CORE -DDB2_CACHE_FIX DB2.c DB2.xs: In function `XS_DBD__DB2__db_disconnect': DB2.xs:128: error: structure has no member named `_old_cached_kids' DB2.xs:129: error: structure has no member named `_old_cached_kids' DB2.xs:130: error: structure has no member named `_old_cached_kids' DB2.xs: In function `XS_DBD__DB2__db_DESTROY': DB2.xs:192: error: structure has no member named `_old_cached_kids' DB2.xs:193: error: structure has no member named `_old_cached_kids' DB2.xs:194: error: structure has no member named `_old_cached_kids' make: *** [DB2.o] Error 1 Can anyone please help me with this? Which version of DBI do you have installed? I'd lay odds that your DBI is too old. Your Perl isn't exactly in its first flush of youth, either, but is probably what comes with your system - which leads to the next question: Which platform are you running on? (Probably less important this time.) -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Problem with DBI installation on x86_64-linux
On Mon, Nov 3, 2008 at 8:06 AM, Raphael Morlec [EMAIL PROTECTED]wrote: Hello everybody, I'm trying without success to install DBI for nearly two days now. I use a x86_64-linux Mandriva 2007 distribution, with perl 5.8.8 (the shell 'perl -V' output is attached). I tried several ways to install DBI : 1. With the CPAN : I tried 'perl -MCPAN -e shell', then 'install DBI' CPAN gets the DBI module, writes the makefile, then... crashes ! I attached the output of the CPAN on the shell (auto_CPAN_crash.txt). It crashes when gcc compiling is beginning (near line 376), so I guess the problem comes from... gcc compilation. I check the C libraries, and I think I have the right libraries : gcc-4.1.1-3mdk.x86_64 libstdc++5-3.3.6-3mdk.x86_64 libstdc++6-devel-4.1.1-3mdk.x86_64 I'm not sure how you define 'crash', but to me, a 'crash' is different from a compilation failure. The first sign I see of trouble is: gcc -shared -L/usr/local/lib64 DBI.o -o blib/arch/auto/DBI/DBI.so \ \ /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: cannot find -lc collect2: ld returned 1 exit status You probably need to resolve that before going any further. 2. By downloading sources from CPAN : Error is almost the same : I get the DBI-1.607.tar.gz file. ( http://search.cpan.org/CPAN/authors/id/T/TI/TIMB/DBI-1.607.tar.gz ) Then I build the makefile with 'perl Makefile.PL' Then I do 'make'. Then... crash. It seems to crash at the same moment than with CPAN automatic installation (shell output attached = manual_CPAN_crash.txt) Same failure. RPM information deleted DBI::Shell is not DBI. And DBI 1.54 is quite a bit older than the current releases. Thanks for including the information about versions, etc. It helps. I note that Perl was built with a pre-release of the C compiler: Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions', cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='4.1.1 20060724 (prerelease) (4.1.1-3mdk)', gccosandvers='' I doubt that has anything to do with the issue. though. You need to ensure that you can find an appropriate C library. Have you managed to build any other C modules in Perl? Somehow, I doubt it. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Help Installing DBI on Sun solaris
On Wed, Oct 29, 2008 at 6:12 AM, Jason Barna [EMAIL PROTECTED] wrote: the Makefile.PL script seems to run fine (no errors) when I do the make command it errors out [/home/oracle/DBI/DBI-1.607] $ make Skip blib/arch/auto/DBI/Driver_xst.h (unchanged) [...snip...] Skip blib/lib/DBI/ProfileData.pm (unchanged) /usr/local/bin/perl -p -e s/~DRIVER~/Perl/g ./Driver.xst Perl.xsi /usr/local/bin/perl /usr/local/lib/perl5/5.8.8/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.8.8/ExtUtils/typemap -typemap typemap Perl.xs Perl.xsc mv Perl.xsc Perl.c gcc -c-fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\1.607\ -DXS_VERSION=\1.607\ -fPIC -I/usr/local/lib/perl5/5.8.8/sun4-solaris/CORE -W -Wall -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare -Wno-cast-qual -Wmissing-noreturn -Wno-unused-parameter -DDBI_NO_THREADS Perl.c cc1: Invalid option `-Wdeclaration-after-statement' cc1: Invalid option `-Wno-unused-parameter' In file included from /usr/local/lib/perl5/5.8.8/sun4-solaris/CORE/perl.h:3950, from DBIXS.h:19, from Perl.xs:6: /usr/local/lib/perl5/5.8.8/sun4-solaris/CORE/proto.h:31: warning: `warn_unused_result' attribute directive ignored /usr/local/lib/perl5/5.8.8/sun4-solaris/CORE/proto.h:42: warning: `__malloc__' attribute directive ignored [...massive snippage...] Clearly, you are not using GCC, or your GCC is so impossibly ancient that it doesn't understand -Wno-unused-parameter or, perhaps, you got creative and did 'ln -s $(which cc) gcc' or something similar. You cannot build Perl extensions unless you have the same compiler as was used to build Perl. It must, at least, be a version of the same compiler (so, I have Perl built with GCC 3.x, but I can use GCC 4.x to add extensions, etc). -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Install DBD-Informix on 64bit RHEL
On Thu, Oct 9, 2008 at 12:26 AM, Peter J. Holzer [EMAIL PROTECTED] wrote: On 2008-10-09 10:58:01 +1000, Changcheng Zou wrote: I got a 64bit RHEL running 32bit IDS11(we don't have 32bit IDS). The processor is a Xeon 3000, therefore I believe that 32bit software will run. Everything goes fine until we got this DBD-Informix problem. Because the perl is a 64bit version (5.10.0), but the esql is a 32bit. We got error messages as following, You cannot link a 32 bit library to a 64 bit program (or vice versa). You will either have to get the 64bit client libraries of informix (assuming the exist) or compile a 32 bit version of perl. Peter is spot on. And 64-bit CSDK (ESQL/C) should be available. The only thing that concerns me is that the Makefile.PL is supposed to detect a mismatch between 64-bit Perl and 32-bit ESQL/C (or vice versa). Please could you send me (no need to trouble the list) the output of 'perl -V', and also the full output from 'perl Makefile.PL'. With luck, that will allow me to see why you didn't get a sane error message about mixing 32-bit and 64-bit files. *-- lib/DBD/Informix/Defaults.pm written OK esqlinfo.h written OK Testing whether your Informix test environment will work... /usr/bin/ld: skipping incompatible /opt/ids/lib/esql/libifsql.so when searching for -lifsql /usr/bin/ld: skipping incompatible /opt/ids/lib/esql/libifsql.a when searching for -lifsql /usr/bin/ld: cannot find -lifsql * I have no idea what this '-lifsql' is. -lifsql means link with the ifsql library. The linker does find two libraries (/opt/ids/lib/esql/libifsql.so and /opt/ids/lib/esql/libifsql.a) but both are of the wrong type, so it tells you that it cannot use them. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Install DBI on Solaris
On Tue, Sep 23, 2008 at 6:28 AM, [EMAIL PROTECTED] wrote: I'm having an issue installing DBI on Solaris. I've read on many people having this issue and the solutions seem to revolve around installing a new compiler, etc. However, I've already installed other perl modules successfully on this box, so it seems to be related to this module only. Following are the results of the log of my total install and the perl -V. Thanks for any help or clarification that you can provide: The relevant information from the trace you provided (thank you for providing the lot - it does make it easier) is: # make cc -c-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TS_ERRNO -xO3 - xspace -xildoff-DVERSION=\1.607\ -DXS_VERSION=\1.607\ -KPIC - I/usr/perl5/5.8.4/lib/i86pc-solaris-64int/CORE -DDBI_NO_THREADS Perl.c sh: cc: not found *** Error code 1 You don't have the correct C compiler on your PATH (maybe, but not necessarily, /usr/ccs/bin). Add it. Or, if you can't get the Sun compiler, then you will need to rebuild Perl with your compiler of choice. If you've successfully installed other modules, then either those modules were all pure Perl or you had your PATH set differently. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Fwd: Installing DBI using gcc
Caught again by the lack of Reply-To the list. -- Forwarded message -- From: Jonathan Leffler [EMAIL PROTECTED] Date: Tue, Sep 2, 2008 at 11:23 PM Subject: Re: Installing DBI using gcc To: pgodfrin [EMAIL PROTECTED] On Tue, Sep 2, 2008 at 8:55 AM, pgodfrin [EMAIL PROTECTED] wrote: Greetings, I saw a few messages about this, and I thought I should ask the same question. I am installing DBI 1.49, since my system has perl 5.6.1. I do not have a sun compiler available, nor do I have root authority. I have 'installed' gcc, however. Seems to me there should be a way to tell Makefile.PL to generate a makefile with gcc specific flags, but I am having difficulty finding documentation on how to invoke Makefile.PL. There is no easy way to do it. If you must use GCC, build your own Perl (5.10.0, therefore, not the archaic 5.6.1), and run with the latest everything. Is Makefile.PL documented anywhere? Is there a way to make it generate code for gcc? Substantially - no. Next... Tim has documented in the README: It is best to use a Perl that was built on the system you are trying to use and it's also important to use the same compiler that was used to build the Perl you are using. Can someone explain to me why the compiled code for DBI needs to match the compiler that created perl? Clearly I'm missing something... It is bloody hard work to make it work otherwise. You may try - but it will be far quicker to build Perl and use your newly built Perl than to fix the build system so that it uses your compiler when the Perl was not built with it. Tim's advice is sound - I'd estimate 1 hour for rebuilding Perl. I'd estimate 1 week of hair-tearing frustration for trying to hack things so it builds with your compiler. Your second attempt might only be 1 day; after a few times, you'll give up, build your own Perl after all, and then wonder how you ever conceived of doing otherwise. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: How do I reset dataset (statement handle) pointer?
On Mon, Aug 25, 2008 at 6:25 AM, rupert [EMAIL PROTECTED] wrote:
I need to find a function or method that will reset or seek the
dataset handle back to the beginning so I can fetchrow all over again
without doing execute() functions all the time...
[code]
$dbConnection-{FetchHashKeyName} = NAME_lc;
$dataGrid = $dbConnection-prepare(SELECT field, type FROM list);
$dataGrid-execute();
for($i=0; $i3; $i++){
while ($fieldRow = $dataGrid-fetchrow_hashref()) {
print $fieldRow-{'field'};
}
#Nee to seek back to first row in $dataGrid here;
$dataGrid-seekBackToFirstRow(); #I need a function to do it here...
#fails because no such method exists to do above
}
$dataGrid-finish();
[/code]
The options I can think of include:
* Redoing the execute.
* Using fetchall_arrayref() to collect all the data
* Requesting DBI add support for scroll cursors and then using them
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: A Question about DBD-Informix
On Thu, Jul 31, 2008 at 8:16 AM, Curtis Leach [EMAIL PROTECTED] wrote:
I'm running into a problem installing DBD-Informix.
I'm running Perl version 5.8.2 on AIX against Informix 10 with the
current DBI.
Well, given what you say below, I shouldn't carp too much about 5.8.2 being
rather ancient.
The version of the Informix SDK is 2.01, with no option to upgrade since
later releases enforce XA compliance and regrettably a lot of our other
non-perl code isn't XA Compliant and breaks.
CSDK 2.01 -- that would be from 1996 or 1997, I believe.
You have at least one upgrade option - install a modern CSDK (3.00, 3.50)
into a new INFORMIXDIR (separate from where you have CSDK 2.01 installed),
and build DBD::Informix against that new version. You would copy (or,
better, link) the sqlhosts file from the INFORMIXDIR containing the archaic
CSDK to the INFORMIXDIR containing the new code. You might want to futz
INFORMIXDIR when running Perl to point to the new INFORMIXDIR, but it should
mostly work even if you use the old one by accident.
Failing that, disable the testing -- edit Makefile.PL to let CSDK 2.01
through. I've not consciously put anything in that will break - as long as
you get the ESQL/C version number right (9.14).
However, it most certainly won't be supported.
The check is:
elsif ($effvernum = 900 $effvernum 916)
{
# ESQL/C 9.0x and 9.10 or 9.11 were pre-releases of the ESQL/C for
# the Informix Universal Server (IUS) - since renamed several times.
# ESQL/C 9.12 was released as ESQL/C 9.12.
# ESQL/C 9.13 was released in DevSDK 2.00
# ESQL/C 9.14 was released in ClientSDK 2.01
# ESQL/C 9.15 was released in ClientSDK 2.02
# All of these are long obsolete and are no longer supported.
dbd_ix_die nlws(qq%
This version of ESQL/C ($infversion) is obsolete.
Please upgrade to ClientSDK version 2.70 or later.
%);
}
Comment out the dbd_ix_die() call, or replace dbd_ix_die with warn.
You could go back and get a really old DBD::Informix and a matching DBI -- I
wouldn't recommend it, but you could do it.
I also won't guarantee that everything will compile - much less work - but
there's a semi-decent chance. The code does still compile with ESQL/C 5.20
(which is much older than the 9.x versions of ESQL/C, and also older than
the 2.x and 3.x versions of ESQL/C, where 3.50 is the current vesion - don't
ask, because I don't need my blood-pressure to rise again), so the
functionality missing in 9.14 that is present in the latest versions (3.50)
should also be excluded for 9.14.
The Makefile.PL logic says that our SDK is too old.
The Makefile.PL logic is correct - your SDK is too old. I probably declared
CSDK 2.01 obsolete about 5 or 6 years ago.
So is there an earlier release of DBD-Informix out there we could
attempt to use? Or does anyone know how to tweak the current release to
make this work? Or any other suggestions?
We've tried both DBD-Informix-2008.0513 DBD-Informix-2007.0914 without
luck.
If you can't find old versions out on backpan.cpan.org let me know which
version you want to experiment with - and provide me with a convenient way
to get files to you (FTP site, for example).
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Perl+DBI question [C1]
On Mon, Jul 28, 2008 at 8:06 AM, Srinivas KATTI [EMAIL PROTECTED]wrote:
I am working on perl assignment which is first perl code in our
environment, i have come across following problem, pls if you could
provide your expert consultansy it will be great help to me
I am trying to use DBI in my program (simple program), below is the piece
of code
#!/usr/bin/perl -w
#use lib '/tools/dev/perl_modules/DBI/1.48/DBI-1.48';
BEGIN {
push @INC,/tools/dev/perl_modules/DBI/1.48/DBI-1.48;
}
Try /tools/dev/perl_modules -- Perl will add the sub-directories.
See the other directories on @INC for examples.
Or, maybe, you need to add blib to the end of the name you're using.
If you haven't installed DBI yet, do so -- don't try to use it (or build any
DBD modules) until it is installed. Doing that prevents this sort of
headache.
use DBI;
use strict;
my $dbh = DBI-connect( 'dbi:Sybase:SNYCTLDBD01',
'glrecadm',
'glrecadm',
{
RaiseError = 1,
AutoCommit = 0
}
) || die Database connection not made:
$DBI::errstr;
$dbh-disconnect();
when i execute the above program, get the following error
Can't locate loadable object for module DBI 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 .
/tools/dev/perl_modules/DBI/1.48/DBI-1.48) at
/tools/dev/perl_modules/DBI/1.48/DBI-1.48/DBI.pm line 254
BEGIN failed--compilation aborted at
/tools/dev/perl_modules/DBI/1.48/DBI-1.48/DBI.pm line 254.
BEGIN failed--compilation aborted at dbp.pl line 7.
**
when i check the DBI.pm code
[EMAIL PROTECTED]:[/tools/dev/perl_modules/DBI/1.48/DBI-1.48] ls -l
DBI*
-rwxr-xr-x 1 fftstroot 269772 Mar 14 2005 DBI.pm
-rwxr-xr-x 1 fftst307 133636 Jan 20 2005 DBI.xs
-rwxr-xr-x 1 fftst30720392 Dec 14 2004 DBIXS.h
[EMAIL PROTECTED]:[/tools/dev/perl_modules/DBI/1.48/DBI-1.48]
the comments specified in DBI.pm says
# If you get an error here like Can't find loadable object ...
# then you haven't installed the DBI correctly. Read the README
# then install it again.
So is this correct? do i need to install it again Or is it something that
i am missing or not using correctly?
Please do let me know if you need any other info to understand/trouble
shoot my query
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Generic DBI question about backups
On Thu, Jun 19, 2008 at 11:54 AM, Curtis Leach [EMAIL PROTECTED] wrote: My big problem is that the new database hasn't been selected yet the our only Oracle database will be gone by the time one is selected. Which was the reason for the need of a database independent solution. I won't be able to load it back into Oracle again for a 2nd attempt. I would recommend using a consistent text backup format. For example, you might use a delimited format (each field printed as text, separated by a delimiter such as '|', with an escape scheme for handling newlines, pipe symbols and escapes (eg, backslash-backslash for a single backslash; backslash-pipe for a single pipe, backslash-newline for a newline). Or you could go with the CSV format that others have suggested - bearing in mind that CSV is not all that well defined (there are multiple possible variants, and even different MS products handle the odd-ball cases differently). At the same time, dump the schema in text - presumably Oracle has tools to assist in that, but failing that, you can either use the DBI and DBD::Oracle metadata facilities, or learn how to interrogate the Oracle system catalog for the information. With the schema and plain text data files, you can get the data into any other DBMS. Informix provides standard tools DB-Export and DB-Import that use the Informix UNLOAD format (basically, pipe-delimited, backslash-escaped data files) for the data and an SQL file (actually created by the code from another utility, DB-Schema) for the SQL. The output from DB-Export is stylized and comprehensible to DB-Import. With Informix, you can also use the same format for ad hoc unload and load commands too - transferring single tables rather than whole databases. Curtis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2008 1:33 PM To: Curtis Leach Cc: dbi-users@perl.org Subject: Re: Generic DBI question about backups I guess I'd be more concerned initially with ensuring the datatype mappings are identical or in the 'to-be' database, the ingress is valid. Has that been considered yet? On Thu, 19 Jun 2008, Curtis Leach wrote: Does anyone know of a module that would backup an Oracle database in a database independent way? We are decommissioning our only Oracle database we would like to be able to preserve it's contents so that it can be reloaded into another database at a later date. Such as Windows SQL Server or Informix. But all Oracle backup tools use proprietary formats. Curtis -- Louis Gonzales [EMAIL PROTECTED] http://www.linuxlouis.net -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: perl out of memory error
Dear Satish, On Sun, Jun 15, 2008 at 2:53 AM, satish dane [EMAIL PROTECTED] wrote: I am using DBI 1.2 and DBD::oracle 1.58 version and 5.8perl version. the error is coming after some time.that is after exiting from script it is giving the error. an dplease tell about memory leak. Well, your version of DBI is antique - version 1.20 was released in Aug 2001, and 1.29 in Jul 2002. I am not sure that your version of DBD::Oracle is current either. If your version of Perl is 5.8.0, that too is archaic (Jul 2002); if it is 5.8.8, you are OK (Jan 2006), though you should review why 5.10.0 is not an option. Given that you are not using DBD::Informix, I am not able to offer a lot more help. The memory leak test in DBD::Informix::TestHarness could probably be adapted to work with DBD::Oracle - it basically invokes a function and monitors how the Perl process grows, and the content of the function doesn't actually matter, so it could exercise DBD::Oracle as well as DBD::Informix. Be aware that the options to 'ps' work on Solaris and may not work on your platform. Note that you've not mentioned the platform you are running on (operating system, hardware), nor the version of Oracle that you are using -- if you were using DBD::Informix, I would be after you for that information too. When I say which versions of everything, everything most definitely includes the operating system and the DBMS access package (OCI for Oracle; ESQL/C for Informix). It isn't a bad idea to include the C compiler, either. Further discussion of this must be sent to [EMAIL PROTECTED] However, the first instructions given will be 'upgrade to current versions' -- people have very limited interest in debugging ancient versions of the software. On Sun, 15 Jun 2008 Jonathan Leffler wrote : On Sat, Jun 14, 2008 at 3:14 AM, satish dane [EMAIL PROTECTED] wrote: i am trying to run the perl script which searches the data inside DAtabase and use it to run other utility. i am getting an error :Out of Memory I am not able to find the root cause of this error. please try to help me out of this because from last 4 days i am struggling to debug it. Are you using DBI and DBD::Informix? If so, which versions of everything? Does the out of memory error occur immediately, or after some time? Are you using shared memory connections? Can you try with a different connection type (eg olsoctcp or oltlitcp) and see whether that fixes the problem? If so, we can probably diagnose an issue with INFORMIXSHMBASE. Alternatively, there is a mechanism in DBD::Informix::TestHarness for checking whether there's a memory leak in a Perl script -- you could use that to see whether there's a memory leak. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Perl 5.10.0
On Thu, Jun 5, 2008 at 12:54 AM, Scott Ryan [EMAIL PROTECTED] wrote: Hi I am struggling to build the DBD-Oracle module on mandriva 2008.1. It uses perl 5.10.0 and I get the following: [EMAIL PROTECTED] DBD-Oracle-1.21]# make cp Oracle.pm blib/lib/DBD/Oracle.pm cp mkta.pl blib/lib/DBD/mkta.pl cp oraperl.ph blib/lib/oraperl.ph cp dbdimp.h blib/arch/auto/DBD/Oracle/dbdimp.h cp ocitrace.h blib/arch/auto/DBD/Oracle/ocitrace.h cp Oraperl.pm blib/lib/Oraperl.pm cp Oracle.h blib/arch/auto/DBD/Oracle/Oracle.h cp mk.pm blib/arch/auto/DBD/Oracle/mk.pm cp lib/DBD/Oracle/GetInfo.pm blib/lib/DBD/Oracle/GetInfo.pm /usr/bin/perl5.10.0 -p -e s/~DRIVER~/Oracle/g /usr/lib/perl5/vendor_perl/5.10.0/i386-linux-thread-multi/auto/DBI/Driver.xst Oracle.xsi /usr/bin/perl5.10.0 /usr/lib/perl5/5.10.0/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.10.0/ExtUtils/typemap -typemap typemap Oracle.xs Oracle.xsc mv Oracle.xsc Oracle.c make: *** No rule to make target `/usr/lib/perl5/5.10.0/i386-linux-thread-multi/CORE/EXTERN.h', needed by `Oracle.o'. Stop. Any help would be appreciated as google throws up nothing. Assuming that the file doesn't exist - rather than no permissions - then look to see whether there is any other file in the CORE directory. On my Solaris machine, the equivalent file exists. If your CORE directory is non-existent, or mostly empty (should be over 50 files in it), then your best bet is probably build your own Perl. If just the one file is missing, you could try a reinstall. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Error Installing DBI on Solaris
On Fri, May 30, 2008 at 3:40 AM, Himanshu Kumar [EMAIL PROTECTED] wrote: I got a problem when trying to install DBI-1.48 module on a solaris 9 box. The error is: [EMAIL PROTECTED] # make /bin/sh -c true cc -c -D_REENTRANT -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O-DVERSION=\1.48\ -DXS_VERSION=\1.48\ -KPIC -I/opt/InfoVista/ivperl/lib/5.6.1/sun4-solaris-thread-multi/CORE Perl.c sh: cc: not found *** Error code 1 make: Fatal error: Command failed for target `Perl.o' I do have gcc package installed on the system. ?? Anyone having an idea ? Many thanks in advance To build extensions for Perl, you need the same (or equivalent) C compiler as the one used to build Perl. You don't have the Sun C compiler on the machine. You have two options: 1. Rebuild Perl (5.8.8 or 5.10.0) with GCC 2. Obtain the Sun C compiler. Anything else is fraught with issues. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: install_driver(Oracle) failed: wrong ELF class: DynaLoader.pm
On Wed, May 28, 2008 at 11:47 PM, Christian Merz [EMAIL PROTECTED] wrote: i set the environment in my skript, the libs are installed correctly - or the script won't run interactively. I'm not the Oracle expert - treat what I say with a pinch of salt. I do use Solaris 10 quite a lot, though - it's my main development platform. LD_LIBRARY_PATH must be set before ld.so.1 runs (because ld.so.1 reads the env var just once and ignores any subsequent changes to it), and ld.so.1 runs before Perl gets going. So, if your Perl script sets LD_LIBRARY_PATH, it is too late to influence ld.so.1 (and dlopen() etc). I've proved that the hard way - with SUID programs and dlopen() function calls in the mix too. Try modifying your cron job so that it runs a shell script which sets at least LD_LIBRARY_PATH before invoking perl at all (use exec perl ...). I suspect it will work better then. If that isn't feasible (for some brain-dead administrative nightmare of a reason), then try having the Perl code set LD_LIBRARY_PATH and then re-exec itself. I've seen that work too. Weird stuff. The hard part is making sure that the re-exec happens just once! On the other hand, this may still be off-target. But 'stuff works at command line and not when run by cron or web server' almost always ends up as 'the problem is environment'. so, there is a problem with the environment but i cannot see it. is there something important besides @INC and %ENV? i already tried both versions of LD_LIBRARY_PATH /oracle/product/10.2.0/lib:/oracle/product/10.2.0/lib32 /oracle/product/10.2.0/lib32:/oracle/product/10.2.0/lib (as Alexander Alekseev [EMAIL PROTECTED] suggested) here are full outputs of my %ENV. -- 1. interactively - runs ok CLASSPATH - :/oracle/product/10.2.0/classes/oracle:/oracle/product/10.2.0/jlib:/oracle/product/10.2.0/lib EDITOR - vi HOME - /export/home/oracle LD_LIBRARY_PATH - /oracle/product/10.2.0/lib32:/oracle/product/10.2.0/lib LOGNAME - oracle MAIL - /usr/mail/oracle MANPATH - /usr/share/man:/opt/nsr/man NLS_LANG - AMERICAN_AMERICA.WE8DEC OLDPWD - /export/home/oracle ORACLE_BASE - /oracle ORACLE_HOME - /oracle/product/10.2.0 ORACLE_PATH - /oracle/product/10.2.0/bin ORACLE_SID - ora19 ORA_NLS10 - /oracle/product/10.2.0/nls/data PATH - /oracle/product/10.2.0/bin:/usr/ccs/bin:/usr/bin:/bin PS1 - db03:oracle:[$ORACLE_SID]$PWD PWD - /oracle/dba/backup/ora19 SHELL - /bin/ksh SHLVL - 1 SSH_CLIENT - 10.1.3.132 55755 22 SSH_CONNECTION - 10.1.3.132 55755 194.246.199.137 22 SSH_TTY - /dev/pts/2 TERM - xterm TNS_ADMIN - /oracle/product/10.2.0/network/admin TZ - MET USER - oracle _ - ./DbOnline.pl -- 2. as cron job - with 'wrong ELF error' CLASSPATH - /oracle/product/10.2.0/classes/oracle:/oracle/product/10.2.0/jlib:/oracle/product/10.2.0/lib:/oracle/product/10.2.0/classes/oracle:/oracle/product/10.2.0/jlib:/oracle/product/10.2.0/lib HOME - /export/home/oracle LD_LIBRARY_PATH - /oracle/product/10.2.0/lib32:/oracle/product/10.2.0/lib LOGNAME - oracle NLS_LANG - AMERICAN_AMERICA.WE8DEC ORACLE_HOME - /oracle/product/10.2.0 ORACLE_SID - ora19 ORA_NLS10 - /oracle/product/10.2.0/nls/data PATH - /oracle/product/10.2.0/bin:/usr/ccs/bin:/usr/bin:/bin SHELL - /usr/bin/sh TZ - MET -- install_driver(Oracle) failed: Can't load '/usr/perl5/site_perl/5.8.4/sun4-solaris-64int/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: perl: fatal: /oracle/product/10.2.0/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64 at /usr/perl5/5.8.4/lib/sun4-solaris-64int/DynaLoader.pm line 230. at (eval 7) line 3 Compilation failed in require at (eval 7) line 3. Perhaps a required shared library or dll isn't installed where expected at /oracle/dba/backup/ora19/DbOnline.pl line 514 Jonathan Leffler wrote: On Wed, May 28, 2008 at 8:30 AM, Christian Merz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: i wrote a skript which works fine for several Oracle Versions on several platforms (linux, solarias 8/9). if i run that script ineractively on solaris 10 it also works fine. if i run it as a cron job i get: cron does not set the environment, so you must do so for it. install_driver(Oracle) failed: Can't load '/usr/perl5/site_perl/5.8.4/sun4-solaris-64int/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: perl: fatal: /oracle/product/10.2.0/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64 at /usr/perl5/5.8.4/lib/sun4-solaris-64int/DynaLoader.pm line 230. at (eval 8) line 3 Compilation failed in require at (eval 8) line 3. Perhaps a required shared library or dll isn't installed where expected 32-bit Client library - 64-bit Perl - won't work. Install 32-bit Perl or 64-bit client libraries. Or just set the environment. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org Blessed are we who can laugh at ourselves
Re: Can't locate DBI.pm
On Wed, May 28, 2008 at 8:37 AM, Singaravelan S (HCL Financial Services) [EMAIL PROTECTED] wrote: DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. Well, this is no help in the description. The error implied by the subject line means you have not installed DBI - or have not installed it where you can pick it up at runtime. Since you've given no other information, you can't get any more help. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: install_driver(Oracle) failed: wrong ELF class: DynaLoader.pm
On Wed, May 28, 2008 at 8:30 AM, Christian Merz [EMAIL PROTECTED] wrote: i wrote a skript which works fine for several Oracle Versions on several platforms (linux, solarias 8/9). if i run that script ineractively on solaris 10 it also works fine. if i run it as a cron job i get: cron does not set the environment, so you must do so for it. install_driver(Oracle) failed: Can't load '/usr/perl5/site_perl/5.8.4/sun4-solaris-64int/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1: perl: fatal: /oracle/product/10.2.0/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64 at /usr/perl5/5.8.4/lib/sun4-solaris-64int/DynaLoader.pm line 230. at (eval 8) line 3 Compilation failed in require at (eval 8) line 3. Perhaps a required shared library or dll isn't installed where expected 32-bit Client library - 64-bit Perl - won't work. Install 32-bit Perl or 64-bit client libraries. Or just set the environment. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Perl in oracle 10.2.0.3 on 64 BIT OS
On Mon, May 19, 2008 at 11:49 AM, Shanmugam, Dhandapani [EMAIL PROTECTED] wrote: Does PERL support 64-bit operating systems? Yes. Kindly help me on how should perl work on Oracle 64-bit Solaris Operating system . Am getting the below error [bash]perl create_ddl.pl Can't locate DBI.pm in @INC So, you haven't installed DBI yet. You will have to do that before you can use it. For example, you must have DBI installed before installing DBD::Oracle. Given that the install is currently using Perl 5.8.3, you should build your own Perl, either 5.8.8 or 5.10.0, and then install it in a location of your own choosing (rather than messing with the system version) and then get on with installing DBI and its pre-requisites and then install DBD::Oracle. I can't answer for whether DBD::Oracle supports 64-bit systems, but it would be astonishing (to me) if it did not do so. Do not follow-up to me - use the list. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: dbquery.cgi: couldn't connect to database: (UNKNOWN OCI STATUS 1804) OCIInitialize
On Mon, May 19, 2008 at 7:16 AM, Jesse Hess [EMAIL PROTECTED] wrote: I am connecting from one server to another server with an ORACLE database. I have already checked the tnsnames and listener.ora files on the connecting box (ORACLE) and they are posted further down in the thread. I have searched for quite some time but haven't found anything helpful yet. I am getting the following error: In general, when something works from the command line and not from a web server, the problem is environment. 99+% of the time (I'm tempted to say 99.9+%) dbquery.cgi: couldn't connect to database: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and NLS settings etc. at ./dbquery.cgi line 19. And that message seems to be saying the same. Remember, web servers, where you run .cgi files, sanitize the environment thoroughly before running anything else. Look up PassEnv and SetEnv directives (and mod_env). Responses to the list - not to me. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - 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 2008.0513 (2008-05-13) released
IBM Informix Database Driver for Perl DBI Version 2008.0513 (2008-05-13)
has been uploaded to CPAN.
IBM Informix Database Driver for Perl (also known as DBD::Informix) is
the driver code that enables Perl 5.6.1 or later to access Informix
databases via the DBI module (but if you are not already using Perl
5.10.0 - or any later version - you should be planning to upgrade). You
will need the code for DBI version 1.38 or later as well (v1.604 - 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 :PRODVER::
* Fix $sth-{TYPE}: return 9 (SQL_DATE) not -1 (SQL_LVARCHAR), fixing an
11-year old bug.
* Add support for BIGINT in ESQL/C 3.50, including $h-{ix_bigserial}.
* CPAN Testers reporting issues because Makefile.PL not exiting
successfully when pre-requisites not met.
* ESQL/C 3.50 (for IDS 11.50) typedefs ifx_loc_t - update dumpesql.h to
cope (Joe R Plugge [EMAIL PROTECTED]).
* ESQL/C test fails during configuration when $Config{ccflags} has
leading spaces. Records show this problem also affected Dr Guenther
Seifert [EMAIL PROTECTED] in June 2007. Apologies
for not getting it fixed sooner.
Release 2008.0229:
* RT#32975: Add $h-{ix_serial} and $h-{ix_serial8}.
Release 2007.0914
* RT#29364: Fix problem identifying ESQL/C libraries.
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.
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 2008.2 2008/05/13 03:03:31 jleffler Exp $
smime.p7s
Description: S/MIME Cryptographic Signature
Re: How to Retrieve Table Name from Statement Handle
On Wed, May 7, 2008 at 10:51 AM, Lamb Joseph [EMAIL PROTECTED] wrote:
I am creating a simple tool that will query one table and retrieve the
data. Then this tool will turn the data into insert statements.
I was wondering if there was a way to retrieve the table name from the
statement handle?
Similar to print SQL statement contains $sth-{NUM_OF_FIELDS} columns\n;
but like this
print SQL statement table name is $sth-{TABLENAME} \n;
Over and above Alexander's cogent (but gentle - the SQL could have been a
lot more complex than that) rebuttal, there's another question for you:
How did you decide which table to build the 'SELECT * FROM $table' query
from?
Can't you keep tabs on the table name from that?
(Succinctly - no, you can't tell the table name from the statement handle
because, in general, there isn't a single table name to report.)
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Fw: How to Retrieve Table Name from Statement Handle
On Wed, May 7, 2008 at 12:37 PM, Lamb Joseph [EMAIL PROTECTED] wrote:
To answer you question, for an Oracle environment I would like
$sth-{TABLENAME} to contain a list.
my $tablename = $sth-{TABLENAME} -[0] = First table
$tablename $sth-{TABLENAME} -[1] = Second table
The $tablename value will be schema.tablename format.
For example:
schema.narf
schema.zord
So, what do you expect from a more complex statement, such as one which
includes multiply nested sub-queries in the FROM clause, with renaming
operations?
SELECT * FROM table1, (SELECT * FROM (SELECT * FROM ...) AS renaming) AS
renaming2 OUTER JOIN (...) ...
And who do you expect to do the parsing of your SQL? On average, the DBD
driver shouldn't have to, and the average database server won't tell you,
so... Also, don't forget that any of the names could be a reference to an
arbitrarily complex view -- what should be returned then?
I'm sorry, but I don't think you are going to get the information, unless
some DB server is willing to give that information to the driver.
I've seen your response to my other post:
I will have to break apart the SQL statement with a regex and store it
that way.
Question: how do you know that it is query using a single table - as your
original question posited?
I won't lambast this any further. Suffice to say, what you are asking for
is incredibly non-trivial in the general case, and the general case has to
work as well as the trivial.
- Forwarded Message
From: Alexander Foken [EMAIL PROTECTED]
To: Lamb Joseph [EMAIL PROTECTED]
Cc: dbi-users@perl.org
Sent: Wednesday, May 7, 2008 11:18:53 AM
Subject: Re: How to Retrieve Table Name from Statement Handle
Hmmm, and what do you think $sth-{TABLENAME} should contain after
executing the following SQL?
SELECT t1.foo,t2.bar FROM narf t1, zord t2 WHERE t1.ikes=t2.blurb
Alexander
On 07.05.2008 19:51, Lamb Joseph wrote:
I am creating a simple tool that will query one table and retrieve the
data. Then this tool will turn the data into insert statements.
I was wondering if there was a way to retrieve the table name from the
statement handle?
Similar to print SQL statement contains $sth-{NUM_OF_FIELDS}
columns\n;
but like this
print SQL statement table name is $sth-{TABLENAME} \n;
Joseph Lamb
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--
Alexander Foken
mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: DB2.xs error
On Thu, Apr 10, 2008 at 5:01 AM, Hildo Biersma [EMAIL PROTECTED] wrote: Simon Cheng wrote: I'm trying to install DBD::DB2 1.0 onto AIX 5.3. perl makefile.pl runs ok but when I run make, I get this error DB2.xs, line 115.9: 1506-025 (S) Operand must be a modifiable lvalue. DB2.xs, line 175.13: 1506-025 (S) Operand must be a modifiable lvalue. make: 1254-004 The error code from the last command is 1. Any suggestions? Please contact the group that supports DBD::DB2 - the mail address is [EMAIL PROTECTED], the same company and country that you are in :-) Over and above what Hildo says, you should at the minimum identify whether you are modifying the system's install of Perl (generally a bad idea) or whether you are using your own version. You should also give at the least the version of Perl you are using and probably the full 'perl -V' output. You should also identify which version of the C compiler you are using, and which version of the DB2 CLI you are using. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Problem posting replies
On Tue, Apr 8, 2008 at 10:46 AM, pgodfrin [EMAIL PROTECTED] wrote: Any reason I can't post a reply to posts? Probably because when you hit reply (instead of reply-all) it goes to just the poster and not everyone else. It catches me out periodically. There was a separate response of yours that did get through. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Blank inserted with varchar copy using prepare
On Fri, Apr 4, 2008 at 12:03 PM, Rutherdale, Will [EMAIL PROTECTED] wrote: I confirmed the problem occurs on another machine I was wondering about. I tried installing the latest DBI and DBD::Informix. DBI was okay, but DBD::Informix started out giving me the following warnings on 'perl Makefile.PL': Using INFORMIX-ESQL Version 9.21.UC1 from /usr/informix Please upgrade to a more recent version of ClientSDK. DBD::Informix will probably work, but that is not guaranteed. Note that bug RT#13708 (IBM CQ bug idsdb00139040) may affect you. In particular, if test t/t931varchar.t detects problems, consider an upgrade to CSDK 3.00 or later - it seems to be fixed there. ESQL/C 9.21 was released as part of CSDK 2.30 in May 1999. I suppose it is sad to make software retire before its tenth birthday, but in this case, it is somewhat past time. That sounds like it could be related to my problem. Do you think I could report to management where I work that this known bug might be causing the problem, and that CSDK 3.00 is recommended? That problem - RT#13708 - is to do with LVARCHAR and not VARCHAR. Well, I tried to install CSDK 2.30 on my Solaris 10 machine. The install worked; the software didn't. The network connections wouldn't work (that appears to be a generic problem for my machine - on later testing; probably needs a reboot), but the stream connections did. The compilation of DBD::Informix 2008.0229 went fine, but the test failed horribly because it couldn't find a symbol ifx_var_freevar(). Dropping back to DBD::Informix 2003.04, the compilation worked and tests ran mostly OK (IUS tests were dubious, but VARCHAR isn't an IUS feature). Using the previously generated test script, I got erroneous output from the VARCHAR data. So, the problem could be in CSDK 2.30 or in DBD::Informix 2003.04. Checking with a more recent CSDK (3.00.UC2), it appears that DBD::Informix 2003.04 was not handling VARCHAR properly; it introduces the blanks. So, between that version and 2008.0229, I fixed the problem, somehow. Looking at the ChangeLog, I find: 2005-07-28: Logged bug B173776 against ESQL/C - SQL DESCRIPTORS mishandle zero-length non-null VARCHAR values. This prevents a solution to a problem report from Vàclav Ovsík [EMAIL PROTECTED]. This would probably be the issue - you'd need a version of DBD::Informix later than 2005.02 and a version of CSDK released after that. The relevant database reports that the bug was fixed in CSDK 2.90.xC4 - so you need a version of CSDK at least that recent. I also happened to fail in 'make test' on DBD::Informix, but I'll have to get back to you later on that. If the trouble is 'ifx_var_freevar()', then that is a (now) known and 'will not be fixed' problem. CSDK 2.30 (ESQL/C 9.21) is officially unsupported by DBD::Informix. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Fwd: Blank inserted with varchar copy using prepare
Bother.
-- Forwarded message --
From: Jonathan Leffler [EMAIL PROTECTED]
Date: Thu, Apr 3, 2008 at 5:49 PM
Subject: Re: Blank inserted with varchar copy using prepare
To: Rutherdale, Will [EMAIL PROTECTED]
On Thu, Apr 3, 2008 at 3:34 PM, Rutherdale, Will [EMAIL PROTECTED]
wrote:
I am using Perl 5.8.8 on SunOS pnc 5.8 with Informix (Server Version
9.30) and DBI 1.51 and DBD::Informix 2005.2.
I try to copy a list of tables using DBI. I have found that a certain
column declared as varchar(64) is copied incorrectly when it contains an
empty string. The value in the target location is a string containing
one space instead of being empty.
Here is a code fragment copied from the actual script:
foreach my $tb ( @$table_list )
{
my ( $sel ) = $from_dbh-prepare( SELECT * FROM $tb );
$sel-execute();
my ( $cols, $val_str ) = ( $sel-{NUM_OF_FIELDS}, () );
$val_str = ( . (?, x ($cols-1)) . ?) if ( $cols0 );
my ( $ins ) = $to_dbh-prepare( INSERT INTO $tb VALUES . $val_str
);
my ( $fetch_tuple_sub ) = sub { $sel-fetchrow_arrayref };
my @tuple_status;
my ( $rc ) = $ins-execute_for_fetch( $fetch_tuple_sub,
[EMAIL PROTECTED] );
my ( @errors ) = grep { ref $_ } @tuple_status;
$sel-finish();
$ins-finish();
}
Is this a known bug? Is there a way I can get this code to faithfully
reproduce the data including blank strings of type varchar(64)?
Perl 5.10.0 on Solaris 10, DBI 1.604, DBD::Informix 2008.0229, ESQL/C
3.00.UC2.
#!/bin/perl -w
use strict;
use DBD::Informix::TestHarness;
my($dbh) = connect_to_test_database({RaiseError = 1});
my($tbl1) = dbd_ix_something_1;
my($tbl2) = dbd_ix_something_2;
$dbh-do(create {temp} table $tbl1 ( col VARCHAR(64) NOT NULL));
$dbh-do(create {temp} table $tbl2 ( col VARCHAR(64) NOT NULL));
$dbh-do(INSERT INTO $tbl1 VALUES('a')); # Non-blank VARCHAR
$dbh-do(INSERT INTO $tbl1 VALUES(' ')); # Single-blank VARCHAR
$dbh-do(INSERT INTO $tbl1 VALUES(''));# Empty (non-null) VARCHAR
my($from_dbh) = $dbh;
my($to_dbh) = $dbh;
my($table_list) = [ $tbl1 ];
foreach my $tb ( @$table_list )
{
my ( $sel ) = $from_dbh-prepare( SELECT * FROM $tb );
$sel-execute();
my ( $cols, $val_str ) = ( $sel-{NUM_OF_FIELDS}, () );
$val_str = ( . (?, x ($cols-1)) . ?) if ( $cols0 );
my ($new) = $tb;
$new =~ s/1/2/;
my ( $ins ) = $to_dbh-prepare( INSERT INTO $new VALUES . $val_str);
my ( $fetch_tuple_sub ) = sub { $sel-fetchrow_arrayref };
my @tuple_status;
my ( $rc ) = $ins-execute_for_fetch( $fetch_tuple_sub,
[EMAIL PROTECTED] );
my ( @errors ) = grep { ref $_ } @tuple_status;
$sel-finish();
$ins-finish();
}
Runs OK - first time.
Black JL: perl will.sciatl.pl
# DBI-connect('dbi:Informix:stores', '', '');
# Connect Attribute: RaiseError = 1
# Connect Attribute: ChopBlanks = 1
Black JL: sqlcmd -d stores -F unload -e 'select * from dbd_ix_something_1'
a|
|
\ |
Black JL: sqlcmd -d stores -F unload -e 'select * from dbd_ix_something_2'
a|
|
\ |
Black JL:
Basically, this code is copying the single blank and the empty but non-null
string accurately.
So, in the absence of a reproduction with DBD::Informix 2008.0229, I'm going
to claim no longer a problem. There have been issues in the handling of
VARCHAR, both in ESQL/C and in DBD::Informix on occasion, but not
self-evidently on this occasion.
I assume there's a reason why you can't do:
INSERT INTO dbase2:tablename SELECT * FROM dbase1:tablename;
Probably related to error -999 (not implemented yet).
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0229 - 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 - v2008.0229 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: error during DBD::Oracle installation (was: error during DBI installation)
Looks like time to get the development stuff you need installed. The log file says: Reading /export/home/oracle/product/9Iclient/precomp/lib/env_precomp.mk Attempting to discover Oracle OCI build rules gcc -c -I. -I/export/home/oracle/product/9Iclient/precomp/public -I/export/home/oracle/product/9Iclient/rdbms/public -I/export/home/oracle/product/9Iclient/rdbms/demo -I/export/home/oracle/product/9Iclient/plsql/public -I/export/home/oracle/product/9Iclient/network/public -I/export/home/oracle/product/9Iclient/rdbms/demo -I/export/home/oracle/product/9Iclient/rdbms/demo -I/opt/ActivePerl-5.8/lib/site_perl/5.8.7/sun4-solaris-thread-multi/auto/DBI/ -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DUSE_SITECUSTOMIZE -DNO_HASH_SEED -DBUILT_BY_ACTIVESTATE -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O-DVERSION=\1.16\ -DXS_VERSION=\1.16\ -fPIC -I/opt/ActivePerl-5.8/lib/5.8.7/sun4-solaris-thread-multi/CORE -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\9.2.0.1\ DBD_ORA_OBJ.c by executing: [make -f /export/home/oracle/product/9Iclient/precomp/demo/proc/demo_proc.mk build ECHODO=echo ECHO=echo GENCLNTSH='echo genclntsh' CC=true OPTIMIZE= CCFLAGS= EXE=DBD_ORA_EXE OBJS=DBD_ORA_OBJ.o] Oracle oci build command: [true -o DBD_ORA_EXE DBD_ORA_OBJ.o -L/export/home/oracle/product/9Iclient/lib/ -lclntsh `cat /export/home/oracle/product/9Iclient/lib/ldflags` `cat /export/home/oracle/product/9Iclient/lib/sysliblist` -R/export/home/oracle/product/9Iclient/lib -laio -lposix4 -lm -lthread] Found header files in rdbms/demo. * I can't find the header files I need in your Oracle installation. You probably need to install some more Oracle components. I'll keep going, but the compile will probably fail. See README.clients for more information. * It also says: *** If you have problems... read all the log printed above, and the README and README.help files. (Of course, you have read README by now anyway, haven't you?) So, which part of that is too hard to understand? You're running on ancient Solaris (2.6 - not supported), and you have a fairly old version of Oracle client -- did you check whether it is supported. And DBD does not mean DBD::Oracle - there are lots of DBD::DBMS drivers. On Wed, Apr 2, 2008 at 1:08 PM, Sasidharan, Radhakrishnan [EMAIL PROTECTED] wrote: We are trying to run the DBD installation on a unix server. We are able to do the Makefile.PL but it failed on the subsequent make. Attached is the output of the two commands. Kindly help us to resolve this issue. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6
On Fri, Mar 21, 2008 at 6:41 AM, Vachon, Frederick P (Fred) A5IT [EMAIL PROTECTED] wrote: Sorry but the information I gave about the make test problem was incorrect. The symbol that it is looking for is nanosleep not nanod. I can't find nanod on my system at all - or in the source for Time::HiRes. That's odd. Not surprising that it failed to find nanod - but odd that it thought it should. So I'm still trying to find a way to fix this and get Perl installed. ld.so.1: perl: fatal: relocation error: file ../lib/auto/Time/HiRes/HiRes.so: symbol nanosleep: referenced symbol not found Ah - nanosleep is definitely around normally - in either or both of libposix4.so or librt.so. I've not checked for other places, but the hints file in ext/Time/HiRes/hints/solaris_2.sh clearly identifies these libraries and 'nm -g /usr/lib/librt.so /usr/lib/libposix4.so | grep nanosleep | grep -v UNDEF' shows them present. If you've got neither of those libaries on the machine, get them installed. You could try rebuilding Time::HiRes manually in the source tree (the code is in ext/Time/HiRes under the perl-5.8.8 directory). The tricky bit is getting your new Perl to do it. This seemed to work for me y'day: ../../../perl -I../../../lib Makefile.PL Killed -Original Message- *From:* Jonathan Leffler [mailto:[EMAIL PROTECTED] *Sent:* Thursday, March 20, 2008 9:54 PM *To:* Vachon, Frederick P (Fred) A5IT *Cc:* DBI Users Mailing List *Subject:* Re: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6 Here's another 'perl -V' - 5.8.8 on Solaris 10 with GCC 3.4.6 - justifying my other email saying that an update to GCC was not crucial. Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.10, archname=sun4-solaris-64 uname='sunos black 5.10 generic_120011-14 sun4u sparc sunw,ultra-4 solaris ' config_args='' 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=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='/usr/gcc/v3.4.6/bin/gcc -m64 -mcpu=v9', ccflags ='-fno-strict-aliasing -pipe -Wdeclaration-a fter-statement -mcpu=v9 -m64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV -DPERL_USE_SAFE_PUTENV', optimize='-O', cppflags='-fno-strict-aliasing -pipe -Wdeclaration-after-statement' ccversion='', gccversion='3.4.6', gccosandvers='solaris2.10' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='/usr/gcc/v3.4.6/bin/gcc -m64 -mcpu=v9', ldflags =' -m64 ' libpth=/usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/usr/lib/sparcv9/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 -m64' Characteristics of this binary (from libperl): Compile-time options: PERL_MALLOC_WRAP PERL_USE_SAFE_PUTENV USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO Built under solaris Compiled at Mar 20 2008 11:38:45 @INC: lib /usr/perl/v5.8.8-gcc-3.4.6/lib/5.8.8/sun4-solaris-64 /usr/perl/v5.8.8-gcc-3.4.6/lib/5.8.8 /usr/perl/v5.8.8-gcc-3.4.6/lib/site_perl/5.8.8/sun4-solaris-64 /usr/perl/v5.8.8-gcc-3.4.6/lib/site_perl/5.8.8 /usr/perl/v5.8.8-gcc-3.4.6/lib/site_perl . On Thu, Mar 20, 2008 at 12:31 PM, Vachon, Frederick P (Fred) A5IT [EMAIL PROTECTED] wrote: Thank you very much for your help! Having the output from a successful build I was able to see what was wrong or missing in my config.sh file. I needed to include the sparcv9 64 bit directories - mainly /usr/lib/sparcv9 and /usr/ccs/lib/sparcv9 to config.sh. The defaults from Configure don't work. I always do a manual configure - though I usually spend a lot of time just accepting the defaults. Tip: if you plan to have Perl installed in /usr/perl/v5.x.y, create both /usr/perl/v5.x.y and /usr/perl/v5.x.y/bin -- it saves having Perl ask you are you sure questions. The Perl configured above failed 4 tests, all related to NDBM. That doesn't surprise me or worry me. I was able to get through the make but ran into a problem with make test that I'm trying to figure out. Thanks again. ext/Time
Re: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6
On Fri, Mar 21, 2008 at 10:21 AM, Vachon, Frederick P (Fred) A5IT [EMAIL PROTECTED] wrote: Thanks for getting back. I'm kinda new at this. I found that I needed to add the rt library to libs variable -lrt. So I did that and rebuild. So I'm almost there. I get 2 errors on the make test. Do you need to have 100% on make test to install? Some notes say (probably harmless) ? If the stuff you need is working, I'd probably go with the install despite the failures. However, if something subsequently goes wrong - especially with something like getppid() - then you need to remember that there were some test failures. For my build, there were 4 failures related to NDBM. I'm not worried because I don't normally use that. Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/ExtUtils/t/Embed.t 9 9 100.00% 1-9 op/getppid.t 3 1 33.33% 3 79 tests and 198 subtests skipped. Failed 2/988 test scripts, 99.80% okay. 10/116518 subtests failed, 99.99%okay. --- HERE IS MORE DETAIL ./perl op/getppid.t 1..3 ok 1 # ppid1=19577 ok 2 # ppid2=20926, ppid1!=ppid2 not ok 3 # ppid2=1 -- ./perl -I../lib ../lib/ExtUtils/t/Embed.t 1..9 Note (probably harmless): No library found for -lsocket Note (probably harmless): No library found for -lnsl Note (probably harmless): No library found for -ldl Note (probably harmless): No library found for -lm Note (probably harmless): No library found for -lc Note (probably harmless): No library found for -lrt # gcc -m64 -o embed_test -I.. -mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/in Undefined first referenced symbol in file cos ../libperl.a(pp.o) exp ../libperl.a(pp.o) log ../libperl.a(pp.o) pow ../libperl.a(pp.o) sin ../libperl.a(pp.o) ceil ../libperl.a(pp.o) fmod ../libperl.a(pp.o) sqrt ../libperl.a(pp.o) atan2 ../libperl.a(pp.o) floor ../libperl.a(pp.o) ld: fatal: Symbol referencing errors. No output written to embed_test collect2: ld returned 1 exit status not ok 1 # embed_test = ./embed_test not ok 9 # system returned -1 [...megasnip...] -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Fwd: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6
Darn the mailing list! -- Forwarded message -- From: Jonathan Leffler [EMAIL PROTECTED] Date: Thu, Mar 20, 2008 at 10:20 AM Subject: Re: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6 To: Vachon, Frederick P (Fred) A5IT [EMAIL PROTECTED] On Thu, Mar 20, 2008 at 10:03 AM, Fred Vachon, Frederick P (Fred) A5IT [EMAIL PROTECTED] wrote: I'm new to this list. I looked over the various Perl mailing lists and decided on this one although my problem isn't directly related to DBI. But the reason I'm trying to compile Perl from source as 64 bit is to use the DBI module and DBD:Oracle (and if I ever can get Perl to Build I'll probably need help with the DBI!). I am trying to build a 64 bit Perl from source on my home directory (as non root) on Solaris 10. I downloaded the most current stable version of Perl 5.8.8 from CPAN. I'm using the Solaris gcc compiler in /usr/local/bin/gcc which is version 3.4.6. I get through the Configure step OK but fail when trying to run make. The tail of the output is listed below. I have searched the internet for others with this problem but have not been able to find a solution. I have read the README file for Solaris, the INSTALL notes and have looked through the hints script. I am not a sysadmin so my options are limited - I cannot install a different gcc compiler or make any changes to the system directories. My objective is to have my own version of Perl so I can add the DBI and DBD::ORACLE modules. I am running Configure this way. I am taking all the defaults except I remove directory /usr/lib as mentioned in the Solaris README notes. sh ./Configure -Dprefix=/home/fred/perl_5.8.8 -Dcc=gcc -Duse64bitall -Aldflags=-mcpu=v9 -m64 -Alddlflags=-mcpu=v9 -m64 -G This is my LD_LIBRARY_PATH and PATH LD_LIBRARY_PATH /usr/local/lib:/usr/ccs/lib:/usr/sfw/lib:/usr/dt/lib:/usr/openwin/lib:/u sr/share/lib:$ORACLE_HOME/lib32 PATH /bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/ccs/bin:/usr/sfw/bin:/usr/op enwin/bin:/etc:$ORACLE_HOME/bin:/usr/ucb This is the error from make: CCCMD = gcc -DPERL_CORE -c -mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/ll gcc -m64 -mcpu=v9 -m64 -L/usr/local/lib -o miniperl \ miniperlmain.o opmini.o libperl.a Undefined first referenced symbol in file cos libperl.a(pp.o) exp libperl.a(pp.o) log libperl.a(pp.o) pow libperl.a(pp.o) sin libperl.a(pp.o) ceil libperl.a(pp.o) fmod libperl.a(pp.o) sqrt libperl.a(pp.o) atan2 libperl.a(pp.o) floor libperl.a(pp.o) ld: fatal: Symbol referencing errors. No output written to miniperl collect2: ld returned 1 exit status make: *** [miniperl] Error 1 Those are maths library functions - the link line needs to include -lm. I'm not clear why it doesn't - I never had this problem on my Solaris boxes. You might need to replace /usr/lib with /usr/lib/sparcv9. Here's the 'perl -V' output from a successful 64-bit Perl (with threading and multiplicity) built on Solaris 8 with GCC 4.0.2 back in 2006: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris-thread-multi-64 uname='sunos anubis 5.8 generic_117350-16 sun4u sparc sunw,ultra-5_10 solaris ' config_args='-Duse64bitall -Duseithreads -Dusethreads -Dusemultiplicity -Dcc=gcc -m64' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc -m64', ccflags ='-D_REENTRANT -mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -pipe -Wd eclaration-after-statement -I/usr/gnu64/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-D_REENTRANT -mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -pipe -Wdeclaration-afte r-statement -I/usr/gnu64/include' ccversion='', gccversion='4.0.2', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc -m64', ldflags ='-m64 -L/usr/lib/sparcv9 -L/usr/gnu64/lib -L/usr/ccs/lib/sparcv9 ' libpth=/usr/lib/sparcv9 /usr/gnu64/lib /usr/ccs/lib/sparcv9 libs=-lsocket -lnsl -lgdbm -ldb -ldl -lm -lpthread -lc perllibs=-lsocket -lnsl -ldl -lm -lpthread -lc libc=/usr/lib/sparcv9/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 -m64 -L/usr/lib/sparcv9 -L/usr/gnu64/lib -L/usr/ccs/lib/sparc v9' Characteristics of this binary
Re: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6
On Thu, Mar 20, 2008 at 10:39 AM, Richard T Malafa [EMAIL PROTECTED] wrote: Upgrade your gcc and get the sun code generator if you want it from SUN... It's version 4.2.0 read the url. http://www.sun.com/download/products.xml?id=43fb4c75 Check out the cool tools also on that page.. It's not necessary - GCC 3.4.6 is fine. I've just rebuilt Perl 5.8.8 with GCC 3.4.6 in 64-bit mode. It was more exasperating than I expected because some monkey added a hint in hints/solaris_2.sh to use getconf to add arguments to the linker - search for an if statement that contains: ccflags=$ccflags -Wa,`getconf XBS5_LP64_OFF64_CFLAGS 2/dev/null` Eliminate it - it comments that it isn't sure it is necessary, and it is actually counter productive. I also got 7 (count them!) copies of -DPERL_USE_SAFE_PUTENV because a config.over got extended each time I ran the configure. Grump! -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
Re: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6
List/Util MIME/Base64 NDBM_File ODBM_File Opcode POSIX PerlIO/encoding PerlIO/scalar PerlIO/via SDBM_File Socket Storable Sys/Hostname Sys/Syslog Time/HiRes Unicode/Normalize XS/APItest XS/Typemap attrs re threads threads/shared Errno gmtime_r_proto=0 i_systime=define i_systimek= i_systimes=define i_time= i_utime=define known_extensions=B ByteLoader Cwd DB_File Data/Dumper Devel/DProf Devel/PPPort Devel/Peek Digest/MD5 Encode Fcntl File/Glob Filter/Util/Call GDBM_File I18N/Langinfo IO IPC/SysV List/Util MIME/Base64 NDBM_File ODBM_File Opcode POSIX PerlIO/encoding PerlIO/scalar PerlIO/via SDBM_File Socket Storable Sys/Hostname Sys/Syslog Thread Time/HiRes Unicode/Normalize XS/APItest XS/Typemap attrs re threads threads/shared localtime_r_proto=0 timeincl=/usr/include/sys/time.h timetype=time_t Black JL: If you get anything significantly different, it might be informative and relevant. OTOH, it may not help in the slightest. -Original Message- From: Jonathan Leffler [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 1:21 PM To: DBI Users Mailing List Subject: Fwd: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6 Darn the mailing list! -- Forwarded message -- From: Jonathan Leffler [EMAIL PROTECTED] Date: Thu, Mar 20, 2008 at 10:20 AM Subject: Re: Make problem Building 64 bit Perl 5.8.8 from source on Solaris 10 with gcc 3.4.6 To: Vachon, Frederick P (Fred) A5IT [EMAIL PROTECTED] On Thu, Mar 20, 2008 at 10:03 AM, Fred Vachon, Frederick P (Fred) A5IT [EMAIL PROTECTED] wrote: I'm new to this list. I looked over the various Perl mailing lists and decided on this one although my problem isn't directly related to DBI. But the reason I'm trying to compile Perl from source as 64 bit is to use the DBI module and DBD:Oracle (and if I ever can get Perl to Build I'll probably need help with the DBI!). I am trying to build a 64 bit Perl from source on my home directory (as non root) on Solaris 10. I downloaded the most current stable version of Perl 5.8.8 from CPAN. I'm using the Solaris gcc compiler in /usr/local/bin/gcc which is version 3.4.6. I get through the Configure step OK but fail when trying to run make. The tail of the output is listed below. I have searched the internet for others with this problem but have not been able to find a solution. I have read the README file for Solaris, the INSTALL notes and have looked through the hints script. I am not a sysadmin so my options are limited - I cannot install a different gcc compiler or make any changes to the system directories. My objective is to have my own version of Perl so I can add the DBI and DBD::ORACLE modules. I am running Configure this way. I am taking all the defaults except I remove directory /usr/lib as mentioned in the Solaris README notes. sh ./Configure -Dprefix=/home/fred/perl_5.8.8 -Dcc=gcc -Duse64bitall -Aldflags=-mcpu=v9 -m64 -Alddlflags=-mcpu=v9 -m64 -G This is my LD_LIBRARY_PATH and PATH LD_LIBRARY_PATH /usr/local/lib:/usr/ccs/lib:/usr/sfw/lib:/usr/dt/lib:/usr/openwin/lib:/u sr/share/lib:$ORACLE_HOME/lib32 PATH /bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/ccs/bin:/usr/sfw/bin:/usr/op enwin/bin:/etc:$ORACLE_HOME/bin:/usr/ucb This is the error from make: CCCMD = gcc -DPERL_CORE -c -mcpu=v9 -m64 -Wa,-xarch=v9 -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/ll gcc -m64 -mcpu=v9 -m64 -L/usr/local/lib -o miniperl \ miniperlmain.o opmini.o libperl.a Undefined first referenced symbol in file cos libperl.a(pp.o) exp libperl.a(pp.o) log libperl.a(pp.o) pow libperl.a(pp.o) sin libperl.a(pp.o) ceil libperl.a(pp.o) fmod libperl.a(pp.o) sqrt libperl.a(pp.o) atan2 libperl.a(pp.o) floor libperl.a(pp.o) ld: fatal: Symbol referencing errors. No output written to miniperl collect2: ld returned 1 exit status make: *** [miniperl] Error 1 Those are maths library functions - the link line needs to include -lm. I'm not clear why it doesn't - I never had this problem on my Solaris boxes. You might need to replace /usr/lib with /usr/lib/sparcv9. Here's the 'perl -V' output from a successful 64-bit Perl (with threading and multiplicity) built on Solaris 8 with GCC 4.0.2 back in 2006: Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=solaris, osvers=2.8, archname=sun4-solaris-thread-multi-64 uname='sunos anubis 5.8 generic_117350-16 sun4u sparc sunw,ultra-5_10 solaris ' config_args='-Duse64bitall -Duseithreads -Dusethreads -Dusemultiplicity -Dcc=gcc -m64' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc -m64
Re: Inserting LOB into DB2 in pieces
On Thu, Mar 6, 2008 at 8:25 PM, Bong Tumanut [EMAIL PROTECTED] wrote:
I'm writing an Apache::ASP program to upload a file and store it in a LOB
column in DB2. Is there a way to store the uploaded file in pieces, i.e.
while(read($filehandle, $data, 1024))
{
# data from the uploaded file read into $data
# load all $data into a LOB column
};
I know the uploaded file can be stored in a file and then the file, in
turn, is bound to a LOB column. But this is extra processing.
I also know that I can store the whole file in a variable but that could
take up a lot of memory.
[EMAIL PROTECTED]
Round trips to the database are expensive too. I'd go with store the whole
LOB in a file and then bind that to the LOB - it will be be less stress on
the system overall, I think. It depends slightly on the size of the files
on average, but if you're going to do more than two round trips in fragments
(more than 2 KB files/LOBs), then you should think again.
Also, your comments imply the data is already in an uploaded file - so
aren't you making busy work for yourself?
And, I strongly suspect this would apply to any DBMS where the client is in
a separate process from the DBMS.
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
Re: Google SoC: Summer of DBI - project manager, ideas, and mentors wanted
On Mon, Mar 3, 2008 at 3:18 AM, Tim Bunce [EMAIL PROTECTED] wrote: On Sat, Mar 01, 2008 at 06:15:40PM -0800, Eric Wilhelm wrote: Hi Tim, I'm not on the DBI mailing list, but it seems like DBI should have a primary presence under the TPF Summer of Code umbrella. If the DBI community hasn't already made arrangements for applying as its own entity, please forward this along. Is anybody interested in mentoring students who want to submit DBI-related/using proposals for Google's Summer of Code? I'm trying to get together a proposal for The Perl Foundation this year, but if google is going to let us in this year, we need to redeem ourselves by gathering a sizable number of willing mentors and project ideas before the 8th. I would also like two volunteers to manage the DBI neck of the woods. That is, you will herd the cats and I will herd you ;-) If you're interested in managing, please join me in #soc on irc.perl.org or e-mail me directly. (This assumes that we have sufficient number of willing mentors in the DBI department to warrant management.) Potential mentors, please add yourselves and your project ideas here: http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_mentors http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_projects If you hate wikis as much as I do, please visit this handy form and I will batch the wiki edits on your behalf. http://scratchcomputing.com/loveperlhatewiki.html I've added myself as a mentor and I'm sending this to the dbi-users and dbi-announce lists. I've also added a description of a DBI project I'd really like someone to pick up and run with: http://www.perlfoundation.org/perl5/index.cgi?gsoc2008_projects#dbi One more site, one more password to remember. Oh well... I've added myself as a possible mentor, and listed DBI as the area of interest. Admittedly, my interest is as much in ensuring that the tests can run with DBD::Informix as anything else - there are enough idiosyncracies to keep students happy for a long time. So, I'm willing to assist in the mentoring, but would hope/expect to have at least one other major DBMS driver writer on the team to ensure that things stay balanced. I need my head seeing to. I must remember that word, what is it now? ... Oh, yes; I remember. No. Another time, perhaps. :) -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2008.0229 - 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 2008.0229 (2008-02-29) released
[I couldn't resist the chance to release on Leap Day - it only happens once
every 4 years, after all :-) ]
IBM Informix Database Driver for Perl DBI Version 2008.0229 (2008-02-29) has
been uploaded to CPAN.
IBM Informix Database Driver for Perl (also known as DBD::Informix) is
the driver code that enables Perl 5.6.1 or later to access Informix
databases via the DBI module (but if you are not already using Perl
5.10.0 - or any later version - you should be planning to upgrade). You
will need the code for DBI version 1.38 or later as well (v1.602 - 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 2008.0229:
* RT#32975: Add $h-{ix_serial} and $h-{ix_serial8}.
Release 2007.0914
* RT#29364: Fix problem identifying ESQL/C libraries.
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.
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 2008.1 2008/02/29 22:25:54 jleffler Exp $
Public Timestamp Numbers (http://publictimestamp.org/)
PTS#642305 DBD-Informix-2008.0229.tgz
PTS#642309 DBD-Informix-2008.0229-MSD.tgz
PTS#642310 DBD-Informix-2008.0229-Master.tgz
PTS#642311 DBD-Informix-2008.0229.sum
PTS#642312 DBD-Informix-2008.0229.tar.gz
PTS#642313 DBD-Informix-2008.0229.rel
SHA-256 hashes and file sizes:
SHA-256 37ed57b075f566f4fecf69d90d329113318e4ace9265d20322eddd2e9e6fa74b
817736 DBD-Informix-2008.0229-MSD.tgz
SHA-256 555bd793a0a52f746a838390908a6d1359315c46dcd7172251ec9af07f831ae5
927390 DBD-Informix-2008.0229-Master.tgz
SHA-256
016ab02d7a98b71327a29dd9dd80620077a4531c397ee3e6815ee46e4aa1280f 107
DBD-Informix-2008.0229.sum
SHA-256 f852d306b1693aea81027a74cc264e68b0709d748171f706c4bcfcb790980d3f
310320 DBD-Informix-2008.0229.tar.gz
SHA-256 864e71c40b44de2d336953132691875bf693379403dc0f218a8c5d35a4e8b877
309695 DBD-Informix-2008.0229.tgz
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
