Fun with unixODBC on Fedora
Date: Mon, 16 Jan 2012 21:12:45 +0000 (UTC)
Message-ID: <pan.2012.01.16.21.12.45_at_gmail.com>
I wanted to test LibreOffice report wizard on Oracle and I chose ODBC to connect to Oracle. I have done so many times, I installed configuration files and it doesn't work. Fedora is a Linux distro appropriately starting with the letter "F", so I knew what to expect, things didn't work. The first step is to set up trace in the /etc/odbcinst.ini like this:
[ODBC]
TraceFile = /tmp/sql.log Trace = Yes ForceTrace = Yes Pooling = No
The trace file produced the following:
[ODBC][4912][1326747189.405674][SQLAllocHandle.c][482]
Exit:[SQL_SUCCESS]
Output Handle = 0x990e698
[ODBC][4912][1326747189.405743][SQLConnect.c][3614]
Entry:
Connection = 0x990e698
Server Name = [local][length = 5
(SQL_NTS)]
User Name = [scott][length = 5
(SQL_NTS)]
Authentication = [*****][length = 5 (SQL_NTS)]
UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE
'UCS-2LE'
[ODBC][4912][1326747189.410219][SQLConnect.c][1063]Can't open lib '/usr/
lib/oracle/11.2/client/lib/libsqora.so.11.1' : file not found
Instant client was installed, I checked and re-checked. The file mentioned was there:
[mgogala_at_medo ~]$ ls -l /usr/lib/oracle/11.2/client/lib/libsqora.so.11.1
-rwxr-xr-x 1 root root 781565 Sep 18 19:12 /usr/lib/oracle/11.2/client/
lib/libsqora.so.11.1
So, what the heck is the problem? I went one step further and performed the following command:
strace -e trace=file isql local scott tiger
It turns out that ODBC was complaining about the libodbcinst.so.1 library:
stat64("/usr/lib/tls/sse2", 0xbf980a3c) = -1 ENOENT (No such file or
directory)
open("/usr/lib/tls/libodbcinst.so.1", O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64("/usr/lib/tls", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
open("/usr/lib/i686/sse2/libodbcinst.so.1", O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64("/usr/lib/i686/sse2", 0xbf980a3c) = -1 ENOENT (No such file or
directory)
open("/usr/lib/i686/libodbcinst.so.1", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/usr/lib/i686", 0xbf980a3c) = -1 ENOENT (No such file or
directory)
open("/usr/lib/sse2/libodbcinst.so.1", O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64("/usr/lib/sse2", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
open("/usr/lib/libodbcinst.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
There wasn't one on the system, so I thought I might have missed something during the installation. I searched the software repositories, using the following command:
yum search /usr/lib/libodbcinst.so.1
Loaded plugins: fastestmirror, langpacks, presto, priorities, protectbase,
: refresh-packagekit
Loading mirror speeds from cached hostfile
- fedora: mirror.symnds.com
- rpmfusion-free: mirror.us.leaseweb.net
- rpmfusion-free-updates: mirror.us.leaseweb.net
- rpmfusion-nonfree: mirror.us.leaseweb.net
- rpmfusion-nonfree-updates: mirror.us.leaseweb.net
- updates: mirror.symnds.com 0 packages excluded due to repository protections Warning: No matches found for: /usr/lib/libodbcinst.so.1
Nothing was found. Hmmmm, that's strange. Let's see what do we have on the system:
[root_at_medo lib]# ls /usr/lib/libodbcinst.so*
/usr/lib/libodbcinst.so /usr/lib/libodbcinst.so.2.0.0
/usr/lib/libodbcinst.so.2
Eventually, the oldest trick in the book made things right: ln -s /usr/lib/libodbcinst.so.2.0.0 /usr/lib/libodbcinst.so.1
[mgogala_at_medo ~]$ isql local scott tiger
+---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+SQL> select * from emp;
+-------+-----------+----------+-------+--------------------+---------- +----------+-------+ | EMPNO | ENAME | JOB | MGR | HIREDATE | SAL | COMM | DEPTNO| +-------+-----------+----------+-------+--------------------+---------- +----------+-------+ | 7369 | SMITH | CLERK | 7902 | 1980-12-17 00:00:00| 800 | | 20 | | 7499 | ALLEN | SALESMAN | 7698 | 1981-02-20 00:00:00| 1600 | 300 | 30 | | 7521 | WARD | SALESMAN | 7698 | 1981-02-22 00:00:00| 1250 | 500 | 30 | | 7566 | JONES | MANAGER | 7839 | 1981-04-02 00:00:00| 2975 | | 20 | | 7654 | MARTIN | SALESMAN | 7698 | 1981-09-28 00:00:00| 1250 | 1400 | 30 | | 7698 | BLAKE | MANAGER | 7839 | 1981-05-01 00:00:00| 2850 | | 30 | | 7782 | CLARK | MANAGER | 7839 | 1981-06-09 00:00:00| 2450 | | 10 | | 7788 | SCOTT | ANALYST | 7566 | 1987-04-19 00:00:00| 3000 | | 20 | | 7839 | KING | PRESIDENT| | 1981-11-17 00:00:00| 5000 | | 10 | | 7844 | TURNER | SALESMAN | 7698 | 1981-09-08 00:00:00| 1500 | 0 | 30 | | 7876 | ADAMS | CLERK | 7788 | 1987-05-23 00:00:00| 1100 | | 20 | | 7900 | JAMES | CLERK | 7698 | 1981-12-03 00:00:00| 950 | | 30 | | 7902 | FORD | ANALYST | 7566 | 1981-12-03 00:00:00| 3000 | | 20 | | 7934 | MILLER | CLERK | 7782 | 1982-01-23 00:00:00| 1300 | | 10 | +-------+-----------+----------+-------+--------------------+----------+----------+-------+
SQLRowCount returns -1
14 rows fetched
SQL> Now I know why the name of this particular Linux distro starts with the letter "F". If anyone wants to play with ODBC, you should add symlink as above. I hope that I have saved a few minutes to someone. I love well tested software which starts flawlessly from scratch, but it's Linux what keeps me on my toes and keeps me sharp and vigilant. I hope that UnixODBC developers will not come up with an idea for a new and improved library, incompatible with the original anytime soon.
-- http://mgogala.byethost5.comReceived on Mon Jan 16 2012 - 15:12:45 CST