Received: from post.demon.co.uk by lion with SMTP (PP) id <23894-9@lion>; Thu, 20 Oct 1994 07:32:17 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Wed, 19 Oct 94 23:08:54 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa19493; 20 Oct 94 0:08 GMT-60:00 Received: by gw.home.vix.com id AA15588; Wed, 19 Oct 94 11:34:40 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA15584; Wed, 19 Oct 94 11:34:38 -0700 Received: from sbi.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA15811 for perldb-interest@vix.com; Wed, 19 Oct 94 14:37:58 -0400 Received: from mhfl.sbi.com by internet.sbi.com (4.1/SMI-4.1) id AA11488; Wed, 19 Oct 94 14:34:33 EDT Received: from sdev1.sbi.com by mhfl.sbi.com (4.1/SMI-4.1) id AA26608; Wed, 19 Oct 94 14:34:31 EDT Received: from old-yeller.sbi.com by sdev1.sbi.com (5.0/SMI-SVR4) id AA29509; Wed, 19 Oct 1994 14:34:27 +0500 Received: by old-yeller.sbi.com (5.0/SMI-SVR4) id AA05842; Wed, 19 Oct 1994 14:34:26 +0500 Date: Wed, 19 Oct 1994 14:34:26 +0500 From: Roger Kohler Message-Id: <9410191834.AA05842@old-yeller.sbi.com> To: perldb-interest@vix.com X-Sun-Charset: US-ASCII Content-Length: 119 I would like a subscription to the DBperl mailing list. My address is: Roger Kohler rkohler@mhfl.sbi.com Thank you ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <24539-1@lion>; Thu, 20 Oct 1994 09:27:29 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Thu, 20 Oct 94 08:13:08 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa25307; 20 Oct 94 9:12 GMT-60:00 Received: by gw.home.vix.com id AA29230; Wed, 19 Oct 94 21:08:55 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA29224; Wed, 19 Oct 94 21:08:53 -0700 Date: Thu, 20 Oct 1994 0:12:56 -0400 (EDT) From: Jay Lawrence Message-Id: <941020001256.2040@BESTPL.HCF.JHU.EDU> Subject: List alive? To: perldb-interest@vix.com X-Vmsmail-To: SMTP%"perldb-interest@vix.com" I see that this list is actually working. I havn't heard "boo" from it. I am needing to develop an interface between perl and my BASISPlus DBMS. I have a fair understanding of the C interface to the DBMS and now would like to adapt some of my current work to be interfaced directly into Perl as user subs. My biggest need is to find some examples of how people read and write to perl arrays in their user subs. I must admit I haven't had much time to investigate the language source. Instead I was hoping to get a (some) good example of how others are doing this and go from there. Thanks for listening.... Jay ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <29895-4@lion>; Thu, 20 Oct 1994 16:22:38 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Thu, 20 Oct 94 15:21:11 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa22588; 20 Oct 94 16:20 GMT-60:00 Received: by gw.home.vix.com id AA07403; Thu, 20 Oct 94 04:00:16 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA07399; Thu, 20 Oct 94 04:00:15 -0700 Received: from ignite.demon.co.uk by post.demon.co.uk id aa18984; 20 Oct 94 11:55 GMT-60:00 Received: from ig.co.uk by lion id <24815-0@lion>; Thu, 20 Oct 1994 09:55:12 +0100 To: perldb-interest@vix.com, JJL@bestpl.hcf.jhu.edu Subject: Re: List alive? Date: Thu, 20 Oct 1994 09:55:12 +0100 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9410201155.aa18984@post.demon.co.uk> > From: Jay Lawrence > > I see that this list is actually working. I havn't heard "boo" from it. > It'll pick up in volume shortly. > I am needing to develop an interface between perl and my BASISPlus DBMS. > > I have a fair understanding of the C interface to the DBMS and now would like > to adapt some of my current work to be interfaced directly into Perl as user > subs. > Great. > My biggest need is to find some examples of how people read and write to perl > arrays in their user subs. I must admit I haven't had much time to investigate > the language source. Instead I was hoping to get a (some) good example of how > others are doing this and go from there. > To get started take a look at the documentation supplied with Perl 5.000. Especially the perlapi, perlguts, perlcall, perlembed etc > Thanks for listening.... > Jay > Regards, Tim. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <05426-2@lion>; Fri, 21 Oct 1994 07:31:15 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Thu, 20 Oct 94 19:26:15 GMT Received: from gw.home.vix.com by post.demon.co.uk id ab08575; 20 Oct 94 20:02 GMT-60:00 Received: by gw.home.vix.com id AA11874; Thu, 20 Oct 94 07:22:09 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA11870; Thu, 20 Oct 94 07:22:06 -0700 Date: Thu, 20 Oct 1994 10:26:09 -0400 (EDT) From: Jay Lawrence Message-Id: <941020102609.2140@BESTPL.HCF.JHU.EDU> Subject: My interface plans... To: perldb-interest@vix.com X-Vmsmail-To: VMAIL$TRANSPORT"perldb-interest@vix.com" The only thing about looking at the Perl 5 source code (for me) is that I am using a VAX for all my work. I only have perl 4.19 (and not completely functional) for VMS. Is this taken care of in 5??? Anyway, thanks for the response. Jay ------------------------------ Jay Lawrence - Cartermill Inc. 410 563-2378 phone 410 563-5389 fax ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <05426-12@lion>; Fri, 21 Oct 1994 07:32:31 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Thu, 20 Oct 94 22:51:23 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa18503; 20 Oct 94 23:50 GMT-60:00 Received: by gw.home.vix.com id AA25890; Thu, 20 Oct 94 14:46:36 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA25876; Thu, 20 Oct 94 14:46:27 -0700 Date: Thu, 20 Oct 94 22:35:37 GMT From: Tony Sidaway Reply-To: oracle@sidaway.demon.co.uk Message-Id: <5089@sidaway.demon.co.uk> To: perldb-interest@vix.com Subject: Solaris 2.3 oraperl 2.4 X-Mailer: PCElm 1.09 Lines: 11 I've successfully built perl 4.036 under Solaris. Well, it ran all the regression tests. Now I need to build oraperl 2, patch level 4. The makefile I've got is for Oracle 6. I'm running ORACLE7. Anyone got a makefile to do this? Thanks in advance Tony -- Tony Sidaway oracle@sidaway.demon.co.uk ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <08417-1@lion>; Fri, 21 Oct 1994 11:57:46 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 21 Oct 94 10:10:12 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa27897; 21 Oct 94 11:09 GMT-60:00 Received: by gw.home.vix.com id AA15263; Fri, 21 Oct 94 01:17:40 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA15259; Fri, 21 Oct 94 01:17:38 -0700 Received: by mail.ic.uva.nl id AA17407 (5.67b/IDA-1.4.4 for perldb-interest@vix.com); Fri, 21 Oct 1994 09:17:30 +0100 Message-Id: <199410210817.AA17407@mail.ic.uva.nl> From: Karel Sprenger Date: Fri, 21 Oct 1994 09:17:29 +0100 In-Reply-To: Tony Sidaway's message as of Oct 20, 22:35 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: perldb-interest@vix.com Subject: Re: Solaris 2.3 oraperl 2.4 Tony, On Oct 20, 22:35 Tony Sidaway wrote: > I've successfully built perl 4.036 under Solaris. Well, it ran all the > regression tests. > Now I need to build oraperl 2, patch level 4. The makefile I've got is > for Oracle 6. I'm running ORACLE7. Anyone got a makefile to do this? > I have put the one we used on ftp.ic.uva.nl in directory /usr/karel/oraperl. Good luck, Karel -- Karel Sprenger Informatiseringscentrum | phone: +31-20-525 2302 Universiteit van Amsterdam | +31-20-525 2741 Turfdraagsterpad 9, NL-1012 XT AMSTERDAM | fax : +31-20-525 2084 *** PGP Public Key available on servers *** | home : +31-20-675 0989 ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <08753-0@lion>; Fri, 21 Oct 1994 12:38:00 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 21 Oct 94 11:22:55 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa24787; 21 Oct 94 12:22 GMT-60:00 Received: by gw.home.vix.com id AA15062; Fri, 21 Oct 94 01:03:43 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA15058; Fri, 21 Oct 94 01:03:41 -0700 Received: from ignite.demon.co.uk by post.demon.co.uk id aa07713; 21 Oct 94 8:47 GMT-60:00 Received: from ig.co.uk by lion id <06263-0@lion>; Fri, 21 Oct 1994 08:47:45 +0100 To: perldb-interest@vix.com, oracle@sidaway.demon.co.uk Subject: Re: Solaris 2.3 oraperl 2.4 Date: Fri, 21 Oct 1994 08:47:45 +0100 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9410210847.aa07713@post.demon.co.uk> > From: Tony Sidaway > > I've successfully built perl 4.036 under Solaris. Well, it ran all the > regression tests. > Now I need to build oraperl 2, patch level 4. The makefile I've got is > for Oracle 6. I'm running ORACLE7. Anyone got a makefile to do this? > Take a look in ftp.demon.co.uk:/pub/perl/db/perl4/oraperl/ Meanwhile here's an extract from one of the oracle7.* files in that directory: ===CUT=== Change these Makefile lines: < OCILIB = $(ORACLE_HOME)/rdbms/lib/libocic.a < NETLIBS = $(ORACLE_HOME)/rdbms/lib/osntab.o \ < $(ORACLE_HOME)/rdbms/lib/libsqlnet.a < ORALIBS = $(ORACLE_HOME)/rdbms/lib/libora.a < ALL_ORA_LIBS = $(CLIBS) $(OCILIB) $(NETLIBS) $(ORALIBS) --- to these: > OCILIB = -locic > NETLIBS = $(ORACLE_HOME)/lib/osntab.o -lsqlnet > ORALIBS = -lora -lcv6 -lcore -lsqlnet > ALL_ORA_LIBS = -L$(ORACLE_HOME)/lib $(CLIBS) $(OCILIB) $(NETLIBS) $(ORALIBS) ===CUT=== Some of the oracle7.* files document important problems and bugs. > Thanks in advance > > Tony > -- > Tony Sidaway > oracle@sidaway.demon.co.uk > Regards, Tim. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <18662-7@lion>; Sat, 22 Oct 1994 18:12:22 +0100 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Sat, 22 Oct 94 01:42:56 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa19526; 22 Oct 94 2:42 GMT-60:00 Received: by gw.home.vix.com id AA04430; Fri, 21 Oct 94 14:21:01 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA04423; Fri, 21 Oct 94 14:20:45 -0700 Date: Fri, 21 Oct 94 20:56:55 GMT From: Tony Sidaway Reply-To: oracle@sidaway.demon.co.uk Message-Id: <5146@sidaway.demon.co.uk> To: perldb-interest@vix.com Subject: Re: Solaris 2.3 oraperl 2.4 X-Mailer: PCElm 1.09 Lines: 19 Thanks to everybody who responded to my request, especially those who sent a makefile or pointed me at ftp.demon.co.uk (now why didn't *I* think of that?) Special thanks to Jim Fox who pointed me in the right direction. Turns out my build was all wrong because perl-4.036 configure made a UCB version when I needed AT&T. This problem can't be that rare and its the sort of thing that'd trip up a VAX/VMS specialist like me. I'm messing with makefiles and config.sh at the moment and I'll summarise to the list when I have success. BTW: anyone know if this list is archived, or does it just all boil off into the aether? Once again, thanks. I'm on the right track now. -- Tony Sidaway Oracle@sidaway.demon.co.uk (I live here, rented) Tony.Sidaway@mcl.co.uk (These guys pay my rent) ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <14532-3@lion>; Tue, 25 Oct 1994 06:31:42 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Mon, 24 Oct 94 23:39:35 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa14702; 24 Oct 94 23:39 GMT Received: by gw.home.vix.com id AA22558; Mon, 24 Oct 94 05:34:46 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA22554; Mon, 24 Oct 94 05:34:43 -0700 Received: from ignite.demon.co.uk by post.demon.co.uk id ab02743; 24 Oct 94 12:11 GMT Received: from ig.co.uk by lion id <29508-0@lion>; Mon, 24 Oct 1994 10:18:43 +0000 To: perldb-interest@vix.com, oracle@sidaway.demon.co.uk Subject: Re: Solaris 2.3 oraperl 2.4 Date: Mon, 24 Oct 1994 10:18:43 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9410241211.ab02743@post.demon.co.uk> > From: Tony Sidaway > > Thanks to everybody who responded to my request, especially those who > sent a makefile or pointed me at ftp.demon.co.uk (now why didn't *I* > think of that?) > > Special thanks to Jim Fox who pointed me in the right direction. > Turns out my build was all wrong because perl-4.036 configure made > a UCB version when I needed AT&T. This problem can't be that rare > and its the sort of thing that'd trip up a VAX/VMS specialist like > me. I'm messing with makefiles and config.sh at the moment and I'll > summarise to the list when I have success. > > BTW: anyone know if this list is archived, or does it just all > boil off into the aether? > Yes, guess where ? ftp.demon.co.uk:/pub/perl/db/DBI/perldb-interest/ Here's the README from that directory --- snip --- Archives of the perldb-interest@vix.com mailing list. Maintained by Tim.Bunce@ig.co.uk on ftp.demon.co.uk:/pub/perl/db Old Files: perldb-i.v03 180Kb perldb-i.v040 60Kb perldb-i.v041 230Kb perldb-i.v042 430Kb perldb-i.v043 150Kb perldb-i.v05a 400Kb Sections 1 thru 3 perldb-i.v05b 300Kb Sections 4 thru 5 perldb-i.v05c 140Kb Sections 6 to end of version 0.5 DBI Specification Version 0.6 (for Perl 5) perldb-i.v06a 230Kb May to Aug 1994 (Perl 5 in alpha) perldb-i.v06b 110Kb Aug to Oct 1994 (Perl 5 in beta) perldb-i.v06c ?Kb Nov 1994 onwards (DBI in alpha) The file suffixes relate very roughly to the version of the DBI spec that was released in that files first message. Files with a .gz suffix are in GNU ZIP format. This archive is only updated on an ad-hoc basis. Tim Bunce. --- snip --- But note that almost none of this related to oraperl. Also, the ftp archive may be down for awhile as they are upgrading to 9Gb of mirrored disk. > Once again, thanks. I'm on the right track now. > -- > Tony Sidaway > Oracle@sidaway.demon.co.uk (I live here, rented) > Tony.Sidaway@mcl.co.uk (These guys pay my rent) > Regards, Tim Bunce. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <14277-0@lion>; Wed, 2 Nov 1994 06:32:06 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Tue, 01 Nov 94 18:52:18 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa18677; 1 Nov 94 18:38 GMT Received: by gw.home.vix.com id AA17811; Tue, 1 Nov 94 07:00:06 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA17789; Tue, 1 Nov 94 07:00:04 -0800 Date: Tue, 1 Nov 1994 10:02:44 -0500 (EST) From: Jay Lawrence Message-Id: <941101100244.47c7@BESTPL.HCF.JHU.EDU> Subject: Re: List alive? To: perldb-interest@vix.com X-Vmsmail-To: SMTP%"perldb-interest@vix.com" I have managed to build some simple dump and load interfaces for my DBMS (BASISPlus). They are quite effective, but suffer from performance problems. right now I'll just overnight any big stuff. In the long-run I do want to develop a generalized set of functione that are built right into Perl - to save on overhead of connecting to the DB, and spawning external processes. My biggest question at this time is how to work with associative arrays. You see, I like to stuff the fields into an array with the field's name as its index. this makes processing a BREEZE. Are there any exemplary pieces of code that clearly show adding, modifying, and removing elements from an associative array? Any help is gratefully accepted. Thanks, Jay ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <12789-1@lion>; Fri, 4 Nov 1994 17:45:10 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 04 Nov 94 17:42:09 GMT Received: from gw.home.vix.com by post.demon.co.uk id ab07172; 4 Nov 94 17:41 GMT Received: by gw.home.vix.com id AA13154; Fri, 4 Nov 94 03:23:48 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA13150; Fri, 4 Nov 94 03:23:44 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id ad14380; 4 Nov 94 11:23 GMT Received: from ig.co.uk by lion id <09593-0@lion>; Fri, 4 Nov 1994 11:14:32 +0000 To: perldb-interest@vix.com, JJL@bestpl.hcf.jhu.edu Subject: Re: List alive? Date: Fri, 4 Nov 1994 11:14:32 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9411041123.ad14380@post.demon.co.uk> > From: Jay Lawrence > > I have managed to build some simple dump and load interfaces for my DBMS > (BASISPlus). They are quite effective, but suffer from performance problems. > right now I'll just overnight any big stuff. > > In the long-run I do want to develop a generalized set of functione that > are built right into Perl - to save on overhead of connecting to the DB, and > spawning external processes. > > My biggest question at this time is how to work with associative arrays. You > see, I like to stuff the fields into an array with the field's name as its > index. this makes processing a BREEZE. > > Are there any exemplary pieces of code that clearly show adding, modifying, and > removing elements from an associative array? Any help is gratefully accepted. > In the short term take a look at the Perl 5.000 documentation. Especially perlapi and perlguts. In the longer term I hope you'll consider implementing a BASISPlus driver for the DBI being developed here. > Thanks, > > Jay > Regards, Tim. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <26801-3@lion>; Tue, 8 Nov 1994 06:32:49 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Tue, 08 Nov 94 00:18:06 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa01729; 8 Nov 94 0:17 GMT Received: by gw.home.vix.com id AA08041; Mon, 7 Nov 94 09:35:09 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA08034; Mon, 7 Nov 94 09:35:05 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id aa28092; 7 Nov 94 17:34 GMT Received: from ig.co.uk by lion id <24217-0@lion>; Mon, 7 Nov 1994 17:33:17 +0000 To: perldb-interest@vix.com Subject: Status and current issues Date: Mon, 7 Nov 1994 17:33:17 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9411071734.aa28092@post.demon.co.uk> Hello again, It's been awhile and I've got some issues I want to bounce around. The DBI has now been significantly reworked (again) to allow it to provide more and better support for extensions. Here's a flavor of the XS code required to implement $dbh->commit for Oracle: void commit(dbh) SV * dbh CODE: D_dbihcom(dbh); /* Declare DBI Handle COMmon data struct */ D_imp_dbh; /* Declare Implementors private DBH struct */ ocom(imp_dbh->lda); /* Do an Oracle commit */ if (imp_dbh->lda->rc==0) XSRETURN_YES; /* return true if it worked */ /* Generate an error event if it failed */ XSRETURN_SV(DBIh_EVENT1(ERROR_event, sv_2mortal(newSViv(imp_dbh->lda->rc)) )); I've put an updated DBI on ftp.demon.co.uk:/pub/perl/db/DBI/. This is *NOT* a release. It WILL *NOT* COMPILE against 5.000 (it requires patches I've sent to Larry since 5.000 was released and a new version of MakeMaker I'm currently working on). It's only of interest to those who really want a sneak preview. If it looks like Larry won't be releasing a perl 5 patch in short term I may release a version of the DBI which will build against 5.000. There are two major topics I want to discuss now, Error/Event handling and fetching data rows. I apologies in advance for any ramblings below. Error/Event Handling -------------------- The players in this scene... - Return values from methods - $handle->err error code value - $handle->errstr error message value - 'Global' $DBI::err and $DBI::errstr variables (equiv to $h->err*) (automatically refers to last DBI handle used) - The SQL2 standard SQLSTATE variable Assumptions... - Errors are rare, error checking is much more common - Using eval { ... } within the DBI would be too expensive Design decisions... - All errors and warnings are recorded & processed via event handlers - The default handler prints a message - Driver is free to either set errstr message string when error occurs or 'on demand' when errstr is first used afterwards. Outstanding Issues... - Should we support an SQLSTATE variable ? The meaning of err and errstr are inherently totally non-portable. DBI applications seeking to be portable will have significant problems interpreting error situations (deadlocks, privilege, disk space etc). The SQL2/ISO/ANSI standard specifies a 5 character SQLSTATE variable consisting of a 2 char class and a 3 char subclass. Around 30 classes have been defined. The most significant for this discussion are: 00000 - Successful completion 01nnn - Warning 02000 - Data not found (no more rows) 07000 - Dynamic SQL error (a reasonable default bucket for errors) This is the standard to which database engines will be migrating over time. We cannot ignore it. - Implementing an SQLSTATE variable I propose that the DBI and it's drivers base their error reporting on the SQLSTATE variable standard via a $handle->state method and/or $handle->{'State'} attribute. The database engines own code and message would still be available via err and errstr. As a minimum Drivers would only be expected to translate engine codes into one of the four state code listed above. The DBI will provide support such that state "00000" appears false. - Should $handle->err and/or $handle->state only be set/reset on error (like unix errno) ? This implies that it must be possible to determine method failure from the return value of the method call. This may be tricky. Lifespan of $handle->err/state value will increase (because the're not being reset on every method call). Fetching Data Rows ------------------ This is much more fun... It seems that the fragments of perl programs which fetch data from databases fall into two broad categories: Those that discard one row as the next is fetched and those that store the rows for later use. I'm looking at moving away from the old-style: @row = $sth->fetch; or ($field1, $field2, $field3) = $sth->fetch; to something more like: $obj = $sth->fetchobj; where $obj is a (possibly blessed) reference to an array. The main aims are to: reduce the amount to data being slung through the stack, reduce the number of perl-level assignments, reduce the amount of memory allocations and frees per row fetch and, lastly, be more object oriented. Consider these loops: push(@all, [@row]) while(@row = $sth->fetch); vs push(@all, $obj) while($obj = $sth->fetchobj); The amount of work that perl is having to do is much less in the second case. Just as a very quick check: use Benchmark; timethese(100, { 'new' => '$i=1000; push(@all, $obj ) while($obj = [1,2,3] and --$i)', 'old' => '$i=1000; push(@all,[@row]) while(@row = (1,2,3) and --$i)', }); Benchmark: timing 100 iterations of new, old... new: 10 secs ( 8.95 usr 1.78 sys = 10.73 cpu) old: 15 secs (12.55 usr 2.60 sys = 15.15 cpu) "How about the convenience of the ($f1, $f2, $f3) = $sth->fetch style?" I hear you ask. Consider these loops: $sth->execute(...); while(($field1, $field2, $field3) = $sth->fetch){ ... do something with $field1, $field2 etc ... } vs $sth->execute(..., [\($field1, $field2, $field3)]); while($sth->fetchobj){ ... do something with $field1, $field2 etc ... } Again, the amount of work that perl is having to do is much less in the second case. The driver is writing the data *directly* into the variables referenced earlier. For those not worried about performance a default fetch() method would be provided which calls fetchobj() and then returns the fields in the old-style. Enough rambling from me, what do you think? Regards, Tim Bunce. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <05559-1@lion>; Wed, 9 Nov 1994 09:13:44 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Wed, 09 Nov 94 00:25:14 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa15835; 9 Nov 94 0:25 GMT Received: by gw.home.vix.com id AA18849; Tue, 8 Nov 94 09:43:18 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA18845; Tue, 8 Nov 94 09:43:17 -0800 Received: by tymix.Tymnet.COM (4.1/SMI-4.1) id AA09017; Tue, 8 Nov 94 09:43:16 PST Received: from nts-gw by tymix.Tymnet.COM (in.smtpd); 8 Nov 94 9:43:15 PST Received: from enchanter.Tymnet.COM by antares.Tymnet.COM (8.6.5/UCB) id JAA19068; Tue, 8 Nov 1994 09:43:05 -0800 Received: by enchanter.Tymnet.COM (5.0/SMI-SVR4) id AA12230; Tue, 8 Nov 1994 09:44:11 +0800 Date: Tue, 8 Nov 1994 09:44:11 +0800 From: Tom Hackwood Message-Id: <9411081744.AA12230@enchanter.Tymnet.COM> To: perldb-interest@vix.com Subject: Re: Status and current issues X-Sun-Charset: US-ASCII Content-Length: 4259 Tim Bunce sends a message ... > Error/Event Handling > -------------------- > > Outstanding Issues... > > - Should we support an SQLSTATE variable ? Personal opinion, I don't really care much for what I do, *but* as you said, it is a standard, so it should be done. > > The meaning of err and errstr are inherently totally non-portable. > DBI applications seeking to be portable will have significant problems > interpreting error situations (deadlocks, privilege, disk space etc). I agree that the meaning of err and errstr are non-portable. They deliver messages specific to any implementaion a DBMS. However, for debugging purposes, I know I'll still need them around. > - Implementing an SQLSTATE variable > > I propose that the DBI and it's drivers base their error reporting > on the SQLSTATE variable standard via a $handle->state method and/or > $handle->{'State'} attribute. The way I see it, you really don't have a choice. Portability rules here, and this is just about the only way you can do it. > The database engines own code and message would still be available > via err and errstr. As a minimum Drivers would only be expected to > translate engine codes into one of the four state code listed above. Within perl DBI's, maybe that a standard library ought to be built to translate vendor-specific error messages to a common format. How any specific error gets translated should be upto the developer of the DBI. The developer of the DBI would use the standard messages, and submit new messages to cover exceptions for his specific DBI. Eventually, as the DBI library grows, the error-message library grows. Case in point: Unify 2000 and Oracle not only have different lock methods, they have totally different terminology for the internals of implementation. I wasted *days* on attempting to find a solution for a lock issue before I found that "I couldn't do that". If the error messages were consistent across DBI's, with some mention of lock types, packet types, shadow tables, synchronous updates, blah-blah-blah, the perl programmer would not have to be an "expert" in any flavor of SQL. Instead the perl programmer would know how to program in perl, and know how to use the DBI, but not necessarily how to be, say a Pro-C programmer for Oracle. So, fuel for the fire: I think we need a standard error library that should keep error terminology consistant across the various DBI's. > > > > - Should $handle->err and/or $handle->state only be set/reset on error > (like unix errno) ? $handle->err should be reset only if there is an error. $handle->state should be set to whatever is appropriate. A state change does not always consitute an error. (No more rows & no more data to find are to "non-erronous" states.) > Fetching Data Rows > ------------------ [examples of "old-style" vs "new-style" code ... Tim likes "new style"] > The main aims are to: reduce the amount to data being slung through > the stack, reduce the number of perl-level assignments, reduce the > amount of memory allocations and frees per row fetch and, lastly, > be more object oriented. [soap box mode on] I can agree with every reason but one: be more object oriented. I don't want to get into a philosophical discussion here, but there are cases where being object-oriented leads to a longer development cycle. One of the reasons I use perl is that I can create-on-the-fly short little hacks to do whatever my mind is thinking of in 2 minutes or less. Programming in an object oriented manner makes me *think* :-). Perl with DBI extenstions isn't going to do me much good if I have to go through a design effort before I code a rushed hack. Now, don't get me wrong -- I do write production type stuff with perl. For this design is *required*, and programming with objects is preferable. But I do have a lot of "hacks" where efficiency isn't needed, and I just want to get the job done. [soap box mode off] [performance stuff here] > For those not worried about performance a default fetch() method would > be provided which calls fetchobj() and then returns the fields in the > old-style. Why not overload the method? Or is this what you are thinking of? Tom Hackwood ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <05556-2@lion>; Wed, 9 Nov 1994 09:13:55 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Wed, 09 Nov 94 00:40:38 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa18621; 9 Nov 94 0:40 GMT Received: by gw.home.vix.com id AA23890; Tue, 8 Nov 94 12:10:53 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA23874; Tue, 8 Nov 94 12:10:31 -0800 Received: from solaris by aqueous with SMTP id AA13345 (5.65c/IDA-1.4.4 for ); Wed, 9 Nov 1994 07:10:02 +1100 From: Jeff Stander Received: by solaris (4.1/Spike-2.2) id AA11536; Wed, 9 Nov 94 07:09:50 EST Date: Wed, 9 Nov 94 07:09:50 EST Message-Id: <9411082009.AA11536@solaris> To: perldb-interest@vix.com Subject: Oracle & oraperl utilities Some of these programs may be of interest to those in the perldb-interest group. -- My two years contract with the CSIRO Division of Fisheries is now finished. I have placed in the CSIRO public ftp directory most of the general purpose utilities, routines and commands which I have written to help my work. I hope they may be of help you. Feedback to my new email address is welcome. All the best, Jeff Stander. ___________________________________________________________________________ JEFF'S DIRECTORIES IN THE CSIRO FTP AREA: /software/jstander/dbfx - DBF (dBase/Foxpro) file reader for loading to Oracle via flat files /software/jstander/form_verifcation - double entry data verification /software/jstander/tsmlib - library of useful C routines /software/jstander/perllib - my perl subs and packages /software/jstander/wdbex - world database map extractor /software/jstander/xsql - Xwindow SQL and tables /software/jstander/oracle_utilities - see following: ___________________________________________________________________________ MISCELLANEOUS ORACLE UTITILES The utilities in this directory are a collection of tools I use to help me with Oracle. Please note that some of these utilities are "quick and dirty", while others (noteably the ones written in Perl and Oraperl) are a bit more robust. I offer them only to share what I have written for my own use and do not make any guarantees that they will work for you. I hope they do help, of course, and if you find any bugs I'd appreciate a message. If you find them useful (or awful) I would like to hear your opinions. The most useful program to "the world" so far has been "unloadr", which extracts data in Oracle tables to flat files and also creates a desciptor file ("dex" file) which contains the data dictionary. The companion routines to "unloadr" are "mkloadf", and "dexalign" which together constitute a suite of programs focusing around the dex file which make it very easy to create and manage tables in the Unix environment. Jeff Stander ___________________________________________________________________________ Location: host: ftp.ml.csiro.au IP: 192.67.12.100 dir: /software/jstander/oracle_utilities In the above directory the following utilities for ORACLE and ORACLE*FORMS are stored as various zip, shar, and tar file archives: orautils.shar - all utilities in shar format orautils.shar.Z - all utilities in shar format, compressed orautils.tar.Z - all utilities tar format orautils.zip - all utilities zipped unloadr.Z - unloadr utility compressed unloadr.zip - unloadr utility zipped flatutils.shar - shar file for ASCII data file utilities only General: README - this notice oraperl.FAQ - FAQ for oraperl FORMS 3.0 utilities checkform - variable reference info from .inp file compfldnames - check field names against table in .inp file lineup - filter to reset field alignment in .inp file Loading and unloading revline - write standard source code headers dexalign - field descriptor alignment in .dex file mkloadf - create control, create table, and input files for Oracle data loading mkloadf.1 - manual page for above revline - create boilerplate headers for scripts/programs/dex files revline.1 - manual page for above unloadr - extract data from Oracle table to delimited ASCII file, has embedded man page Database Maintenance create_index - create table indexes datadict - create nroff/troff data dictionary table drop_index - drop table indexes find_dups - program to find duplicate keys in a table newstruct - unload and reload a table into a new or modified structure nextval - show next value in Oracle sequence Xwindow utitlities (uses xtpanel) xbox - pipe stdin or file to an Xwindow "box" xsqlbox - like above but tailored to Oracle SQL*PLUS output sqlx/xsqlx - shell/Xwindow interface to Oracle database tables/xtables - shell/Xwindow table and database information manager ASCII data file maintenance: add_delims - insert or change delimiters in ASCII file add_delims.1 - manual page for above insert_delims - insert delimiters at fixed columns in ASCII file insert_delims.1 - manual page for above zerofill_fields - pad numeric/fill numeric/move fields in ASCII file zerofill_fields.1 - manual page for above Perl/Oraperl/C subroutines: keypress.pl - sub to read from keyboard keypress.c - called by keypress.pl, needs to be compiled fullpath.pl - find full path name of argument nsu.pl - handle netgroup superuser access rform.pl - run Oracle forms in xterm window selection.pl - create user selection menu sqlx.pl - SQL*PLUS subroutine library for perl & oraperl test_for_oracle.pl - test if Oracle running on this host dtime.pl - formatted time misc.pl - miscellaneous subs oraenv.pl - set Oracle environment (needs customizing) oraenv6.pl - set Oracle environment (needs customizing) revline.pl - create standard source code headers rform.pl - run a form with runform30 subopts.pl - parse options to Perl subs unloadr.pl - support for unloadr To Install: 1. Compile keypress.c with your favorite C compiler. (e.g. gcc -fpcc-struct-return -o keypress keypress.c) 2. Copy all the .pl files to your perl library directory (e.g. /home/jstander/lib/perl). 3. Link the following files: ln xtables tables ln unloadr unloadr.1 ln sqxl xsqlx 4. Copy all the document files (*.1 files) to your ../man/man1 directory. 5. Copy the executables to a directory in your PATH, (normally bin): add_delims checkform compfldnames create_index datadict dexalign drop_index find_dups insert_delims keypress (you just compiled this) lineup mkloadf nextval newstruct revline sqlx tables unloadr xbox xsqlbox xsqlx xtables zerofill_fields 6. Environment: The following environment variables will affect these routines: ORACLE_HOME - should contain Oracle home directory ORACLE_HOST - should contain name of Oracle host machine PRINTER - should contain default printer name NSU_USER - if reqd. set to default user to 'nsu' to COPYRIGHT - should contain your copyright string 7. If you don't have xtpanel on your system, you will need to get and install that (see the README file) 8. If you don't have Perl 4.0 or later you will need to get and install that, too. Also you will need oraperl for many of the programs and xtpanel for the Xwindow stuff. ___________________________________________________________________________ PERL SUBROUTINES AND UTILITIES host: ftp.ml.csiro.au IP: 192.67.12.100 dir: /software/jstander/perllib Doc - manual for the routines contained herein dtime.pl - formatted time fullpath.pl - get full path of a directory or file keypress.pl - raw response from keyboard* misc.pl - small utilities (max, min, in_list, etc) nsu.pl - handles network superuser to other userid oraenv.pl - Oracle 7 environment oraenv6.pl - Oracle 6 environment print.pl - handles access to network printers revline.pl - part of revline program rform.pl - run Oracle FORMS30 selection.pl - simple interactive selection menu sqlx.pl - Oracle interface routines (uses oraperl) subopts.pl - handle option passing in subroutine arguments test_for_oracle.pl - see of Oracle present on host timing.pl - mark and report on running times tsm.pl - some file testing routines uncomment.pl - remove C-style and shell comments unloadr.pl - support Oracle 'unloadr' routine usage.pl - write the "usage: .." statement variance.pl - stats: standard deviation and variance ask.c - C program to support keypress.pl revline - write program headers revline.1 - manual page for revline ask.1 - manual page for ask * requires "C" program: ask ___________________________________________________________________________ FORMS 3.0 DOUBLE ENTRY DATA VERIFICATION Forms Tools in /software/jstander/form_verification These are tools for working with FORMS 3.0 inp files. checkform - check as form and produce a table of fields, locs, etc. checkform.1 - man page for above insert_proc - insert a procedure into a form insert_trig - insert a trigger into a form lineup - manipulate field locations in the inp file lineup.1 - man page for above mkverify - convert an inp file to a double-entry verification form mkverify.1 - man page for above sqlx.pl - perl support package for mkverify misc.pl - perl support package for mkverify subopts.pl - perl support package for mkverify anzora.ps - postscript documentation of ANZORA (Oracle User Group) paper on double entry data verification. anzora.wp - WordPerfect document of above ___________________________________________________________________________ Jeff.Stander@ml.csiro.au _--_|\ Database Analyst CSIRO Division Of Fisheries / \ Pelagic Fisheries Resources GPO Box 1538, Hobart \_.--._/ Tasmania 7001, Australia Aus Tel: 002-325-332 v Intl Tel: +61-02-325-332 Aus Fax: 002-325-000 Intl Fax: +61-02-325-000 ___________________________________________________________________________ NEW ADDRESS EFFECTIVE 8 NOVEMBER 1994: jstander @ozemail.com.au (Note: Mail to above will be forwarded). ---+++--- Received: from punt.demon.co.uk by lion with SMTP (PP) id <29403-1@lion>; Fri, 11 Nov 1994 06:31:42 +0000 Received: from punt.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 11 Nov 94 02:13:10 GMT Received: from gw.home.vix.com by punt.demon.co.uk id aa26648; 11 Nov 94 2:12 GMT Received: by gw.home.vix.com id AA18418; Thu, 10 Nov 94 15:25:51 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA18411; Thu, 10 Nov 94 15:25:33 -0800 Date: Thu, 10 Nov 94 23:02:21 GMT From: Tony Sidaway Reply-To: oracle@sidaway.demon.co.uk Message-Id: <5965@sidaway.demon.co.uk> To: perldb-interest@vix.com Subject: Perl/oraperl/perldb for ORACLE FAQ X-Mailer: PCElm 1.09 Lines: 22 Searching for perl/oraperl/perldb WWW pages or html documents. I'm working on the oraperl link to the Oracle FAQ, which is being compiled by David Bath. I have located the oraperl FAQ (or thought I had; it seems to have moved since I last found it using Archie) and the idea is to convert it to html[*] so that the FAQ, which will be a series of WWW pages. David Bath will probably be contacting Tim Bunce separately for a paragraph or so about perldb. But it occurs to me that somebody may have already done some html work on perl and even oraperl. It would be a waste to duplicate that work. So my question is: are there any WWW pages or html in existence concerning perl and oraperl? URL's please if possible. My access to the WWW is through a mail server, and I'm a complete newbie so it's rather difficult for me to find out. [*] tech note: html is the hypertext language used in the World Wide Web [WWW] -- Tony Sidaway oracle@sidaway.demon.co.uk ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <29421-0@lion>; Fri, 11 Nov 1994 06:31:43 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Thu, 10 Nov 94 22:20:01 GMT Received: from gw.home.vix.com by post.demon.co.uk id ab01158; 10 Nov 94 22:19 GMT Received: by gw.home.vix.com id AA08660; Thu, 10 Nov 94 10:02:19 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA08656; Thu, 10 Nov 94 10:02:08 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id aa11163; 10 Nov 94 18:01 GMT Received: from ig.co.uk by lion id <27023-0@lion>; Thu, 10 Nov 1994 17:50:45 +0000 To: tchrist@mox.perl.com Subject: Re: Oraperl availability Cc: perldb-interest@vix.com Date: Thu, 10 Nov 1994 17:50:45 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9411101801.aa11163@post.demon.co.uk> > From: Tom Christiansen > > In article you write: > :In article <39osvc$qp1@wolfe.wimsey.com> Bo Graham writes: > :>I am wondering where I can ftp ORAPERL from. > :> > :ftp.demon.co.uk:/pub/perl/db/perl4/oraperl/ > : > :>I just downloaded PERL5.000. Will all versions of Oraperl work with it? > :> > :No. Perl 4 extensions will not work, or even compiler, with Perl 5. > : > :An Oracle database interface driver is in the works. > > any idea when? It's becoming a faq. > Some time after I stop beating MakeMaker into shape. Sometime after I take two weeks off in Portugal in late November. Sometime after Christmas. Sometime. I really wish I could be more specific. I'm designing and implementing the DBI, the Oracle DBD, the DBI/DBD interface and the script/DBI interface all at the same time! Then I tear bits up and do it again! The core DBI is now stable (after a rewrite). The DBI/DBD interface and Oracle DBD implementation for the driver (dr) class and the database session (db) class is also stable. I'm now beating my head against the Event/Error handling and the statement (st) classes, especially row and field buffer management. As per my recent message to perldb-interest, which, incidentally, generated almost no interest whatsoever :-( > --tom > Regards, Tim. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <00278-0@lion>; Fri, 11 Nov 1994 09:54:21 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 11 Nov 94 07:40:04 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa15910; 11 Nov 94 7:39 GMT Received: by gw.home.vix.com id AA25185; Thu, 10 Nov 94 20:10:57 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA25181; Thu, 10 Nov 94 20:10:56 -0800 Received: from aeronomics.COM by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA22527 for ; Thu, 10 Nov 94 23:11:23 -0500 Received: from jnl5 by aerohpux (1.37.109.4/3.2.083191-Aeronomics Incorporated) id AA03132; Thu, 10 Nov 94 23:04:58 -0500 Original-Received: from cc:Mail by jnl5.aeronomics.com id AA784537512 Thu, 10 Nov 94 23:05:12 EST PP-warning: Illegal Received field on preceding line Date: Thu, 10 Nov 94 23:05:12 EST From: HESS@aeronomics.com Message-Id: <9410107845.AA784537512@jnl5.aeronomics.com> To: perldb-interest@vix.com Subject: Re: Perl/oraperl/perldb for ORACLE FAQ There's a good hypertext perl 5 manual on: http://www.cs.cmu.edu:8001/htbin/perl-man To my knowledge, there's no OraPerl hypertext document. :-( - John Hess ______________________________ Reply Separator _________________________________ Subject: Perl/oraperl/perldb for ORACLE FAQ Author: oracle%sidaway.demon.co.uk@aerohpux at UnixGateway Date: 11/10/94 9:13 PM Searching for perl/oraperl/perldb WWW pages or html documents. I'm working on the oraperl link to the Oracle FAQ, which is being compiled by David Bath. I have located the oraperl FAQ (or thought I had; it seems to have moved since I last found it using Archie) and the idea is to convert it to html[*] so that the FAQ, which will be a series of WWW pages. David Bath will probably be contacting Tim Bunce separately for a paragraph or so about perldb. But it occurs to me that somebody may have already done some html work on perl and even oraperl. It would be a waste to duplicate that work. So my question is: are there any WWW pages or html in existence concerning perl and oraperl? URL's please if possible. My access to the WWW is through a mail server, and I'm a complete newbie so it's rather difficult for me to find out. [*] tech note: html is the hypertext language used in the World Wide Web [WWW] -- Tony Sidaway oracle@sidaway.demon.co.uk ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <20939-1@lion>; Fri, 11 Nov 1994 17:01:18 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 11 Nov 94 16:28:10 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa03249; 11 Nov 94 16:27 GMT Received: by gw.home.vix.com id AA07387; Fri, 11 Nov 94 05:02:44 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA07381; Fri, 11 Nov 94 05:02:40 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id ae18816; 11 Nov 94 13:01 GMT Received: from ig.co.uk by lion id <01383-0@lion>; Fri, 11 Nov 1994 12:39:40 +0000 To: rogers@isi.edu Subject: Re: Oraperl availability Cc: perldb-interest@vix.com Date: Fri, 11 Nov 1994 12:39:40 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9411111301.ae18816@post.demon.co.uk> > From: Craig Milo Rogers > > >I'm now beating my head against the Event/Error handling and the > >statement (st) classes, especially row and field buffer management. As > >per my recent message to perldb-interest, which, incidentally, > >generated almost no interest whatsoever :-( > > I decided that I'd have to read it carefully before I offered > an opionion. I also wanted to reread opinions I'd offered in the > past, as I recall advocating row/field interfaces from what I thought > was a programmer simplicity point of view. > That would be great. I don't think much will happen next week and then I'm off for two weeks break so it could wait till then I guess. > I've also put myself in a little bind with management, telling > them about all the wonderful things one can do with Perl5, but then > saying that we can't use it yet because there's no Oracle interface. > I suspect many people are in this position. Myself included! > Craig Milo Rogers > Regards, Tim. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <22950-0@lion>; Fri, 11 Nov 1994 18:03:30 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 11 Nov 94 17:55:02 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa22028; 11 Nov 94 17:54 GMT Received: by gw.home.vix.com id AA07433; Fri, 11 Nov 94 05:02:47 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA07382; Fri, 11 Nov 94 05:02:41 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id ab18816; 11 Nov 94 13:01 GMT Received: from ig.co.uk by lion id <01319-0@lion>; Fri, 11 Nov 1994 12:31:26 +0000 To: perldb-interest@vix.com, thack@antares.tymnet.com Subject: Re: Status and current issues Date: Fri, 11 Nov 1994 12:31:26 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9411111301.ab18816@post.demon.co.uk> > From: Tom Hackwood > Thanks for the reply - you're the only one who has. I know I bleat on about this from time to time but it would be nice if people just said "That sounds okay Tim" from time to time. > Tim Bunce sends a message ... > > > Error/Event Handling > > -------------------- > > > > Outstanding Issues... > > > > - Should we support an SQLSTATE variable ? > Personal opinion, I don't really care much for what I do, *but* as you > said, it is a standard, so it should be done. > > > > > The meaning of err and errstr are inherently totally non-portable. > > DBI applications seeking to be portable will have significant problems > > interpreting error situations (deadlocks, privilege, disk space etc). > > I agree that the meaning of err and errstr are non-portable. They > deliver messages specific to any implementaion a DBMS. However, for > debugging purposes, I know I'll still need them around. > They'll always be available. > > - Implementing an SQLSTATE variable > > > > I propose that the DBI and it's drivers base their error reporting > > on the SQLSTATE variable standard via a $handle->state method and/or > > $handle->{'State'} attribute. > The way I see it, you really don't have a choice. Portability rules here, > and this is just about the only way you can do it. > > > The database engines own code and message would still be available > > via err and errstr. As a minimum Drivers would only be expected to > > translate engine codes into one of the four state code listed above. > > Within perl DBI's, maybe that a standard library ought to be built to > translate vendor-specific error messages to a common format. How any > specific error gets translated should be upto the developer of the DBI. > The developer of the DBI would use the standard messages, and submit new > messages to cover exceptions for his specific DBI. Eventually, as > the DBI library grows, the error-message library grows. > (I presume you mean DBD instead of DBI in that paragraph.) It's generally very easy for a driver to distinguish between Ok, Warning, No more rows and Error. That's all I'm going to _require_ of a DBD. A well written DBD will translate a number of common warning and error conditions into their _specific_ SQLSTATE equivalents. The DBI will provide a method to translate SQLSTATE codes to the corresponding messages. > Case in point: Unify 2000 and Oracle not only have different lock methods, > they have totally different terminology for the internals of implementation. > I wasted *days* on attempting to find a solution for a lock issue before I > found that "I couldn't do that". If the error messages were consistent across > DBI's, with some mention of lock types, packet types, shadow tables, > synchronous updates, blah-blah-blah, the perl programmer would not have to > be an "expert" in any flavor of SQL. Instead the perl programmer would > know how to program in perl, and know how to use the DBI, but not necessarily > how to be, say a Pro-C programmer for Oracle. > > So, fuel for the fire: I think we need a standard error library that > should keep error terminology consistant across the various DBI's. > You're asking alot from the DBD implementors. Using SQLSTATE should provide as measure of consistency but the actual degree will depend on the DBD implementation. > > - Should $handle->err and/or $handle->state only be set/reset on error > > (like unix errno) ? > > $handle->err should be reset only if there is an error. > > $handle->state should be set to whatever is appropriate. A state change > does not always consitute an error. (No more rows & no more data to find > are to "non-erronous" states.) > That's not a problem. Drivers are required to detect such changes. The issue is whether to _explicitly_ reset the state _before_ taking any action (or, similarly, to explicitly record success). This would mean that it is completely accurate after each action but an error could go unnoticed if another action is preformed before the state is checked. That's the dilemma. The UNIX errno model says "only record errors". The SQLSTATE model says "record the state of every action". Which to choose? Perhaps we can use the SQLSTATE model for $h->state and the errno model for $h->err. > > Fetching Data Rows > > ------------------ > > [examples of "old-style" vs "new-style" code ... Tim likes "new style"] > > > The main aims are to: reduce the amount to data being slung through > > the stack, reduce the number of perl-level assignments, reduce the > > amount of memory allocations and frees per row fetch and, lastly, > > be more object oriented. > > [soap box mode on] > I can agree with every reason but one: be more object oriented. I don't > want to get into a philosophical discussion here, but there are cases > where being object-oriented leads to a longer development cycle. One of > the reasons I use perl is that I can create-on-the-fly short little hacks > to do whatever my mind is thinking of in 2 minutes or less. Programming > in an object oriented manner makes me *think* :-). Perl with DBI > extenstions isn't going to do me much good if I have to go through a > design effort before I code a rushed hack. > > Now, don't get me wrong -- I do write production type stuff with perl. For > this design is *required*, and programming with objects is preferable. But > I do have a lot of "hacks" where efficiency isn't needed, and I just want > to get the job done. > [soap box mode off] > > [performance stuff here] > > > For those not worried about performance a default fetch() method would > > be provided which calls fetchobj() and then returns the fields in the > > old-style. > Why not overload the method? Or is this what you are thinking of? > All DBD classes are derived from base classes provided by the DBI. These provide many default methods to make life easy for the driver developer. In this case the base class will implement a fetch() in terms of fetchobj() *and* a fetchobj() in terms of fetch(). The Driver can simply implement the one that's most natural for it and the DBI provides the other. A driver must implement at least one of them. Consider SQL access to a non-sql database and non-sql access to an SQL database. A driver is either an SQL driver or an non-SQL driver. It either implements an SQL API ($h->prepare() and $h->execute()) or an non-sql API (not yet defined). The driver base classes in the DBI could implement both in terms of the other... (this is wild stuff)... The base class implementation of $h->prepare() and $h->execute() would parse the SQL and execute it using the non-sql API that the driver has implemented. The base class implementation of the non-sql API would convert the calls into SQL and pass them on to the $h->prepare() and $h->execute() functions that the driver has implemented. Before you start shouting - it's all a long way off - it's just an idea! > Tom Hackwood > Regards, Tim Bunce. ---+++--- Received: from punt.demon.co.uk by lion with SMTP (PP) id <28607-0@lion>; Fri, 11 Nov 1994 19:08:57 +0000 Received: from punt.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 11 Nov 94 18:52:12 GMT Received: from gw.home.vix.com by punt.demon.co.uk id aa25201; 11 Nov 94 18:51 GMT Received: by gw.home.vix.com id AA05830; Fri, 11 Nov 94 04:36:04 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA05823; Fri, 11 Nov 94 04:35:59 -0800 Message-Id: <9411111234.AA08437@ac2.hq.eso.org> Received: from localhost.hq.eso.org by ac2.hq.eso.org (4.1/ eso-3.8) id AA08437; Fri, 11 Nov 94 13:34:58 +0100 To: oracle@sidaway.demon.co.uk Cc: perldb-interest@vix.com Subject: Re: Perl/oraperl/perldb for ORACLE FAQ In-Reply-To: oracle's message of Thu, 10 Nov 94 23:02:21 +0000.<5965@sidaway.demon.co.uk> Date: Fri, 11 Nov 94 13:34:58 +0100 From: Bo Frese Rasmussen > Searching for perl/oraperl/perldb WWW pages or html documents. > > [....] > > So my question is: are there any WWW pages or html in existence concerning > perl and oraperl? URL's please if possible. My access to the WWW is > through a mail server, and I'm a complete newbie so it's rather difficult > for me to find out. > > [*] tech note: html is the hypertext language used in the World Wide Web [WWW] > > -- > Tony Sidaway > oracle@sidaway.demon.co.uk This is from my WWW 'hotlist' on Perl
  • Perl. Also, the The DBPerl Specification - Version 0.5 is availalbe in HTML from http://www.metronet.com/1m/perlinfo/dbperl I don't know of any oraperl pages. \\\\\// Cheers | | Bo (.) (.) ==========oOO==(_)==OOo===================================================== Bo Frese Rasmussen E-Mail: bfrasmus@eso.org ESO - EUROPEAN SOUTHERN OBSERVATORY Phone : +49 89 320 06 365 Space Telescope - European Coordinating Facility Fax : +49 89 320 06 480 ---------------------------------------------------------------------------- Everyone can be taught to sculpt: Michelangelo would have had to be taught how NOT to. So it is with the great programmers. ============================================================================ Finger/Talk: bfrasmus@ac2.hq.eso.org ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <01457-0@lion>; Sat, 12 Nov 1994 18:12:11 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 11 Nov 94 20:10:09 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa20770; 11 Nov 94 20:09 GMT Received: by gw.home.vix.com id AA12216; Fri, 11 Nov 94 07:43:49 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA12212; Fri, 11 Nov 94 07:43:48 -0800 Received: from ef0424.efhd.ford.com (ef0424.efhd.ford.com [19.78.50.24]) by dns004.ford.com (8.6.7/8.6.6) with SMTP id KAA01872 for ; Fri, 11 Nov 1994 10:41:09 -0500 Received: from ef0535.efhd.ford.com by ef0424.efhd.ford.com (5.61/1.3U) id AA13077; Fri Nov 11 10:43:28 1994 Date: Fri, 11 Nov 1994 10:43:28 -0500 Message-Id: <9411111543.AA13077@ef0424.efhd.ford.com> X-Sender: wmeahan@ef0424.efhd.ford.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tim Bunce From: Bill Meahan Subject: Re: Status and current issues Cc: perldb-interest@vix.com X-Mailer: Tim Bunce writes: > >> From: Tom Hackwood >> >Thanks for the reply - you're the only one who has. > >I know I bleat on about this from time to time but it would be nice if >people just said "That sounds okay Tim" from time to time. [deletia] "That sound's OK, Tim" I'll probably get flamed for this but .... May I suggest you take a look at Microsoft's ODBC specifications as a possible model for the SQLSTATE issue and DBI/DBD implementation. No, I'm not a member of the Bill Gates Fan Club but I _am_ a working developer (OK, I lead working developers more than do development myself these days) in a not-atypical corporate development environment. Within our company, my group is an "early-adopter" of "client/server" technology (no religious wars over what this means, please) and have spend a lot of time dividing our overall applications between PC-based front ends and HP-UX based data servers where some of the processing load is done on the data servers and is mostly done using oraperl. For shops like ours, having a consistent model and similar syntax is a HUGE benefit since my people and I develop total applications, not just "the front end" or "the back end." Since Visigenic, and others, are developing ODBC libraries for Unix (of which, of course, HP-UX is a variant) it would seem reasonable that Perl-DBI not be radically different from these libraries, again so that developers such as us can benefit from the synergy of the common model across different platforms and languages. This does NOT mean that I think a brainless, wholesale adoption of ODBC for Perl is in order, nor does it mean that I think that ODBC is the ideal method of database connectivity - it surely isn't!! Still, following Larry's principle of lunching off of what's already out there, where reasonable, indicates to this benighted soul that some degree of "ODBC likeness" in Perl DBI would be of value. This would be of especially great value when the folks working on porting Perl5 to MS Windows get something released. Just my $.02 worth (not my company's for sure!) -- Bill Meahan Senior Developer, wmeahan@ef0424.efhd.ford.com Electrical & Fuel Handling Division, Ford Motor Company Information and opinions expressed herein are those of the author and do not represent any official statement by Ford Motor Company ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <01454-2@lion>; Sat, 12 Nov 1994 18:12:13 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 11 Nov 94 21:28:47 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa04917; 11 Nov 94 21:28 GMT Received: by gw.home.vix.com id AA14554; Fri, 11 Nov 94 09:01:55 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA14550; Fri, 11 Nov 94 09:01:46 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id aa10655; 11 Nov 94 17:01 GMT Received: from ig.co.uk by lion id <20837-0@lion>; Fri, 11 Nov 1994 16:58:34 +0000 To: wmeahan@ef0424.efhd.ford.com Subject: Re: Status and current issues Cc: perldb-interest@vix.com Date: Fri, 11 Nov 1994 16:58:34 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9411111701.aa10655@post.demon.co.uk> > From: Bill Meahan > > Tim Bunce writes: > > > >> From: Tom Hackwood > >> > >Thanks for the reply - you're the only one who has. > > > >I know I bleat on about this from time to time but it would be nice if > >people just said "That sounds okay Tim" from time to time. > > [deletia] > > "That sound's OK, Tim" > > I'll probably get flamed for this but .... > > May I suggest you take a look at Microsoft's ODBC specifications as a possible > model for the SQLSTATE issue and DBI/DBD implementation. No, I'm not a > member of the Bill Gates Fan Club but I _am_ a working developer (OK, I lead > working developers more than do development myself these days) in a > not-atypical corporate development environment. I certainly won't flame you for it. I've got the ODBC 1.0 SDK and I've spent a little (but not enough) time looking at it. Anyone thinking of flaming should remember that ODBC is the only widely available implementation of the SQL Access Group Call Level Interface spec (albeit slightly twisted to Microsofts own ends). > Within our company, my > group is an "early-adopter" of "client/server" technology (no religious wars > over what this means, please) and have spend a lot of time dividing our > overall applications between PC-based front ends and HP-UX based data > servers where some of the processing load is done on the data servers and is > mostly done using oraperl. For shops like ours, having a consistent model > and similar syntax is a HUGE benefit since my people and I develop total > applications, not just "the front end" or "the back end." > > Since Visigenic, and others, are developing ODBC libraries for Unix (of > which, of course, HP-UX is a variant) it would seem reasonable that Perl-DBI > not be radically different from these libraries, again so that developers > such as us > can benefit from the synergy of the common model across different platforms > and languages. > Very true. > This does NOT mean that I think a brainless, wholesale adoption of ODBC for > Perl is in order, nor does it mean that I think that ODBC is the ideal > method of database connectivity - it surely isn't!! Still, following > Larry's principle of lunching off of what's already out there, where > reasonable, indicates to this benighted soul that some degree of "ODBC > likeness" in Perl DBI would be of value. This would be of especially great > value when the folks working on porting Perl5 to MS Windows get something > released. > > Just my $.02 worth (not my company's for sure!) Worth more than $.02. Basically I'm trying to steer a course that heads in the direction of all the applicable standards. This can be a little tricky sometimes. I *need* the input of people with experience in this area. > Bill Meahan Senior Developer, wmeahan@ef0424.efhd.ford.com > Thanks for the input Bill, I appreciate it. Regards, Tim Bunce. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <05152-0@lion>; Thu, 29 Dec 1994 06:31:06 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Wed, 28 Dec 94 19:10:30 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa23670; 28 Dec 94 19:09 GMT Received: by gw.home.vix.com id AA08086; Wed, 28 Dec 94 08:18:19 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA08064; Wed, 28 Dec 94 08:18:04 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id aa19344; 28 Dec 94 16:10 GMT Received: from ig.co.uk by lion id <28869-0@lion>; Wed, 28 Dec 1994 12:49:26 +0000 To: grady@swindle.berkeley.edu Subject: Re: objections to inclusion on CD-ROM? Cc: perldb-interest@vix.com Date: Wed, 28 Dec 1994 12:49:26 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9412281610.aa19344@post.demon.co.uk> > From: grady@swindle.berkeley.edu > > Hello. I'm putting together a Perl archive/CD-ROM for Walnut Creek > CD-ROM. (When it is finished, the FTP archive will be available at > wcarchive.cdrom.com.) I am attempting to include all of the perl information > from all the existing perl archives I can find (metronet, UFL, etc..). > As a courtesy, I wanted to make sure that no one objected to having > their work included on the CD-ROM. If any of you have made something > available to the Perl users out there, which has therefore probably found > itself to one of the archives, and you strongly object to the inclusion > of your work on the Perl CD-ROM, please let me know. > > (BTW, I do not work for Walnut Creek.) > I've CC'd this to perldb-interest@vix.com because I'd like to suggest that you include the contents of the DBperl archive: ftp.demon.co.uk:/pub/perl/db > Steven Grady > grady@wcarchive.cdrom.com > Regards, Tim Bunce. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <13743-2@lion>; Fri, 6 Jan 1995 06:31:39 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 06 Jan 95 04:55:51 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa23116; 6 Jan 95 4:55 GMT Received: by gw.home.vix.com id AA06032; Thu, 5 Jan 95 15:43:14 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA05997; Thu, 5 Jan 95 15:42:00 -0800 Received: by netcon.smc.edu (5.59/25-eef, Santa Monica College) id AA23576; Thu, 5 Jan 95 19:45:17 EST Received: by intime.intime.com (Smail3.1.28.1 #2) id m0rPzzd-0003HCC; Thu, 5 Jan 95 13:45 PST Message-Id: Subject: Status? To: perldb-interest@vix.com Date: Thu, 5 Jan 1995 13:45:12 -0800 (PST) From: Scott Michel X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 292 Organization: IntelliMED Corporation, Santa Monica, CA, USA Newbie questions, since no FAQ is readily on hand: a) Which version of DBI is currently being implemented? b) For which databases? c) Which version of Perl? Personally, I have a stake in seeing Informix integrated, but before I get started, I don't want to do useless development. -scottm ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <22934-0@lion>; Fri, 6 Jan 1995 15:16:08 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 06 Jan 95 14:20:55 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa02205; 6 Jan 95 14:20 GMT Received: by gw.home.vix.com id AA24276; Fri, 6 Jan 95 02:33:41 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA24271; Fri, 6 Jan 95 02:33:32 -0800 Received: from ignite.demon.co.uk by post.demon.co.uk id ac14149; 6 Jan 95 10:29 GMT Received: from ig.co.uk by lion id <14837-0@lion>; Fri, 6 Jan 1995 10:19:56 +0000 To: perldb-interest@vix.com, scottm@intime.intime.com Subject: Re: Status? Date: Fri, 6 Jan 1995 10:19:56 +0000 From: Tim Bunce Sender: Tim.Bunce@ig.co.uk Organisation: Paul Ingram Group, Software Systems, +44 483 424424 Message-Id: <9501061030.ac14149@post.demon.co.uk> > From: Scott Michel > > Newbie questions, since no FAQ is readily on hand: > > a) Which version of DBI is currently being implemented? Er, the one that's not been written yet! Basically after the 0.5 spec was completed and frozen we started discussing applying Perl5 features and object orientation. Nothing much has been done with the 0.6 spec yet. It doesn't seem worth do it on paper until an implementation exists. For more info take a look at the perldb-interest archives. Especially ftp.demon.co.uk:/pub/perl/db/DBI/perldb-interest/perldb-i.v06b > b) For which databases? Oracle 7 first, with Ingres 6.4 close behind. Once the first is done most of the others should be simple to implement. > c) Which version of Perl? > Perl 5 > Personally, I have a stake in seeing Informix integrated, but before > I get started, I don't want to do useless development. > Once somthing is working it's likely that the DBI interface will not be very stable for awhile. I intend that drivers for Oracle, Ingres, Informix etc should be supplied with a .pl file which implements the old oraperl, ingperl, isqlperl interfaces. This will allow people to get real work done while giving us the freedom to change the DBI interface if needed. As for when, I hope to get back into heavy DBI/DBD development within a couple of weeks. > -scottm > Regards, Tim Bunce. ---+++--- Received: from post.demon.co.uk by lion with SMTP (PP) id <01868-2@lion>; Mon, 9 Jan 1995 06:31:42 +0000 Received: from post.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Fri, 06 Jan 95 22:47:36 GMT Received: from gw.home.vix.com by post.demon.co.uk id aa16157; 6 Jan 95 22:46 GMT Received: by gw.home.vix.com id AA29626; Fri, 6 Jan 95 06:24:28 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA29624; Fri, 6 Jan 95 06:24:26 -0800 Received: by rmy.rmy.emory.edu (5.65/Emory_rmy.3.4.0) via MAILPROG id AA04862 ; Fri, 6 Jan 95 09:29:27 -0500 Return-Path: walt@rmy.emory.edu Date: Fri, 6 Jan 95 09:29:27 -0500 From: Walt Hultgren Message-Id: <9501061429.AA04862@rmy.rmy.emory.edu> To: perldb-interest@vix.com Subject: Re: Status? > Personally, I have a stake in seeing Informix integrated, but before > I get started, I don't want to do useless development. I'd also like an interface for Informix. I've been monitoring (and occasionally participating in) this list in hopes of seeing that happen. If anyone on the list is trying to gauge the level of interest for an Informix capability, I'd say it would be worth the effort. Questions concerning both Perl and Informix regularly pop up on comp.databases.informix and the Informix mailing list. Walt. -- Walt Hultgren Internet: walt@rmy.emory.edu (IP 128.140.8.1) Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt 954 Gatewood Road, NE BITNET: walt@EMORY Atlanta, GA 30329 USA Voice: +1 404 727 0648 ---+++--- Received: from punt.demon.co.uk by lion with SMTP (PP) id <01875-2@lion>; Mon, 9 Jan 1995 06:31:44 +0000 Received: from punt.demon.co.uk via puntmail for dbperl@ignite.demon.co.uk; Sat, 07 Jan 95 00:39:05 GMT Received: from gw.home.vix.com by punt.demon.co.uk id aa11915; 7 Jan 95 0:38 GMT Received: by gw.home.vix.com id AA16375; Fri, 6 Jan 95 13:43:44 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id AA16370; Fri, 6 Jan 95 13:43:39 -0800 Received: from hpbs2245.boi.hp.com by relay.hp.com with ESMTP (1.37.109.14/15.5+ECS 3.3) id AA230538617; Fri, 6 Jan 1995 13:43:38 -0800 Received: from localhost by hpbs2245.boi.hp.com with SMTP ($Revision: 1.37.109.15 $/16.2) id AA1382547497; Fri, 6 Jan 1995 14:43:37 -0700 Message-Id: <199501062143.AA1382547497@hpbs2245.boi.hp.com> To: perldb-interest@vix.com Subject: Re: Status? In-Reply-To: Your message of "Fri, 06 Jan 1995 09:29:27 EST." <9501061429.AA04862@rmy.rmy.emory.edu> Date: Fri, 06 Jan 1995 14:43:36 -0700 From: Rodger Anderson For what it is worth, I would also be interested in a Perl-Informix interface. Rodger Anderson ---+++---