0

I usually access an ODBC connection through a CentOS server, and I'm trying to make the same connection locally on my Ubuntu Trusty laptop. So far as I can tell I've duplicated everything properly across the two machines, but I just can't get it to work. I had it working on an old laptop on the same network, so I think I can rule out firewalls/routing/etc.

When I try to test the connection I get:

me@T420:~/tmp$ iodbctest
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.52.0709.0909

Enter ODBC connect string (? shows list): ?

DSN                              | Driver                                  
------------------------------------------------------------------------------
NZSQL_SERVER                    | NetezzaSQL                              

Enter ODBC connect string (? shows list): NZSQL_SERVER
1: SQLDriverConnect = ������ (33) SQLSTATE=
1: ODBC_Connect = ������ (33) SQLSTATE=

my /etc/odbcinst.ini:

Have a nice day.patrickmc@patrickmc-ThinkPad-T420:~/tmp$ cat /etc/odbcinst.ini

[ODBC Drivers]
NetezzaSQL = Installed

[NetezzaSQL]
Description = Netezza ODBC Driver
Driver = /usr/local/nz/lib64/libnzodbc.so
Setup = /usr/local/nz/lib64/libnzodbc.so
FileUsage = 1
APILevel = 1
ConnectFunctions = YYN
DriverODBCVer = 03.50
UnicodeTranslationOption = utf8
CharacterTranslationOption = all
PreFetch = 256
Socket = 8192
LogPath = /tmp
DebugLogging = false

[ODBC]
Trace = No

and my /etc/odbc.ini:

;
;  odbc.ini
;
[ODBC Data Sources]
NZSQL_SERVER = NetezzaSQL


[NZSQL_SERVER]
Driver                = /usr/local/nz/lib64/libnzodbc.so
Description           = NetezzaSQL ODBC
Servername            = db.mynetwork.net
Port                  = 5480
Database              = db_1
Username              = db_user
Password              = db_pass
ReadOnly              = false
ShowSystemTables      = true
LegacySQLTables       = false
LoginTimeout          = 0
QueryTimeout          = 0
DateFormat            = 1
NumericAsChar         = false
SQLBitOneZero         = false
StripCRLF             = false
securityLevel         = preferredUnSecured
caCertFile            =

2 Answers 2

0

In your odbc.ini file, try changing this line:

Driver                = /usr/local/nz/lib64/libnzodbc.so

to this:

Driver                = NetezzaSQL

and see if that helps.

UPDATE:

I've never used iodbctest but a quick search indicates you may be specifying things incorrectly. Here's a snippet from this man page:

$ iodbctest
OpenLink ODBC Demonstration program
This program shows an interactive SQL processor

Enter ODBC connect string (? shows list): ?

DSN                              | Driver
-----------------------------------------------------------------
ora9                             | OpenLink Generic ODBC Driver
mysql                            | OpenLink Generic ODBC Driver
mysqllite                        | OpenLink Lite for MySQL
myodbc                           | MyODBC Driver
pgsql                            | OpenLink Generic ODBC Driver
tds                              | OpenLink Generic ODBC Driver

Enter ODBC connect string (? shows list): DSN=ora9;PWD=tiger
Driver: 05.20.0316 OpenLink Generic ODBC Driver (oplodbc.so)

SQL>

Looks like you need to specify the connect string, not just the DSN.

If that doesn't work, you should try these:

  • ls -l /usr/local/nz/lib64/libnzodbc.so to check the driver

  • Make sure you don't have a ~/.odbc.ini file or the ODBCINI var set

  • Try enabling DebugLogging (odbcinst.ini) and Trace / TraceFile (odbc.ini)

1
0

My hunch would be a library difference between the two machines.

Make sure you have only one ODBC driver manager (iODBC is what you've pictured; UnixODBC may also be installed), at least in the active LD_LIBRARY_PATH.

If that doesn't clear things up, then enabling ODBC Tracing and/or Driver Debug Logging is likely to bring more information to light.

It currently appears that the driver is returning an error in a different codepage than the driver manager expects, and so you get the several "unknown character" glyphs. We do see an error number -- 33 -- which corresponds to "Server and/or port attributes are empty" though they are set in the DSN, which suggests other possible environmental issues (Is $ODBCINI set? Does it point to /etc/odbc.ini?)....

If in doubt, perhaps take a look at the official Netezza docs!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .