ODBC client connection information is generally deployed as an ODBC data source. You can deploy an ODBC data source in one of the following ways:
Programmatically Add a data source description to your end-user's registry or ODBC initialization files.
Manually Provide your end users with instructions, so that they can create an appropriate data source on their own computer.
On Windows, you create a data source manually using the ODBC Administrator, from the User DSN tab or the System DSN tab. The SQL Anywhere ODBC driver displays the configuration window for entering settings. Data source settings include the location of the database file, the name of the database server, and any start up parameters and other options.
On Unix platforms, you can create a data source manually using the SQL Anywhere dbdsn utility. Data source settings include the location of the database file, the name of the database server, and any start up parameters and other options.
This section provides you with the information you need to know for either approach.
There are three kinds of data sources: User data sources, System data sources, and File data sources.
User data source definitions are stored in the part of the registry containing settings for the specific user currently logged on to the system. System data sources, however, are available to all users and to Windows services, which run regardless of whether a user is logged onto the system or not. Given a correctly configured System data source named MyApp, any user can use that ODBC connection by providing DSN=MyApp in the ODBC connection string.
File data sources are not held in the registry, but are held in a special directory. A connection string must provide a FileDSN connection parameter to use a File data source.
Each user data source is identified to the system by registry entries. The simplest way to ensure the correct creation of registry entries for data source definitions is to use the SQL Anywhere dbdsn utility to create them.
Otherwise, you must create a set of registry values in a particular registry key.
For User data sources, the key is as follows:
HKEY_CURRENT_USER\ SOFTWARE\ ODBC\ ODBC.INI\ user-data-source-name
For System data sources, the key is as follows:
HKEY_LOCAL_MACHINE\ SOFTWARE\ ODBC\ ODBC.INI\ system-data-source-name
The key contains a set of registry values, each of which corresponds to a connection parameter. For example, the SQL Anywhere 11 Demo key corresponding to the SQL Anywhere 11 Demo system Data Source Name (DSN) contains the following settings for 32-bit Windows:
|Value name||Value type||Value data|
|Description||String||SQL Anywhere 11 Sample Database|
It is recommended that you include the ServerName parameter in connection strings for deployed applications. This ensures that the application connects to the correct server in the event that a computer is running multiple SQL Anywhere database servers and can help prevent timing-dependent connection failures.
In these entries, install-dir is the SQL Anywhere installation directory. For 64-bit Windows, bin32 would be replaced by bin64.
In addition, you must add the data source name to the list of data sources in the registry. For user data sources, you use the following key:
HKEY_CURRENT_USER\ SOFTWARE\ ODBC\ ODBC.INI\ ODBC Data Sources
For system data sources, use the following key:
HKEY_LOCAL_MACHINE\ SOFTWARE\ ODBC\ ODBC.INI\ ODBC Data Sources
The value associates each data source with an ODBC driver. The value name is the data source name, and the value data is the ODBC driver name. For example, the system data source installed by SQL Anywhere is named SQL Anywhere 11 Demo, and has the following value:
|Value name||Value type||Value data|
|SQL Anywhere 11 Demo||String||SQL Anywhere 11|
User data source configurations can contain sensitive database settings such as a user's ID and password. These settings are stored in the registry in plain text, and can be viewed using the Windows Registry editors regedit.exe or regedt32.exe, which are provided by Microsoft with the operating system. You can choose to encrypt passwords, or require users to enter them when connecting.
You can identify the data source name in an ODBC connection string in this manner,
On Windows, when a DSN parameter is provided in the connection string, the Current User data source definitions in the Windows Registry are searched, followed by System data sources. File data sources are searched only when FileDSN is provided in the ODBC connection string.
The following table illustrates the implications to the user and developer when a data source exists and is included in the application's connection string as a DSN or FileDSN parameter.
|When the data source ...||The connection string must also identify ...||The user must supply ...|
|Contains the ODBC driver name and location; the name of the database file/server; startup parameters; and the user ID and password.||No additional information||No additional information.|
|Contains the ODBC driver name and location; the name of the database file/server; startup parameters.||No additional information||User ID and password if not provided in the DSN.|
|Contains only the name and location of the ODBC driver.||The name of the database file (DBF=) and/or the database server (ENG=). Optionally, it may contain other connection parameters such as Userid (UID=) and PASSWORD (PWD=).||User ID and password if not provided in the DSN or ODBC connection string.|
|Does not exist||The name of the ODBC driver to be used (Driver=) and the database name (DBN=), the database file (DBF=), and/or the database server (ENG=). Optionally, it may contain other connection parameters such as Userid (UID=) and PASSWORD (PWD=).||User ID and password if not provided in the ODBC connection string.|
For more information about ODBC connections and configurations, see the following:
The Open Database Connectivity (ODBC) SDK, available from Microsoft.
|Discuss this page in DocCommentXchange.
Send feedback about this page using email.
|Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1|