Re: ORA-1008 on Oracle 10g (update)
Hello! it seems there is a common interest for a solution for this case. We solved this problem changing the Oracle parameter 'CURSOR_SHARING' from value 'force' to 'exact'. This fixes a known bug (or feature) introduced in Oracle 10. After changing this parameter DBI works like with Oracle 9 before. Hope this helps you to solve *your* problem. Update: This is bug #5863277 which has been fixed in in a small standalone patch. This patch is included in the 10.2.0.4 patchset. (Thanks to Nelson Calero for this information.) Best Regards, Olaf Ohlenmacher -- Olaf Ohlenmacher [EMAIL PROTECTED] MaXpert AG, Berner Straße 119, 60437 Frankfurt am Main Tel: +49 69 50065 269 Fax: +49 69 50065 515 Mobil: +49 172 6648 604 Von: [EMAIL PROTECTED] Gesendet: Donnerstag, 14. Februar 2008 17:47 An: dbi-users@perl.org Betreff: ORA-1008 on Oracle 10g Hello! i am writing a script querying a Oracle database with prepared statements. The database owner has upgradeed the database from version 9.2 to version 10g. Since this upgrade the scripts croaks() with DBD::Oracle::st execute failed: ORA-01008: not all variables bound (DBD ERROR: OCIStmtExecute) [for Statement SELECT * FROM BB_TO_SYS_MESSAGE WHERE STATUS= 'new' AND BACKBONE_TICKET_ID = ? AND TIMESTAMP = ? with ParamValues: :p1='Ticket-SC-GER-20080214153230054', :p2='2008-02-14 15:39:38'] at D:/Programme/backbone-devel/Programme/DBhandling.pm line 459 There are only two parameters :p1 and :p2 with both have valid values. Have you any suggestion why this statement failed on Oracle 10g? Do you know about any problems with the module version i am using (see below)? Using this version... ActiveState perl 5.8.8 DBI 1.601 DBD-Oracle 1.17 All from ActiveState Package Repository. Best Regards, Olaf Ohlenmacher -- Olaf Ohlenmacher [EMAIL PROTECTED] MaXpert AG, Berner Straße 119, 60437 Frankfurt am Main Tel: +49 69 50065-265 Mobil: +49 172 6648 604
Urgent help required : Issue with DBD:Oracle 1.20 installation
Hi all I am trying to install DBD-Oracle-1.20 downloaded from CPAN. I am getting the following errors. Request you to help asap [EMAIL PROTECTED] # perl Makefile.PL Using DBI 1.601 (for perl 5.008007 on sun4-solaris) installed in /opt/soe/local/perl-5.8.7/lib/site_perl/5.8.7/sun4-solaris/auto/DBI/ Configuring DBD::Oracle for perl 5.008007 on solaris (sun4-solaris) Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in /u02/app/dvoa061a/oracle/8.0.6 DEFINE _SQLPLUS_RELEASE = 80006 (CHAR) Oracle version 8.0.6.0 (8.0) Found /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo/demo_rdbms.mk Found /u02/app/dvoa061a/oracle/8.0.6/precomp/demo/proc/demo_proc.mk Using /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo/demo_rdbms.mk Your LD_LIBRARY_PATH env var is set to '/usr/openwin/lib:/u02/app/dvoa061a/oracle/8.0.6/lib' Reading /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo/demo_rdbms.mk Reading /u02/app/dvoa061a/oracle/8.0.6/rdbms/lib/env_rdbms.mk Attempting to discover Oracle OCI build rules gcc -c -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/demo -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/demo -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/public -I/u02/app/dvoa061a/oracle/8.0.6/plsql/public -I/u02/app/dvoa061a/oracle/8.0.6/network/public -I/opt/soe/local/perl-5.8.7 /lib/site_perl/5.8.7/sun4-solaris/auto/DBI -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\1.20\ -DXS_VERSION=\1.20\ -fPIC -I/opt/soe/local/perl-5.8.7/lib/5.8.7/sun4-solaris/CORE -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\8.0.6.0\ -DUSE_ORA_OCI_STMNT_FETCH DBD_ORA_OBJ.c by executing: [make -f /u02/app/dvoa061a/oracle/8.0.6 /rdbms/demo/demo_rdbms.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 -L/u02/app/dvoa061a/oracle/8.0.6/lib/ -L/u02/app/dvoa061a/oracle/8.0.6/rdbms/lib -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh /u02/app/dvoa061a/oracle/8.0.6/lib/nautab.o /u02/app/dvoa061a/oracle/8.0.6/lib/naeet.o /u02/app/dvoa061a/oracle/8.0.6 /lib/naect.o /u02/app/dvoa061a/oracle/8.0.6/lib/naedhs.o -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lmm -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lepc -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lclient -lvsn -lcommon -lgeneric -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnsl -lsocket -lgen -ldl -lc -laio -lm -lthread] Found header files in /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo. Checking for functioning wait.ph System: perl5.008007 sunos zlggs002 5.8 generic_108528-07 sun4u sparc sunw,ultra-250 Compiler: gcc -O -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Linker: /usr/ccs/bin/ld Sysliblist: -lnsl -lsocket -lgen -ldl Oracle makefiles would have used these definitions but we override them: CC: cc CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(QACCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -xO2 $(CDEBUG) -Xa $(PROFILE) -xstrconst -xF $(XS) -mr -xarch=v8 -xcache=16/32/1:1024/64/1 -xchip=ultra -D_REENTRANT -K PIC $(QACCFLAGS) -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/demo -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/public -I/u02/app/dvoa061a/oracle/8.0.6/plsql/public -I/u02/app/dvoa061a/oracle/8.0.6/network/public -DSLMXMX_ENABLE -DSLTS_ENABLE $(LPFLAGS) $(USRFLAGS)] LDFLAGS: -L$(LIBHOME) -L$(ORACLE_HOME)/rdbms/lib [-L$(LIBHOME) -L/u02/app/dvoa061a/oracle/8.0.6/rdbms/lib] Linking with OTHERLDFLAGS = -L/u02/app/dvoa061a/oracle/8.0.6/lib/ -L/u02/app/dvoa061a/oracle/8.0.6/rdbms/lib -lclntsh /u02/app/dvoa061a/oracle/8.0.6/lib/nautab.o /u02/app/dvoa061a/oracle/8.0.6 /lib/naeet.o /u02/app/dvoa061a/oracle/8.0.6/lib/naect.o /u02/app/dvoa061a/oracle/8.0.6/lib/naedhs.o -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lmm -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lepc -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lclient -lvsn -lcommon -lgeneric -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnsl -lsocket -lgen -ldl -lc -laio -lm -lthread [from 'build' rule] WARNING: If you have problems you may need to rebuild perl with threading enabled. LD_RUN_PATH=/u02/app/dvoa061a/oracle/8.0.6 /lib:/u02/app/dvoa061a/oracle/8.0.6/rdbms/lib Using DBD::Oracle 1.20. Using DBD::Oracle 1.20. Using DBI 1.601 (for perl 5.008007 on sun4-solaris) installed in /opt/soe/local/perl-5.8.7/lib/site_perl/5.8.7/sun4-solaris/auto/DBI/ Writing Makefile for DBD::Oracle *** If you have problems... read all the log printed above, and the README and README.help.txt files. (Of course, you have read README by now anyway, haven't you?) [EMAIL PROTECTED] # make
Re: Urgent help required : Issue with DBD:Oracle 1.20 installation
Well you oracle clients it ancient for one this (8.0.6.0 ) and unfortunately installing DBD::Oracle on a sun box has always been problematic. the dbdimp.c:2997: error: `OCI_BATCH_ERRORS' undeclared (first use in this error basically tells me that you are missing this constant in the 'oci.h' of the client you are attempting to use. If this is the case you will have to use an older version of DBD::ORACLE (1.17) if you want to keep this client. I doesn't matter really as with this client you cannot use any of the functionality of the later versions. So if you must use the old oracle client use an older DBD::Oracle. You can also compile you DBD:Oracle against the Oracle instant client and it will work as well cheers John Scoles Divyansh Nasa wrote: Hi all I am trying to install DBD-Oracle-1.20 downloaded from CPAN. I am getting the following errors. Request you to help asap [EMAIL PROTECTED] # perl Makefile.PL Using DBI 1.601 (for perl 5.008007 on sun4-solaris) installed in /opt/soe/local/perl-5.8.7/lib/site_perl/5.8.7/sun4-solaris/auto/DBI/ Configuring DBD::Oracle for perl 5.008007 on solaris (sun4-solaris) Remember to actually *READ* the README file! Especially if you have any problems. Using Oracle in /u02/app/dvoa061a/oracle/8.0.6 DEFINE _SQLPLUS_RELEASE = 80006 (CHAR) Oracle version 8.0.6.0 (8.0) Found /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo/demo_rdbms.mk Found /u02/app/dvoa061a/oracle/8.0.6/precomp/demo/proc/demo_proc.mk Using /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo/demo_rdbms.mk Your LD_LIBRARY_PATH env var is set to '/usr/openwin/lib:/u02/app/dvoa061a/oracle/8.0.6/lib' Reading /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo/demo_rdbms.mk Reading /u02/app/dvoa061a/oracle/8.0.6/rdbms/lib/env_rdbms.mk Attempting to discover Oracle OCI build rules gcc -c -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/demo -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/demo -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/public -I/u02/app/dvoa061a/oracle/8.0.6/plsql/public -I/u02/app/dvoa061a/oracle/8.0.6/network/public -I/opt/soe/local/perl-5.8.7 /lib/site_perl/5.8.7/sun4-solaris/auto/DBI -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -DVERSION=\1.20\ -DXS_VERSION=\1.20\ -fPIC -I/opt/soe/local/perl-5.8.7/lib/5.8.7/sun4-solaris/CORE -Wall -Wno-comment -DUTF8_SUPPORT -DORA_OCI_VERSION=\8.0.6.0\ -DUSE_ORA_OCI_STMNT_FETCH DBD_ORA_OBJ.c by executing: [make -f /u02/app/dvoa061a/oracle/8.0.6 /rdbms/demo/demo_rdbms.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 -L/u02/app/dvoa061a/oracle/8.0.6/lib/ -L/u02/app/dvoa061a/oracle/8.0.6/rdbms/lib -o DBD_ORA_EXE DBD_ORA_OBJ.o -lclntsh /u02/app/dvoa061a/oracle/8.0.6/lib/nautab.o /u02/app/dvoa061a/oracle/8.0.6/lib/naeet.o /u02/app/dvoa061a/oracle/8.0.6 /lib/naect.o /u02/app/dvoa061a/oracle/8.0.6/lib/naedhs.o -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lmm -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lepc -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lclient -lvsn -lcommon -lgeneric -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnsl -lsocket -lgen -ldl -lc -laio -lm -lthread] Found header files in /u02/app/dvoa061a/oracle/8.0.6/rdbms/demo. Checking for functioning wait.ph System: perl5.008007 sunos zlggs002 5.8 generic_108528-07 sun4u sparc sunw,ultra-250 Compiler: gcc -O -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Linker: /usr/ccs/bin/ld Sysliblist: -lnsl -lsocket -lgen -ldl Oracle makefiles would have used these definitions but we override them: CC: cc CFLAGS: $(GFLAG) $(OPTIMIZE) $(CDEBUG) $(CCFLAGS) $(QACCFLAGS) $(PFLAGS)\ $(SHARED_CFLAG) $(USRFLAGS) [$(GFLAG) -xO2 $(CDEBUG) -Xa $(PROFILE) -xstrconst -xF $(XS) -mr -xarch=v8 -xcache=16/32/1:1024/64/1 -xchip=ultra -D_REENTRANT -K PIC $(QACCFLAGS) -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/demo -I/u02/app/dvoa061a/oracle/8.0.6/rdbms/public -I/u02/app/dvoa061a/oracle/8.0.6/plsql/public -I/u02/app/dvoa061a/oracle/8.0.6/network/public -DSLMXMX_ENABLE -DSLTS_ENABLE $(LPFLAGS) $(USRFLAGS)] LDFLAGS: -L$(LIBHOME) -L$(ORACLE_HOME)/rdbms/lib [-L$(LIBHOME) -L/u02/app/dvoa061a/oracle/8.0.6/rdbms/lib] Linking with OTHERLDFLAGS = -L/u02/app/dvoa061a/oracle/8.0.6/lib/ -L/u02/app/dvoa061a/oracle/8.0.6/rdbms/lib -lclntsh /u02/app/dvoa061a/oracle/8.0.6/lib/nautab.o /u02/app/dvoa061a/oracle/8.0.6 /lib/naeet.o /u02/app/dvoa061a/oracle/8.0.6/lib/naect.o /u02/app/dvoa061a/oracle/8.0.6/lib/naedhs.o -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lmm -lnlsrtl3 -lcore4 -lnlsrtl3 -lcore4 -lnlsrtl3 -lnetv2 -lnttcp -lnetwork -lncr -lnetv2 -lnttcp -lnetwork -lclient -lvsn -lcommon -lgeneric -lepc -lnlsrtl3
RE: Blank inserted with varchar copy using prepare
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. 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? I also happened to fail in 'make test' on DBD::Informix, but I'll have to get back to you later on that. -Will - - - - - Appended by Scientific Atlanta, a Cisco company - - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
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.
RE: Blank inserted with varchar copy using prepare
Thank you very much Jonathan for that tremendous amount of help. I'll have to digest what you've said, but it sounds like I need a newer DBD::Informix and possibly a newer CSDK. I got the same failure on my system with the missing ifx_var_freevar during the 'make test'. From what you said, I would need to install a new DBD::Informix (newer than 2005.02, probably 2008.0229), and CSDK at least 2.90.xC4. That is, I would need these fixes in order to solve the table copying the way I showed you using the prepare and execute loop. However I might be able to find a better way to copy the tables that curcumvents this problem. On the other hand, the bug would still be there and could affect other operations that read those varchar columns. -Will -Original Message- From: Jonathan Leffler [mailto:[EMAIL PROTECTED] Sent: Friday 04 April 2008 16:01 To: Rutherdale, Will Cc: DBI Users Mailing List Subject: 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. - - - - - Appended by Scientific Atlanta, a Cisco company - - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any
