unixODBC giving error while running isql [Vertica]

Question

Hi I have configured the DSN settings for vertica in Ubuntu 10.10 32 bit version machine. The settings are all fine and I have cross checked them.

Here is my odbc.ini file:

 [VerticaDSN]
  Description = VerticaDSN ODBC driver
  Driver = /opt/vertica/lib/libverticaodbc_unixodbc.so
  Servername = myservername
  Database = mydbname
  Port = 5433
  UserName = myuname
  Password = *******
  Locale = en_US

Similarly I have a odbcinst.ini file.

when I run the command: isql -v VerticaDSN I get the following error:

 [S1000][unixODBC][DSI] The error message NoSQLGetPrivateProfileString could not be found    in the en-US locale. Check that /en-US/ODBCMessages.xml exists.
[ISQL]ERROR: Could not SQLConnect.

I have tried everything but I am not able to decipher this error.

Any help will be greatly appreciated.

Answer 1

You may be missing the Driver configuration section. Edit or create the file /etc/vertica.ini with the following content:

[Driver]
DriverManagerEncoding=UTF-16
ODBCInstLib=/usr/lib64/libodbcinst.so
ErrorMessagesPath=/opt/vertica/lib64
LogLevel=4
LogPath=/tmp

More information can be found in the Vertica Programmer's Guide in the section "Location of the Additional Driver Settings".

Answer 2

Searching the Internet about this issue I have seen that tons of people have been able to connect with tsql but not with isql or osql (which uses isql). I have had this same issue and have been researching and testing for the last week trying to figure out what the issue is. The thing is everyone has approached it from the angle of the ODBC when what I think it is is something to do with the Windows server or sql server config. I checked the logs on the windows server and see that the machine running the ODBC has hit it and tried to log in repeatedly but has not been able to. In the event viewer there are tons of entries showing the same thing, that the client machine is trying to log into SQL Server but is being refused by the host machine. That is the angle I am focusing on now and where I think the problem lies. If I get this resolved I will post again letting everyone know what I found out about this problem.

Thanks,

Answer 3

From the error we can see you are using unixODBC and I presume "DSI" is what Vertica calls itself as ODBC error text is formatted with entries in [] from left to right as the path though the different components (see Example diagnostic messages).

I presume that message should be "No SQLGetPrivateprofileString could be found". SQLGetPrivateProfileString is an API provided by the ODBC driver manager to read entries from the odbc.ini file. I believe it should be found in the libodbcinst.so shared object however, some distributions (e.g., Ubuntu/Debian) strip symbols from shared objects so it is difficult to verify this.

In your DSN, the driver is the file "/opt/vertica/lib/libverticaodbc_unixodbc.so". Although it is more usual to name the driver in the odbc.ini and add an entry to the odbcinst.ini file your DSN looks ok. e.g.:

/etc/odbcinst.ini:
[Easysoft ODBC-SQL Server SSL]
Driver=/usr/local/easysoft/sqlserver/lib/libessqlsrv.so
Setup=/usr/local/easysoft/sqlserver/lib/libessqlsrvS.so
Threading=0
FileUsage=1
DontDLClose=1

/etc/odbc.ini:
[SQLSERVER_SAMPLE_SSL]
Driver=Easysoft ODBC-SQL Server SSL
Description=Easysoft SQL Server ODBC driver
.
.

See in the above example doing it this way allows you to specify additional options associated with the driver like Threading (and a quick search on the net suggests Vertica can use Threading=1 which is less restrictive if using a threaded program) and DontDLClose. However, as I said things should work as you have them now.

Now the next bit depends on your platform and I didn't notice if you specified one. You need to examine that shared object for your ODBC Driver and see what it depends on. On Linux you do something like this:

$ ldd /usr/local/easysoft/sqlserver/lib/libessqlsrv.so
    linux-gate.so.1 =>  (0xb76ff000)
    libodbcinst.so.1 => /usr/lib/libodbcinst.so.1 (0xb75fe000)
    libesextra_r.so => /usr/local/easysoft/lib/libesextra_r.so (0xb75fb000)
    libessupp_r.so => /usr/local/easysoft/lib/libessupp_r.so (0xb75de000)
    libeslicshr_r.so => /usr/local/easysoft/lib/libeslicshr_r.so (0xb75cd000)
    libestdscrypt.so => /usr/local/easysoft/lib/libestdscrypt.so (0xb75c8000)
    libm.so.6 => /lib/libm.so.6 (0xb75a2000)
    libc.so.6 => /lib/libc.so.6 (0xb7445000)
    libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb743b000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7421000)
    /lib/ld-linux.so.2 (0xb7700000)
    libdl.so.2 => /lib/libdl.so.2 (0xb741d000)

which shows this ODBC driver depends on libodbcinst.so.1 and the dynamic linker found it. I imagine your Vertica driver should look similar in this respect although it is possible the Vertica driver dynamically loads this shared object itself on first being loaded. Either way, it looks like the Vertica driver cannot find the symbol SQLGetPrivateProfileString which is in libodbcinst.so so make sure a) you have libodbcinst.so b) your dynamic linker knows about it (how this is done depends on your platform - on Linux see /etc/ld.so.conf and LD_LIBRARY_PATH and the man page for ld.so) c) run ldd (or equivalent) on it to make there are no missing dependencies.

The vertica.ini file is probably where the driver stores driver specific configuration - some drivers do this. If the format of this file is like the odbc ones above it may also use SQLGetPrivateProfileString for this file as you can tell that ODBC API which file to use.

Beyond this I've no more ideas other than contact vertica.

Answer 4

Arun -- if you can let me know the version of the database and the version of the driver I can get you more detail. Also, I might try posting this on the official Vertica community forum.

http://my.vertica.com/forums/forum/application-and-tools-area/client-drivers/

If I had to guess what your issue is I think it might be related to this post :

http://my.vertica.com/forums/topic/odbc-on-linux-issue/

... specifically the comment at the end about 'ODBCInstLib'.