InterSoft's Implementation over Open Database Connectivity (ODBC)

There are many applications today such as Word Processors, Spreadsheets, etc, which need data access critically to/from many diferents DBMS, by a standard mechanism. In order to do this they must have a way to get the data without knowing how the DBMS treats the tables, indexes, etc.

Microsoft's Open Database Connectivity (ODBC) is an interface which allows the application to access the data via SQL. With this interface the application does not need to know wich DBMS it is working with. In order to access the data, some drivers implemented as DLL (dynamic link libraries) are used, which permits to choose a DBMS in particular (in runtime).

The ODBC architecture has 4 basic components:

  • 1) Application: executes calls to ODBC which invoke SQL statements and obtains the corresponding results

  • 2) Driver Manager: loads the drivers to access each one of the DBMSs according to the application's necessity

  • 3) Driver: processes the ODBC calls, executes the SQL requests to the DBMS (Data Source), and returns the result of the operation to the application.

  • 4) Data Source: composed by the data the application needs to access, associated with the operating system, the DBMS and the network used for the access.

    This figure shows how these components interact with each other:

    ODBC defines 2 kinds of drivers:

  • 1) Single-Tier: they process ODBC functions as well as SQL statements.

  • 2) Multiple-Tier: they process only ODBC calls and send the SQL statements to the Data Source.

    We now exemplify these concepts with the implementation over ODBC made by InterSoft S.A. to both kinds of Drivers.

    In the Single-Tier configuration, as shown in the figure, we can find the application (for example, a spreadsheet working under Windows), the Driver Manager, the Driver and the data, over the same machine.

    The spreadsheet will make a request to data access by the ODBC interface; the Driver Manager will select the adequate driver, in this case the one which accesses to the Ideafix database files, which will resolve the SQL statements as well as the data access. As it can be seen, the Driver is completely autonomous. It is designed to resolve the SQL statements and to access the data stored by Ideafix in the same environment. The Multiple-Tier configuration is more complex but adequate when one wants to handle big volumes of data. In this case, each one of the components can be held in the same machine; nevertheless a more frequent configuration puts the application, the Driver Manager and the driver in a machine (called client), and the database and its access software in another called server.

    To exemplify this configuration let's go back to the spreadsheet example. When this application makes a data access request, it will be the driver who will process the ODBC calls, but it will transmit the SQL statements over the network to the server, where the data and the data access software are stored.

    Under our implementation and in the client machine (working under Windows), there is a .DLL file (the driver) which builds the messages for the execution of the SQL statements. The driver sends them to the server and waits for its aswer to return them back to the application.

    In the server (running under Unix), the data access software is divided in 2 components: the SQL server, which processes the SQL statements received from the driver (parsing, optimization, execution, etc.), and the Essentia database server, which resolves the requirements for the low level data access executed by the SQL server.

    The following figure shows how each one of these components interact and how they are distributed in both machines:

    As we can see, ODBC gives a simple mechanism which allows different configurations and interconections across platforms, and allowing the adoption of a Client-Server architecture (with one or more DBMSs) when handling big volumes of data.