Download ODBC Drivers for Oracle, SQL Server, Salesforce, MongoDB, Access, Derby, InterBase & DB2.

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

First, use oobping to test the connection to the Easysoft ODBC-ODBC Bridge server and to test authentication. You'll then have the machine name of an ODBC-ODBC Bridge server and the port the server is listening on. You'll also have a valid operating system user name and password. Now check the connection to the remote ODBC data source.

There are two ways to do this. The simplest way is to add a local data source to your odbc.ini file and then specify the data source in the -d argument as DSN=dsnname. This method checks the local ODBC-ODBC Bridge client data source. An alternative method is to specify all the connection attributes in the -d argument.

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 ODBC data source on myserver. (This is the ODBC-ODBC Bridge client attribute TargetDSN.) Note that the TargetDSN value must be a remote system data source, you can't access user data sources. If the database also needs login information, specify the database user name and password with TargetUser and TargetAuth.

Here's an example ODBC-ODBC Bridge DSN in odbc.ini:

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

To test this DSN with oobping, use:

oobping -d "DSN=mydsn;"
Using Connection string :
DSN=mydsn;
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.
OutConnectionString:
DSN=mydsn;UID=dbusername;PWD=dbpassword;
TARGETDSN=mysystemdsn;LOGONUSER=me;LOGONAUTH=mypassword;

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

This uses oobping to pass the ODBC connection string DSN=mydsn to the ODBC-ODBC Bridge client. 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 odbc.ini to get additional attributes. The client found ServerPort, LogonUser, LogonAuth, TargetDSN, TargetUser, and TargetAuth. The client then connects to the server on myserver port 8888, logs in with the LogonUser and LogonAuth. Then finally connects remote ODBC data source mysystemdsn. In the example, the data source points to SQL Server. There are some informational diagnostics saying the language is us_english and the database is pubs. (Not all databases return such messages.) The OutConnectionString is a string returned by the ODBC-ODBC Bridge client that you can use to connect to this data source again. The final messages show the database, DBMS name, driver name, and driver version. (The driver is the ODBC-ODBC Bridge client.)

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;
TARGETDSN=mysystemdsn;
LOGONUSER=me;LOGONAUTH=mypassword;"

would produce the same result as above.

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

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

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

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;
TargetDSN=test;LogonUser=me;LogonAuth=mypassword"
Using Connection string :
ServerPort=myserver:8888;UID=dbuser;PWD=dbauth;TargetDSN=test;
LogonUser=me;LogonAuth=mypassword

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.