ODBC Theory: Why do I still need database specific client drivers?
From: Joe F. <maxplunk_at_hotmail.com>
Date: 6 May 2002 06:30:37 -0700
Message-ID: <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.
Date: 6 May 2002 06:30:37 -0700
Message-ID: <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 Mon May 06 2002 - 15:30:37 CEST