Easysoft ODBC-ODBC Bridge

How do I use oobping to test the connection to a remote ODBC DSN?

Last Reviewed:
22nd January 2024

You should first use oobping to test the connection to the Easysoft ODBC-ODBC Bridge Server and to test authentication. Once you have done that, you should have the name of a server where an ODBC-ODBC Bridge Server is running and the port it is listening on. You should also have a valid operating system username and password and be enabled in the ODBC-ODBC Bridge Server access control rules. You can now check connectivity to a specified remote ODBC data source (DSN).

There are two ways to check the connection to a remote DSN with oobping. The simplest way is to add a local DSN to your odbc.ini file and then specify the DSN in the -d argument as "DSN=dsnname". This method tests you have defined the local ODBC-ODBC Bridge client DSN correctly and put the definition in the right file. An alternative method is to specify all the connection attributes in the -d argument, not just the DSN.

For example, suppose as a result of checking the connection to the ODBC-ODBC Bridge Server and ODBC-ODBC Bridge Server authentication, you have the following information:

Server = myserver
Port = 8888
LogonUser = me
LogonAuth = mypassword

Add the name of the target DSN on myserver. (This is the ODBC-ODBC Bridge client attribute TargetDSN.) Note that the TargetDSN value must be a remote SYSTEM data source, you cannot access USER data sources. If the database also needs login information, the database username and password must be specified using the ODBC-ODBC Bridge attributes TargetUser and TargetAuth.

If you want to test a DSN in your odbc.ini file, the .ini file entry would look something like:

ServerPort = myserver:8888
LogonUser = me
LogonAuth = mypassword
TargetDSN = mysystemdsn
TargetUser = dbusername
TargetAuth = dnpassword

Note Later when using the unixODBC Driver Manager, you will need to add "Driver=ODBC-ODBC Bridge" to the above DSN. This is not needed when using oobping, however.

You can run oobping as follows:

oobping -d "DSN=mydsn;"
Using Connection string :
Connected OK

01000:1:5701:[NetConn: 032bc620][Microsoft][ODBC SQL Server Driver]
[SQL Server]Changed database context to 'pubs'.
01000:2:5703:[NetConn: 032bc620][Microsoft][ODBC SQL Server Driver]
[SQL Server]Changed language setting to us_english.

Connected to database:  pubs
DBMS Name:  Microsoft SQL Server
Driver Name:  esoobclient
Driver Version:  01.00.0043

Here you passed the ODBC connection string "DSN=mydsn" to the ODBC-ODBC Bridge client via oobping. The ODBC-ODBC Bridge client did not have sufficient attributes in the connection string to define what it should do, so it looked up the DSN "mydsn" in the odbc.ini file to get additional attributes. It found ServerPort, LogonUser, LogonAuth, TargetDSN, TargetUser and TargetAuth. The ODBC-ODBC Bridge client then connected to the ODBC-ODBC Bridge Server on myserver port 8888, logged you in with the LogonUser/LogonAuth values and finally connected via ODBC to the remote data source "mysystemdsn". In the above example, the DSN pointed to SQL Server. There were some informational diagnostics returned saying the language is "us_english" and the database is "pubs". (Not all databases will return informational messages on the connection). The OutConnectionString is a string returned by the ODBC-ODBC Bridge client that you can use to connect to this data source again (see below). The final messages show the database, DBMS Name and Driver Name/Version (ODBC-ODBC Bridge in this case, obviously).

Instead of specifying just the name of a DSN to oobping and defining the other connection attributes in the odbc.ini file, you can specify all the connection attributes in one go and not use an odbc.ini file. The OutConnectionString above shows you what connection string you could have passed to the ODBC-ODBC Bridge client. To connect without a DSN, remove "DSN=mydsn;".

For example:

oobping -d "UID=dbusername;PWD=dbpassword;SERVERPORT=myserver:8888;

would produce the same result as above.

You might be slightly confused why you specify TargetUser/TargetAuth in the odbc.ini file, but UID/PWD in the connection string. Strictly speaking, the ODBC defined attributes are UID/PWD and they are passed to the database for database authentication. As far as ODBC connection strings are concerned UID/PWD and TargetUser/TargetAuth are synonymous in ODBC-ODBC Bridge, but if specified in the odbc.ini file, you should alway use TargetUser/TargetAuth.

Now you know how to use oobping with a connection string, here are some examples of common problems you might see:

oobping -d "UID=dbuser;PWD=dbauth;TargetDSN=test;
Using Connection string :

IM002:1:0:[Easysoft ODBC (Client)]
Data source not found and no default driver specified
HY000:2:0:[Easysoft ODBC (Client)]
general error: Missing attribute(s): SERVERPORT

The initial diagnostic, IM002, is defined by ODBC, but as it rather vague, the ODBC-ODBC Bridge client added a secondary more helpful diagnostic. Here, the ODBC-ODBC Bridge connection attribute ServerPort was omitted, and so the ODBC-ODBC Bridge client did not know which server to connect to.

oobping -d "ServerPort=myserver:8888;UID=dbuser;PWD=dbauth;
Using Connection string :

28000:1:18456:[][Microsoft][ODBC SQL Server Driver][SQL Server]
Login failed for user 'dbuser'.

The above error comes from SQL Server and suggests the database password "dbauth" is not correct for the database user "dbuser". This error illustrates an important point with ODBC errors, namely, how to identify what component is reporting the error. You should examine the components in [], the one furthest right is the reporting component and as you move left through the components, you are moving closer to the ODBC-ODBC Bridge client.

For example, if you specified a TargetDSN that did not exist on the server machine, the Driver Manager on the remote machine would be the component reporting the error. The diagnostic (for Windows) would be:

IM002:1:0:[][Microsoft][ODBC Driver Manager]
Data source name not found and no default driver specified

The other important thing to note here is that oobping outputs any ODBC diagnostics as:

ODBC State : diagnostic sequence : ODBC native error: text

The native error code is specific to the component reporting the error. For example, in the SQL Server login failure above, you can look up native error code 18456 in the SQL Server documentation. This should tell you precisely in what circumstances this is reported.

Applies To

Knowledge Base Feedback

* Did this content help you?
* Please select one option based on your first choice:

(* Required Fields)