Supposing everything compiles and installs without trouble, how do you know if your ODBC setup works? Or, if you know it doesn't, what then?
First, try to connect with tsql. If you're intending to use freetds.conf
, exercise it with
tsql -S servername
. If not, use
TDSVER=auto tsql -H hostname
-p port
If tsql works and isql doesn't, you've isolated the problem to the ODBC setup. FreeTDS™ might have some interoperability problems, but mere connection to the database isn't one of them! If tsql
doesn't work, turn on logging with TDSDUMP
. The log will tell you what TCP/IP name (and address) FreeTDS™ is attempting to connect to, and what version of the TDS protocol it's using.
iODBC
comes with a sample command line query program called odbctest, located in the iodbc/samples
directory.
Using this program you can get a listing of DSNs, connect, and issue queries.
Tip | |
---|---|
For debugging purposes, you may wish to link a program such as odbctest directly to FreeTDS™ instead of to the driver manager.
[15]
To do so, compile and install the Example 4.7. Compile
|
Try isql -v dsn
username
password
, and have a look at the log. See if the right address and TDS version are being used. Adjust to taste.
The osql utility is a Bourne shell script that checks your ODBC configuration.
If it approves, it invokes the unixODBC
isql utility.
Cf. man osql for details on its use.
Example 4.8. Use osql to test the ODBC setup.
$
osql -S machine -U mr_ed -P hayseed
looking for odbc.ini and odbcinst.ini in /usr/local/etc reading "/usr/home/mr_ed/.odbc.ini" [machine] found in "/usr/home/mr_ed/.odbc.ini" found this section: [machine] Database = testdb Servername = machine Trace = Yes TraceFile = /tmp/unixodbc.trace looking for driver for DSN [machine] no driver mentioned for [machine] in .odbc.ini looking for driver for DSN [default] driver "FreeTDS" found for [default] in .odbc.ini found driver named "FreeTDS" FreeTDS is not a readable file looking for entry named [FreeTDS] in /usr/local/etc/odbcinst.ini driver "/usr/local/lib/libtdsodbc.so" found for [FreeTDS] in odbcinst.ini /usr/local/lib/libtdsodbc.so is a readable file Using ODBC-Combined strategy FreeTDS servername is "machine" (from /usr/home/mr_ed/.odbc.ini) looking for [machine] in /usr/home/mr_ed/.freetds.conf "/usr/home/mr_ed/.freetds.conf" is a readable file found this section: [machine] host = machine.example.com port = 2500 tds version = 7.1 machine.example.com has address 10.82.32.177 DSN: machine Driver: /usr/local/lib/libtdsodbc.so Server's hostname: machine.example.com Address: 10.82.32.177 Attempting connection as mr_ed ... + exec isql machine mr_ed hayseed -v +---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL>
The reader is here advised that the isql that comes with many versions of unixODBC
will truncate text and surprise in other ways without warning.
If it behaves strangely, try FreeTDS™'s bsqlodbc before you decide you've found a FreeTDS™ bug.
[15] Why? Once the program is started in the debugger, the driver entry points become viable breakpoints.
Because the DM loads the driver dynamically with dlopen(3)
, no driver addresses even exist until the runtime linker loads it.
[16] When linking directly to FreeTDS™ you still need the Driver Manager's header files.