Install the DBI and DBD::Sybase. Sybperl is a holdover from the days of yore (read - before the DBI), and while still functional and all that, you really want to use the DBI.

There are a few gotchas, such as the need for the dblib and ctlib functions (with a free as in speech version at this site.) Or if you happen to have a copy of Sybase SQL Server for *nix sitting around, you could use those.

If I recall, in some cases, make test might fail, but this has been, in my experience, a non-showstopping problem.

It's a great interface, that allows you to use any DBMS that speaks in Tabular Data Streams (read - Sybase SQL Server, MS SQL Server, and Sybase SQL Anywhere).

ALL HAIL BRAK!!!

...and don't forget *my* personal favorite, Oracle... :)

As long as one uses the right DBD - DBD::Oracle, one can even move data from Sybase to Oracle (movement direction intended :) )

Update: Didn't want to start a religious war over which database is better than another, more wanted to illustrate that one can employ the DBI/DBD modules to move data or munge data easily between one or more databases from different vendors.

Mike - mps@discomsys.com

"The two most common elements in the universe are hydrogen... and stupidity."
Harlan Ellison

use DBI. Yes, very nice.

But as far as I can tell, I need to get the Open Client installed and configured properly, which is unsupported and undocumented, to make the DBD work, but it looks like freeTDS will work too. I'm not sure about Sybperl, but I expect the same from it.

My initial thoughts are that I should use DBI, but we have lots of scripts here that use sybperl, and it may be better to stick with a company standard.

Our sybase servers are Sun systems (Thank goodness! We already have too damn many boxes that need regular reboots!) I'm not sure what "those" you are referring to.

Do you use freeTDS? It looks pretty promising. Have you tried the Sybase Open Client for Linux? How well do the system(s) you have used work?

Oracle, huh? Well, we have Sybase up and running and I don't even want to guess what it would cost to switch, even if the server itself were free. Forgive me if I don't demand a switch. Anyhow, for what I'm going to be doing, mySql would be fine. If I use sybase, it's one less piece of software that I personally have to maintain.


TGI says moo

My current test environment at work is as follows:
• DBI && DBD::Sybase
• Open Client libs from Sybase for Linux (note these are free as in beer for development and perhaps other purposes, read the license since it may apply for in house use.)
• MS SQL 6.5

I made an attempt (months ago, and I know FreeTDS has leapt since then) to get the FreeTDS libs working on a connection with MS SQL 7.0. Abject failure was what I accomplished. I read every HowTo and various readme I could find, and got nada. This was in a very tight situation where the connection had to be brought up ASAP, so I went to ODBC. But as I said, FreeTDS has made mucho progress since then, and anyway it was probably user error. :)

My advice is keep sybperl around, but migrate any new projects to DBI. Trust me. It's not that you have that chance to change DBMS platforms, but it is something that is always nice to be prepared for. If you switch in a year and 75% of your codebase is sybperl, it takes time to rebuild; if you switch in 5 years and 20% of your codebase is in sybperl, then you have avoided a major bullet. The key here is that you'd rather be flexible enough just in case. Plus, what if they bring in some new DBMS to sit next to your Sybase DBMS. What then? DBI facilitates communication is what then.

ALL HAIL BRAK!!!

Sybperl is not only quite a bit older than DBD::Sybase but also is at a lower level and provides more functionality of the underlying client libraries. Which you choose depends on what you need to accomplish -- DBD::Sybase has always done everything I need with no problems. The fact that ASE 11.0.3 is free for development and deployment on Linux makes this combo a real killer, even if the db is a little older.

Also, note that sometimes you need to rebuild perl (the executable) to use Sybperl on Linux, since there can be conflicting library names between Open Client and one of the DBM libraries that get compiled into Perl. (The FAQ explains all this.)

Chris

M-x auto-bs-mode

I am using DBI and DBD::Sybase at work since about a year now. Not many problems.

One thing we noted is that it sometimes is hard to get DBI running smoothly when there is a locale in use (since these rarely are integrated into the Sybase build/configuration procedure - you can configure Sybase properly, too).

In this case, a fast workaround is to unset the environment variables LANG and LC_ALL.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

princepawn, ++ for bringing up the management viewpoint. I'd have to agree that knowing both APIs would be a sound view.

My argument is that somebody has to be the butterfly that causes the storm halfway 'round the world. I'm sure that sybperl handles what is necessary, but eventually, the port to DBD::Sybase will be considered. That's why I suggest early adoption (in the case where you may have to support legacy code in sybperl until you move entirely to DBD, not in the case where you choose an untested technology to build an enterprise solution on). I'd be interested to see if you agree with me that bucking the trend is worthwhile given that one day, the impossible will be required, and management decides to port to an independent interface to be more flexible.

ALL HAIL BRAK!!!