This Data Flow Diagram (DFD) depicts all of the key components in a Linux ODBC environment. This DFD is numbered to highlight the flow when connecting to a database system.

1. An App makes calls (SQLAllocEnv, SQLAllocConnect, SQLConnect) to the Driver Manager.
2. The Driver Manager responds to an SQLConnect by cross-referencing the given Data Source Name (DSN) to a Database Driver.
3. The Driver Manager loads the Database Driver and asks it to connect.
4. The Database Driver may need to obtain additional options from the DSN.
5. The Database Driver uses a Database System specific call to connect to the Database System.

NOTE: odbc.ini and odbcinst.ini are considered to be ODBC System Information. All access (read or write) to this System Information should occur via the Driver Manager or the ODBCINST share library. Do not access these INI files directly!

The odbc.ini file contains a list of Data Sources and any properties for each. There are two types of odbc.ini files; 1) System and 2) User. The System odbc.ini file exists as /etc/odbc.ini while the user usually exist as ~/.odbc.ini. By default, the Driver Manager will search for given Data Sources using the following scheme;

1. Using an environment variable to indicate the path of the User odbc.ini. For Example ODBCINI + /.odbc.ini.
2. Using the home dir of the process owner as defined in /etc/passwd to find the path for .odbc.ini.
3. Using the System odbc.ini as /etc/odbc.ini.

The User and System odbc.ini files serve the same functionality except that system services can assume a higher level of security on the System odbc.ini.

ini files contain the same syntax requirements. Data Source names are embraced by square brackets. Properties follow on subsequent lines and use PropertyName = PropertyValue. For example;

driver = /usr/lib/libsybase.so.11
tracefile = /home/pharvey/sql.log
trace = off
database = dbAccounting

Each Data Source name must have, at least, a driver property defined. This will allow the Driver Manager to load the driver when a connect call is made. The only properties the Driver Manager works with are DRIVER, TRACEFILE, and TRACE. Other properties will be interpreted by the Driver as the Driver sees fit and are irrelevant to the Driver Manager. An [ODBC Data Sources] section is maintained in each odbc.ini and may or may not be used by the odbcinst library.

System and User odbc.ini files are configured using the graphical ODBC Config program.

This ini file simply lists all installed drivers. It is located in /etc/odbcinst.ini. The syntax is simple; a name followed by a property which tells us the drivers file name. For example;

[Sybase 11]
Comment = Super Duper Sybase Server
Driver =  /usr/lib/libsybase.so.11
Setup = /usr/lib/libsybaseS.so.11
FileUsage = 1

The Driver file name ( ie /usr/lib/libsybase.so.11 ) should be unique. The friendly name ( ie Sybase 11 ) must also be unique. 

The Setup property points to a shared lib containing functions to be called by ODBC Config. ODBC Config will call this share to get driver specific property names during data source configuration. If ODBC Config can not find/use this file it will assume some defaults such as; Data Source Name, Host, and default Database.

One should always modify this file either using the ODBCINST share library or by using the command line equivalent odbcinst.

The Graphical Stuff
The ODBC spec includes two instances where a GUI would be particularly useful. The LinuxODBC project is in the process of implementing GUI for both instances. First, the two instances...

1. Configuration

ODBC Config needs to allow the user to config driver specific options. In the MS'ism this is handled by the ODBC Admin calling the Driver (or related libs) and then letting the Driver do the rest. LinuxODBC will not force the Driver to handle such work. Instead; the ODBC Config will call a Drivers Setup library to get a simple list of properties. ODBC Config will handle presentation and saving of these properties. This approach will make the creation of Driver Setup libs VERY simple because they only have to supply a list of options.

2. Login Prompt

The DriverManager may have to prompt the user for more login information. It can do this when it has been compiled with X options in.