Re: ODBC Theory: Why do I still need database specific client drivers?
Date: 9 May 2002 04:00:09 -0700
most Database Providers do also Provide a Client Networking License
with their Product which enables you to access the DB. This might
cause a certain degree of platfrom dependency. The general idea of
ODBC is to be platform independant but the reality is far away from
what you described. I would suggest that you choose an independant
ODBC Driver Provider like OpenLink to connect to your Database as most
Databases and OSs are being supported by these Drivers.
Further information is available at http://www.openlinksw.com.
Let me know if you got any further questions on this matter,
hope this helps,
maxplunk_at_hotmail.com (Joe F.) wrote in message news:<7889ff69.0205060530.27e09a0d_at_posting.google.com>...
> According to what I learned in college, if I have any database running
> on any type of server (independant of OS and RDBMS) and it provides an
> ODBC connection, theoretically, any client (ie a program using ODBC
> protocol) should be able to connect to that database and be completely
> unaware of what kind of database it is, as long as it speaks ODBC.
> This is supposed to be a beautiful thing, speaking Esperanto SQL, and
> everyone just gets along together.
> So why, in my implementation (which is in Perl using the DBD-ODBC
> module), must I provide a client-side, database-specific ODBC driver?
> Doesn't this defeat the purpose of ODBC?
> Can anyone clarify this matter? Am I mistaken on the purpose of ODBC?
> (In my particular case I am trying to connect to both Sybase, for
> which I have a client driver, and InterSystems Cache, which does not
> have any Perl-drivers available, but provides an ODBC connection at
> the server. I know I can connect to both with Java, but I need the
> text parsing capability of Perl.)
Received on Thu May 09 2002 - 13:00:09 CEST