You need a DBD module (such as DBD::Sybase). Here's a modified example from the DBI documentation:

use DBI;

my $data_source = "DBD::Sybase::dbname";    # or something like this
my $dbh = DBI->connect($data_source, $username, $password);

my $sth = $dbh->prepare(' SELECT user, pass FROM auth ');    # or some
+thing like this
$sth = $dbh->execute;
while (($user, $pass) = $sth->fetchrow_array)) {
    # do something
}
[download]

The Perl database module to use is DBI.

I disagree. DBI might be a solution. It depends what you want. If you are satisfied with the lowest common denominator API, and you're going to swap database servers around, DBI is the way to go. But swapping database servers isn't common, just as people don't run a different OS or different hardware every week, and nor do they swap from language to language.

Instead, you might prefer access to the full API of your database vendor. Sybase has three different libraries, DBlib, CTlib and BCP. There's an excellent, mature Perl interface for that (Sybase::* aka sybperl).

DBI is nice, but like most things, it's not the be all, end all. Why can't we apply there is more than one way to do it on modules?

-- Abigail

But swapping database servers isn't common

Really? It is in my experience. I've written throwaway Perl programs that have lasted years beyond their useful lifetimes, switched OS and database servers half a dozen times, and have benefitted greatly from the cross-platform nature of Perl and the cross-database nature of DBI.

Yes, sybperl might be more mature, and it gives wider access to the Sybase API, but is that really what a Perl newbie writing a Web login program is looking for? I'd be looking for the widest portability possible, both for that specific program and my own learning curve.

Or perhaps I'm just a Web designer used to choosing the lowest common denominator anyway. ;)

~chris

> Why can't we apply TIMTOWTDI on modules

I would have to disgree on that one. Although there are no official standards for accessing databases through perl, DBI has become the unofficial standard. In this specific question, (Mork seems to be a newbie user, learning perl, etc) I would recommend against swimming against the tide. I'd stick with chromatic's DBI suggestion, so that Mork can share his/her doubts with other monks that use DBI (be it on MySQL, Oracle, Postgres, and not only Sybase).

> But swapping database servers isn't common

Again, I have to disagree. There are many cases in which people switch databases on a daily, maybe hourly base! I have a real example I use almost everyday at work:

My company develops systems for clients that use several different flavors of DBMS's. All of the developers have perl, IIS and Access (DBD::ODBC) installed on their machines. Our main staging server has Oracle (DBD::Oracle) and our clients might use Informix, DB2, MySQL, MS SQL, Postgres, you name it... That's a clear example of how one might switch from DBD::ODBC, to DBD::Oracle, to DBD::Whatever on an hourly basis!

Just my R$0.02 worth, anyway.

#!/home/bbq/bin/perl
# Trust no1!

Caveat: I am not well-versed with Perl DBI, and do not yet own this book, but have had consistantly good experience with the 20 other O'Reilly books in my library, Perl or otherwise.

Yea or Nay from DBI-head Monks?

Programming the Perl DBI is excellent. Buy it. Read it.

The only O'Reilly book I've felt I wasted my money on is 'MySQL & mSQL'. That book is nothing more than a rehash of 'perldoc DBI'. For a good mySQL book (if that's what you're using, of course), get the MySQL by Paul DuBois from New Riders.

The remaining 10 or so O'Reilly books I have I've felt are good values.

--Chris

e-mail jcwren

yea from me on Programming the Perl DBI
It's short and sweet, and it is probably the easiest
O'Reilly book I have read.
Of course, we're talking DBI here, not Sendmail ;)