Antwort: compilation requirements for DBD-DB2
Edward Peschko An: [EMAIL PROTECTED] [EMAIL PROTECTED]Kopie: [EMAIL PROTECTED] Thema: compilation requirements for DBD-DB2 12.10.2004 21:27 hey all, I'm missing a piece, I guess, in the install of DB2.. I have the libraries, etc. installed in /opt/IBM/db2/V8.1. I'm getting: Constants.xs:16:20: sqlcli.h: No such file or directory Constants.xs:18:21: sqlcli1.h: No such file or directory Constants.xs:19:20: sqlext.h: No such file or directory so... what do I need to download and from where? Thanks, Ed Hey Ed, the sql*.h you mention belong to the db2-Client-Software! You should find them in your sqllib\include directory! There are different editions ( runtime-,administration- and developer-Client) of the db2-client-software! If you have a DB2-Client installed and don't find them, you will need to install the Developer-Client, which I have. I think they are only in the dev-Client, but am not sure! If you find find them, they may not be in your include-path! best regards Manfred
Re: alternative to DBD::Oracle that does not use OCI?
You could install DBD::Oracle DBI on the server which has the Oracle install and use DBD::Proxy to connect. Or look into using DBD::JDBC. On Tue, 2004-10-12 at 16:36, Joseph Bruni wrote: Hello all, Although DBI is great, is there some other sort of DBD module that can connect to an Oracle database without needing to install Oracle's pile of steaming code? I'd like something considerably lighter weight than the 250MB client. Surely there must be some sort of reverse-engineered Oracle client? Thanks Joe
Re: I'll be giving my Advanced DBI tutorial at MySQL ComCon Europe
Hello Tim, I have registered for the workshop. I have missed the early bird discount :-( It's only 5 kilometers away from my home. So if you need some local support, feel free to mail me. Wednesday, September 8, 2004, 1:06:06 PM, you wrote: TB The oddly named MySQL ComCon Europe conference will take place TB in Frankfurt in November: http://mysqlcomconeurope.com/ TB I'll be presenting my Advanced DBI tutorial on the pre-conference TB workshop day. I think it's the first time I've presented it in Europe. TB I hope to see some of you there. cu Wielandmailto:[EMAIL PROTECTED]
Re: compilation requirements for DBD-DB2
On October 12, 2004 1:27 pm, Edward Peschko wrote: hey all, I'm missing a piece, I guess, in the install of DB2.. I have the libraries, etc. installed in /opt/IBM/db2/V8.1. Did you install the application development tools with DB2? If you have the Application Development Client installed, you have it. Or, if you have any licensed product, you could install it (it's optional). If you have the Runtime Client or the Administration Client products, you will need to get the Application Development Client off the IBM website and install it to get the headers and libraries required for compiling C programs. I'm getting: Constants.xs:16:20: sqlcli.h: No such file or directory Constants.xs:18:21: sqlcli1.h: No such file or directory Constants.xs:19:20: sqlext.h: No such file or directory so... what do I need to download and from where?
Re: alternative to DBD::Oracle that does not use OCI?
DBD::Proxy is brilliant! This also solves some security concerns as well as having to install Oracle binaries for various operating systems. Thanks for the tip! On Oct 13, 2004, at 6:45 AM, Scott T. Hildreth wrote: You could install DBD::Oracle DBI on the server which has the Oracle install and use DBD::Proxy to connect. Or look into using DBD::JDBC. On Tue, 2004-10-12 at 16:36, Joseph Bruni wrote: Hello all, Although DBI is great, is there some other sort of DBD module that can connect to an Oracle database without needing to install Oracle's pile of steaming code? I'd like something considerably lighter weight than the 250MB client. Surely there must be some sort of reverse-engineered Oracle client? Thanks Joe smime.p7s Description: S/MIME cryptographic signature
Programming the Perl DBI
Hello, I'm looking at the Perl DBI O'Reilly book, but it has a publish date of 2000. How much has DBI changed since then? Is the book still a good reference or has it become outdated? Joe smime.p7s Description: S/MIME cryptographic signature
DBI version for Perl 5.005_03
DBI-1.45 requires Perl 5.006, I am running 5.005.03, which DBI version should I use? I am getting below error when I do $)- perl Makefile.PL Perl 5.006 required--this is only version 5.00503, stopped at Makefile.PL line 10. BEGIN failed--compilation aborted at Makefile.PL line 12. Regards, Mano
Re: I'll be giving my Advanced DBI tutorial at MySQL ComCon Europe
On Wed, Oct 13, 2004 at 04:51:50PM +0200, Wieland Pusch wrote: Hello Tim, I have registered for the workshop. I have missed the early bird discount :-( It's only 5 kilometers away from my home. So if you need some local support, feel free to mail me. Thanks Wieland. Tim. Wednesday, September 8, 2004, 1:06:06 PM, you wrote: TB The oddly named MySQL ComCon Europe conference will take place TB in Frankfurt in November: http://mysqlcomconeurope.com/ TB I'll be presenting my Advanced DBI tutorial on the pre-conference TB workshop day. I think it's the first time I've presented it in Europe. TB I hope to see some of you there. cu Wielandmailto:[EMAIL PROTECTED]
Re: Programming the Perl DBI
On Wed, Oct 13, 2004 at 01:58:53PM -0700, Joseph Bruni wrote: Hello, I'm looking at the Perl DBI O'Reilly book, but it has a publish date of 2000. How much has DBI changed since then? | this much | or, for a list of changes since DBI 1.14, this much: http://search.cpan.org/~timb/DBI/Changes Is the book still a good reference or has it become outdated? Both. It's a good (enough) reference for what it covers, but what it covers grows more limited relative to the (slowly) advancing DBI. A second edition is in the works but the works seem to be less than productive at the moment and relatively little is actually done. So don't go holding your breath... Tim.
Re: Fwd: DBD::Informix A configuration failure
Dear Marco, Thanks for the extra information - I wish I could make head or tail of the problem(s). On Tue, 12 Oct 2004 11:52:12 +0200, Marco Avvisano [EMAIL PROTECTED] wrote: Dear Jonathan, i'm sorry i haven't see your answer, so i try to send again my help-mail. I use perl 5.8.0 from my redhat distribution. These are the outputs from my tests how you suggest to me. Thanks a lot for your help. perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.21-14.elsmp, archname=i386-linux-thread-multi uname='linux twe' config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostnam e=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallp refix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsitepre fix= /usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithr eads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_sh adow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -U vers iononly -Dpager=/usr/bin/less -isr' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef' useithreads=define usemultiplicity= useperlio= d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=un uselongdouble= usemymalloc=, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGI NG -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFF SET_ BITS=64 -I/usr/include/gdbm', optimize='', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-st rict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-37)', gccosand vers='' gccversion='3.2.3 200305' intsize=o, longsize=s, ptrsize=l, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long' k', ivsize=4' ivtype='long' known_extensi, nvtype='double', nvsize=, Off_t='', lseeksize=8 alignbytes=4, prototype=define Here we have 'prototype=define', yet when we come to test it in the DBD::Informix build, we are getting 'undef'. That is very odd. Very odd indeed. Are you sure we aren't accidentally using two different versions of Perl? It's still pretty unlikely that the C compiler for any Linux-based Perl does not have prototypes. That test has, I think, outlived its usefulness. Linker and Libraries: ld='gcc' l', ldflags ='' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs= libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libper gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi /CORE' cccdlflags='-fPIC' ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s Unicode/Normalize XS/A' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: MAINT18379 Built under linux Compiled at Jun 28 2004 14:32:58 @INC: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 ## my log # Configuring IBM Informix Database Driver for Perl Version 2003.04 (2003-03-05) (aka DBD::Informix) You are using DBI version 1.45 and Perl version 5.008 Remember to actually read the README file! Perl: perl5.008 i386-linux-thread-multi dl_dlopen.xs System: linux tweet Compiler: gcc -O2 -g -pi -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -f no-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_B ITS=64 -I/usr/include/gdbm Using IBM Informix CSDK Version 2.81, IBM Informix-ESQL Version 9.53.UC2X5 from /opt/informix Beware: DBD::Informix is not yet aware of all the new IUS data types. Assert macro will be disabled! lib/DBD/Informix/Defaults.pm written OK esqlvrsn.h written OK esqlinfo.h written OK Gosh! Perl doesn't think your compiler handles prototypes. Well, even though I don't believe it, we'll take Perl's word for it and we won't try to force them into use. Don't you need to upgrade your compiler? If you run into compilation problems with the test program, you will need to revisit this issue. Testing whether your Informix test