Microsoft
Open Database Connectivity (ODBC) is a standard programming interface for
application developers and database systems providers. Before ODBC became a de
facto standard for Windows programs to interface with database systems,
programmers had to use proprietary languages for each database they wanted to
connect to. Now, ODBC has made the choice of the database system almost
irrelevant from a coding perspective, which is as it should be. Application
developers have much more important things to worry about than the syntax that
is needed to port their program from one database to another when business
needs suddenly change.
Through the
ODBC Administrator in Control Panel, you can specify the particular database
that is associated with a data source that an ODBC application program is
written to use. Think of an ODBC data source as a door with a name on it. Each
door will lead you to a particular database. For example, the data source named
Sales Figures might be a SQL Server database, whereas the Accounts Payable data
source could refer to an Access database. The physical database referred to by
a data source can reside anywhere on the LAN.
The ODBC system files are not
installed on your system by Windows 95. Rather, they are installed when you
setup a separate database application, such as SQL Server Client or Visual
Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a file
called ODBCINST.DLL. It is also possible to administer your ODBC data sources
through a stand-alone program called ODBCADM.EXE. There is a 16-bit and a
32-bit version of this program and each maintains a separate list of ODBC data
sources.
From a
programming perspective, the beauty of ODBC is that the application can be
written to use the same set of function calls to interface with any data
source, regardless of the database vendor. The source code of the application
doesn’t change whether it talks to Oracle or SQL Server. We only mention these
two as an example. There are ODBC drivers available for several dozen popular
database systems. Even Excel spreadsheets and plain text files can be turned
into data sources. The operating system uses the Registry information written
by ODBC Administrator to determine which low-level ODBC drivers are needed to
talk to the data source (such as the interface to Oracle or SQL Server). The
loading of the ODBC drivers is transparent to the ODBC application program. In
a client/server environment, the ODBC API even handles many of the network
issues for the application programmer.
The
advantages of this scheme are so numerous that you are probably thinking there
must be some catch. The only disadvantage of ODBC is that it isn’t as efficient
as talking directly to the native database interface. ODBC has had many
detractors make the charge that it is too slow. Microsoft has always claimed
that the critical factor in performance is the quality of the driver software
that is used. In our humble opinion, this is true. The availability of good
ODBC drivers has improved a great deal recently. And anyway, the criticism
about performance is somewhat analogous to those who said that compilers would
never match the speed of pure assembly language. Maybe not, but the compiler
(or ODBC) gives you the opportunity to write cleaner programs, which means you
finish sooner. Meanwhile, computers get faster every year.
No comments:
Post a Comment