 Introduction
Systems and programmers who had to accommodate two or more databases and had to find a way to make data from both seem as though it came from one. Applications were written in that language for that specific database. Each system (such as Oracle or IBM) had its own programming language, so programmers either had to know both languages or team up with the other programmers to coordinate efforts. A program couldn’t be adapted to handle both databases, so it was clear there needed to be one generic access method to databases. This is where ODBC comes into the picture. ODBC allows a single uniform language to access different databases, instead of using the proprietary language of each database. It did this by designing a standard set of APIs (application program interfaces). Previously, a programming language talked directly to a database, but with ODBC, a programming language talks to the API. The API is developed for each database, so it knows what kind of database you’re trying to talk to (because you told it), and it interprets your requests so that the database can return the information. Since every database driver has to follow the same standard for the APIs, the programming code doesn’t have to change for each database. This open connectivity to a database now allows an application to get data from any kind of database. The application becomes more flexible because you don’t have to write code based on a particular database. The language and database are made by the same manufacturer (such as Oracle); no other language can interact with that database, and the language can communicate only with the databases made by that manufacturer. The database can now be accessed (by using an ODBC driver that’s proprietary to that database) with a variety of languages. Since ODBC is a component used by other programs, such as Access or MS Excel, it has an install option with several programs. Microsoft provides free drivers to MS SQL Server and MS Access. To find drivers to other databases, contact that database’s manufacturer. The client software sits on a client machine and is called from an application. The request from the client application is passed to the ODBC Driver Manager on the client or server. The ODBC Driver Manager decides whether the database driver is installed on the client or server and passes the request to physical database, which can be on the client but is typically on the server. The database on the server fulfills or denies the request and passes the appropriate information back to ODBC driver on the client. The ODBC driver interprets any error information available on the client, if necessary. Finally, the ODBC driver returns the information to the client application.
A driver usually contains the callable API functions for a single database, such as MS SQL Server. The drivers and Driver Manager (also the ODBC DSN Administrator) need to be installed on every client machine. The drivers are dynamic link libraries (DLLs) and the Driver Manager is an executable program (in this case, odbcad32.exe). For each database you want the client to connect to, a data source name (DSN) must be created. The DSN tells the driver where the database is located. In the ODBC 3.0 version of the Administrator, you have three choices for what type of DSN you create: User, System, File. The System DSN allows every user of the computer and system-level resource access to that database. The File DSN allows all users access to the same drivers, but the User DSN allows just a specific user to access this database. For example, if you’re using an NT operating system machine (server or workstation), you can log on as the administrator and install a System DSN or File DSN or you can log on as the user and install a User DSN. The security to access the database is still necessary. If someone logged on with System DSN tries to access the database, he or she must supply a user name and password that the database validates, or the user won’t be allowed into the database. |