Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: Michael Peppler <mpeppler at MBAY dot NET>
Subject: setting a standard for sybperl development
Date: Jun 10 1998 12:57AM

Lee Falkenhagen writes:
 > I have a client that needs to set a standard for development using 
 > SybPerl.  Right now, everyone is developing in their own version.
 > I see three choices:
 > DB-Lib
 > CT-Lib
 > DBI
 > DB-Lib is the only one, to my knowledge, that supports BCP.  But, 
 > according to Sybase, DB-Lib is no longer supported.  But, it seems that 
 > is what the default is for this group.
 > CT-Lib seems to have a lot of problems
 > DBI still is in alpha and we need production quality code.  What is the 
 > time frame for this becoming a release 1.x (Michael?).
 > Any suggestions would be great.  BTW, we do ALOT of bulk loading of 
 > mainframe flat files.

Here's how I see it.

DBlib is the most stable, simply because it's the one I've used most,
and the one others have tended to use the most. As we all know Sybase
will not further enhance DBlib, so any new features that are added at
the server level and that require API access may not be supported from 

CTlib is quite good, and is probably what we all should be using today 
anyway. There are a number of configuration problems because CTlib
needs access to a number of files on startup, and if environment
variables aren't set right then CTlib will break. However the
underlying code is probably at least as solid as DBlib.

DBI (or rather DBD::Sybase) is built on top of Sybase's OpenClient
Client Library (aka CTlib) so the comments regarding the configuration 
issues apply here too. I am not doing a lot of perl development at the 
moment so I have not had time (or the need) to *really* use DBI, and
to get 100% comfortable with it. There seems to be a lot of satisified 
users, but there are bound to be bugs. DBI also limits what you can do 
as it constrains you to the DBI API rather than the native way of
doing things, but that's an advantage if your code may need to get
ported to another RDBMS engine.

For BCP - well I would suggest using Sybase's bcp application rather
than using the BCP API, because the BCP API is slow. I would like to
add a Sybase::BLK module (ie to add the CTlib BCP API) but as usual I
have not had time to look into that (and there haven't been any
requests for it either...).

I will not hazard to say when DBD::Sybase will become really stable. I 
believe it does it's job correctly today, but I haven't used it enough 
myself to feel 100% confident in it, and it doesn't cover the DBI API
spec completely yet.

My suggestions would be to use Sybase::CTlib if the backend is
unlikely to change, and to try to use DBD::Sybase if portability is
required. In addition it's always a good idea to centralize all
database calls in a central module. That way if you want to move from
one backend to another the porting is fairly simple.

Michael Peppler         -||-  Data Migrations Inc.    -||-
Int. Sybase User Group  -||-