Antwort: compilation requirements for DBD-DB2

2004-10-13 Thread Manfred . Beilfuss
   
  
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?

2004-10-13 Thread Scott T. Hildreth
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

2004-10-13 Thread Wieland Pusch
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

2004-10-13 Thread Darin McBride
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?

2004-10-13 Thread Joseph Bruni
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

2004-10-13 Thread Joseph Bruni
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

2004-10-13 Thread Das, Manojit
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

2004-10-13 Thread Tim Bunce
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

2004-10-13 Thread Tim Bunce
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

2004-10-13 Thread Jonathan Leffler
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