Good comments. Maybe this should turn into a FAQ. My observations below
and, I too, will let this fade...
>
> Agree! Thank goodness for consistent API for DBI. If only SQL syntax
> could be that consistent!
Agreed...that's a battle no matter what.
>
> Some last thoughts and I will fade into sunset on this topic....
>
> DBD::ODBC has some other advantages in multi-vendor situation or project:
>
> 1. Point DSN to New DBMS -- Same script can be pointed at different data
> source, just by giving the DBD::ODBC script a different DSN parameter.
> Whether DSN points to text, Foxpro, DB2, oracle, SQL Server, etc. I
> admit this is not a requirement in many applications.
If you look at the DSN as a whole, you can "extend" this to:
dbi:Oracle:TNSNAME vs. dbi:ODBC:DSN... simple enough for both, IMHO.
>
> 2. Meta data Support -- For last few years, only DBD::ODBC seemed to
> provide a consistent and complete way to access metadata: primary and
> foreign keys, indexes, table/column definitions. This appears to be
> changing w/newer DBI releases.
True...but, as you point out, more and more drivers are supporting the DBI
specs.
>
> 3. DB Properties -- The 'getting' private method of DBD::ODBC provides
> access to SQLGetInfo to get DB properties about quoted identifiers, case
> sensitivity of table/column names, owner/schema support ('owner.table'
> syntax). etc. This is quite useful in building dynamic SQL statements
> for different DB vendors.
Same as above...yes.
>
> On the downside:
> ---------------
> 1. Variants in ODBC drivers can be problem (or real pain in few cases).
I agree -- Especially Oracle's :) Each release changes enough that you have
to be very careful -- or, buy into a 3rd party that supplies multiple ODBC
drivers for multiple DBMSs. That *reduces*, but does not eliminate
differences...
>
> 2. ODBC is much more prevalent and common place on Windows, but not as
> prevalent on Unix.
Also true.
3. Speed. DBD::Oracle, for example, is MUCH faster than DBD::ODBC when
talking to Oracle.
Jeff
>
>
> Anyhow, just some thoughts from the last few years.
>
> Bill
>
>
> Jeff Urlwin wrote:
>
> >>
> >>Your message shows you migrating from Sybase to Oracle. What about when
> >>the customer (or your mgt) decides to use DB2?
> >>
> >>The other points are quite valid, but ask yourself about future DB
> >>changes or multi-vendor situation? I like DBD::ODBC solution since my
> >>group has had to deal w/multi-vendor situation.
> >>
> >
> > I'm glad you like DBD::ODBC :)
> >
> > However, part of the DBI concept is that it provides a
> consistent api to the
> > databases. Aside from date handling it does a great job.
> >
> > Jeff
> >
> >
> >>Jeff Urlwin wrote:
> >>
> >>
> >>>If you can, use DBD::Oracle. It will generally be faster and have less
> >>>"layers" between you and the database.
> >>>
> >>>Regards,
> >>>
> >>>Jeff
> >>>
> >>>
> >>>
> >>>>Hi All,
> >>>>
> >>>> I want to migrate to migrate some existing Sybase Perl
> >>>>Programs to work with ORACLE 9. Would it be better to go for
> >>>>DBD::ODBC or DBD:ORACLE.
> >>>>
> >>>>Thanks in Adavance,
> >>>>Arun
> >>>>
> >>>>
> >>
> >>------------------------------------------------------------------------
> >>Bill Cowan, Vice President R&D, Metagenix, Inc.
> >>[EMAIL PROTECTED], 919-490-0034 X-218, Fax: 919-490-0143
> >>URL: http://www.metagenix.com/
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> -- Bill
> ------------------------------------------------------------------------
> Bill Cowan, Vice President R&D, Metagenix, Inc.
> [EMAIL PROTECTED], 919-490-0034 X-218, Fax: 919-490-0143
> URL: http://www.metagenix.com/
>
>
