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.

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