On Linux and UNIX, SYSTEM
data sources are typically defined in /etc/odbc.ini
. USER
data sources are defined in ~/.odbc.ini
.
On Windows, data sources are created in ODBC Data Source Administrator. The available system data sources are listed in the System DSN tab. The user data sources that are available for the currently logged on user are listed in the User DSN tab.
Refer to your ODBC driver's documentation for information about how to create a data source and the connection details that you need to put in it.
On Linux and UNIX, you need read access to the .ini
file that contains the data source.
On Windows, the user account that is attempting to access the data source needs to have sufficient permissions to read the registry subkey where the data source is stored. System data sources are stored under HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI. User data sources are stored under HKEY_CURRENT_USER\Software\ODBC\ODBC.INI.
SYSTEM
data sources or ODBC drivers are defined in non-standard files or locations and you have not set the relevant environment variable to tell unixODBC where to find them.
You may need to set ODBCSYSINI
, ODBCINSTINI
, or ODBCINI
. For more information, refer to ODBC on Linux and UNIX platforms.
User data sources are defined for a specific user.
Driver
attribute is either missing from the data source or has an invalid value.
The ODBC Driver Manager relies on the Driver
attribute to know which ODBC driver to load.
Driver
attribute points to is not installed on your machine.
On Linux and UNIX, to display a list of installed drivers, enter odbcinst -q -d
.
On Windows, the Drivers tab in ODBC Data Source Administrator lists the installed drivers.
Driver
attribute is missing, has an invalid value or points to an ODBC driver that is not installed on your machine.The remote data source specified in your ODBC-ODBC Bridge client data source (the TargetDSN
attribute value) needs to exist on the machine (or machines) specified with the ServerPort
attribute.
–Or–
SQLDriverConnectW
, which expects the UCS-2 encoding. You may be able to work around this by configuring your application to behave differently. For example, some versions of the Oracle Heterogeneous Services agent, DG4ODBC, supports the init file setting, HS_NLS_NCHAR = UCS2
, which causes it to pass UCS-2 encoded data to the ODBC APIs rather than UTF-8. Some ODBC driver distributions may include an ANSI-only version of the driver, which may cause your application to behave differently. For example, there is an ANSI-only version of Easysoft SQL Server ODBC driver, which has the suffix "_a":
[MY_SQL_SERVER_ODBC_DRIVER_DSN] #Driver = Easysoft ODBC-SQL Server Driver = /usr/local/easysoft/sqlserver/lib/libessqlsrv_a.so