The Oracle ODBC driver story
Mladen Gogala
the driver that doesn't work with unixODBC shipped with the Red Hat
distribution. I complained several times, never got any usable reply. The
ODBC driver for Linux is still pretty much useless, unless you compile
the newer version of unixODBC from the source. I will try getting it to
work with iODBC driver manager, an alternative to unixODBC, but this is
ridiculous. Even Red Hat acknowledged the problem but they are for some
reason refusing to ship the new version of the driver.
https://bugzilla.redhat.com/show_bug.cgi?id=475615
Oracle is stubbornly shipping a non-functional driver. This is getting
ridiculous. Don't they test their software? Maybe they have transcended
the spiritual state in which they cared about the quality of their
products and are quickly becoming a software equivalent of BP?
Mladen Gogala
> I will try getting it to
> work with iODBC driver manager, an alternative to unixODBC, but this is
> ridiculous.
That doesn't work either. Turns out that iODBC needs unixODBC as a lower
layer software to work properly. Basically, Oracle's ODBC driver on Linux
is completely useless unless the unixODBC is compiled from source.
John Hurley
# What is the story with Oracle ODBC driver? Oracle is stubbornly
shipping the driver that doesn't work with unixODBC shipped with the
Red Hat distribution. I complained several times, never got any usable
reply.
Ok I am really not understanding you here ( as usual probably eh? ).
AFAIK ODBC is a client technology and from a client machine you can
use ODBC calls against a remote Oracle database. I think mostly
Microsoft based software uses ODBC type calls ( not exactly sure ...
maybe things like Delphi ... PowerBuilder ... etc may also use that
stuff ).
So you are talking about making ODBC calls from a linux machine? What
kind of software does that exactly?
Sorry to be dense here but all the significant development efforts I
have seen over the last 10 years using the Oracle plumbing ( SQLNet
whatever you want to call it ) stack and/or OCI stuff ... I kind of
thought at this point the whole ODBC thing is a dying and/or outmoded
set of technology.
As far as "complaining several times" did you submit an SR and
especially an SR with some kind of test case that demonstrates a
repeatable failure?
Mladen Gogala
> So you are talking about making ODBC calls from a linux machine? What
> kind of software does that exactly?
>
> Sorry to be dense here but all the significant development efforts I
> have seen over the last 10 years using the Oracle plumbing ( SQLNet
> whatever you want to call it ) stack and/or OCI stuff ... I kind of
> thought at this point the whole ODBC thing is a dying and/or outmoded
> set of technology.
There are many pieces of software that use ODBC. Microsoft tried killing
it, in favor of ADO, but ODBC is still alive and well, even kicking a**.
That sort of debate would be off topic here.
>
> As far as "complaining several times" did you submit an SR and
> especially an SR with some kind of test case that demonstrates a
> repeatable failure?
To be very short: yes, I have. No resolution. The failure was
acknowledged, but never resolved. Had you taken the time to read my post,
you would have noticed a link to the Red Hat bug repository in which they
do acknowledge the bug but essentially say "go ask oracle why are they
shipping an incompatible driver". That is a verifiable fact. This is
precisely what I am doing: asking here why is Oracle shipping an unusable
driver?
The course of events that lead me to this is the following: I am looking
into an open source reporting engine called RLIB. This engine, as is the
case with many open source products, has the native links toward MySQL
and Postgres and uses ODBC links for all proprietary databases that they
cannot distribute themselves. Oracle, obviously, belongs to the latter
category. RLIB is an engine that can produce PDF and HTML reports,
running in batch. It manages pages, groups, headers, footers and all of
the other stuff that report engines do. It has Perl bindings, so it's
easy for me to write scripts that will be executed by cron and produce a
lot of pretty reports asked for by my management. RLIB doesn't have a
native Oracle connection, it requires ODBC. I wasted my entire evening
linking and configuring something that should have been packaged. The
product is described here: http://rlib.sicompos.com
See if you're smarter than me and can configure it to use Oracle without
ODBC.
joel garry
Why don't you ask Wim Coekaerts?
I suppose you could have rlib talk to something else with native links
that then talks to Oracle... or have a 10g intermediary... I'm
assuming you are on some 11g?
You mentioned compiling it from source? Isn't that the DIY way?
jg
--
@home.com is bogus.
"You're listening to RDB on Bluesville." - Heard on satellite radio.
Rockers Doing Blues.
Maxim Demenko
> On Fri, 11 Jun 2010 06:19:27 -0700, John Hurley wrote:
> product is described here: http://rlib.sicompos.com
Thank you for sharing, that looks interesting.
But back to odbc driver - if i understood it correctly from the
Bugzilla, the problem should disappear with newer (compared to shipped
with redhat) unixODBC version ? Then, why don't you try it this way?
Best regards
Maxim
Mladen Gogala
> Why don't you ask Wim Coekaerts?
I don't know the gentleman. I, of course, know of him but I don't want to
pester people that I've never met with personal emails.
>
> I suppose you could have rlib talk to something else with native links
> that then talks to Oracle... or have a 10g intermediary... I'm assuming
> you are on some 11g?
Actually, no, I am not. The database in question is 10.2.0.5. The same
problem happens with every version after 10.2.0.3. Version 10.2.0.3
doesn't work because of some unresolved symbol on Red Hat 5.
>
> You mentioned compiling it from source? Isn't that the DIY way?
Yes, it works that way, but I have to compile and configure the machine
manually and my boss is reluctant to allow me to do that on the
production box.
joel garry
> On Fri, 11 Jun 2010 09:56:56 -0700, joel garry wrote:
> > Why don't you ask Wim Coekaerts?
>
> I don't know the gentleman. I, of course, know of him but I don't want to
> pester people that I've never met with personal emails.
>
Fair enough. I imagine you aren't many degrees of freedom away from
him, though - I see him publicly on linkedin, for example (I despise
linkedin, but when I log in I see someone could introduce me to him,
should I care, and he does say he shares expertise - I would go out on
a limb and guess he wants to evangelize and make it work better). I
imagine doing things through support adds degrees.
>
>
> > I suppose you could have rlib talk to something else with native links
> > that then talks to Oracle... or have a 10g intermediary... I'm assuming
> > you are on some 11g?
>
> Actually, no, I am not. The database in question is 10.2.0.5. The same
> problem happens with every version after 10.2.0.3. Version 10.2.0.3
> doesn't work because of some unresolved symbol on Red Hat 5.
And here I've been complaining about stuff that doesn't work on hp-ux
because it has linux syntax, lol!
Oracle cross platform compatibility - makes all platforms red-headed
stepchildren.
>
>
>
> > You mentioned compiling it from source? Isn't that the DIY way?
>
> Yes, it works that way, but I have to compile and configure the machine
> manually and my boss is reluctant to allow me to do that on the
> production box.
Fair enough. Any manual operations are subject to non-repeatability.
I often even script things I only intend to do once.
jg
--
@home.com is bogus.
Data and death: http://www.msnbc.msn.com/id/37612199/ns/us_news-life/
Mladen Gogala
>> Yes, it works that way, but I have to compile and configure the machine
>> manually and my boss is reluctant to allow me to do that on the
>> production box.
>
> Fair enough. Any manual operations are subject to non-repeatability. I
> often even script things I only intend to do once.
That's the problem. Getting it to work is not the problem:
[mgogala@medo ~]$ isql ora11 scott tiger
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL> select * from dept;
+-------+---------------+--------------+
| DEPTNO| DNAME | LOC |
+-------+---------------+--------------+
| 10 | ACCOUNTING | NEW YORK |
| 20 | RESEARCH | DALLAS |
| 30 | SALES | CHICAGO |
| 40 | OPERATIONS | BOSTON |
+-------+---------------+--------------+
SQLRowCount returns -1
4 rows fetched
SQL>
[mgogala@medo ~]$ isql --version
unixODBC 2.3.0
[mgogala@medo ~]$
If you take a look at the version, you will see that unixODBC version is
2.3.0. Unfortunately, I had to link that myself, it wasn't in a
repository package. I am not asking how to get it working, I did that a
long time ago. The problem is the fact that Oracle is shipping the driver
which doesn't work with the official OS packages. I can't ask my system
administrator to install unixODBC-2.3.0-1-el5.386.rpm because there is no
such thing in any repository. The version in the repository is 2.2.11:
[mgogala@medo ~]$ rpm -qa|grep unixODBC
unixODBC-devel-2.2.11-7.1
unixODBC-2.2.11-7.1
[mgogala@medo ~]$
Oracle ODBC drivers shipped with the RDBMS, as well as the ones shipped
with the instant client(s) do not work with the version 2.2.11. Linking
things by myself means no maintenance, no automatic updates, no platform
specific configuration manuals and a lot of dependency upon the DBA. This
is what happens with unixODBC-2.2.11:
[mgogala@medo tmp]$ isql ora11 scott tiger
isql: symbol lookup error: /usr/lib/oracle/11.2/client/lib/
libsqora.so.11.1: undefined symbol: SQLGetPrivateProfileStringW
[mgogala@medo tmp]$ isql --version
unixODBC 2.2.11
This has been going on for more than a year. It is really, really, really
annoying. Even funnier thing is that Oracle does the same thing with OEL.
That doesn't work either. That, in particular, means that Oracle Corp. is
shipping a non-functional product. I wonder what will happen with
Solaris? If the QA remains the same as for Linux, the SUN might turn into
a black hole, and soon.
Tim X
Although not a great solution, something I've used in the past which
addresses some of your concerns is to create your own rpm package. It
has been a while since I've worked with RPMs, so I can't remember the
exact details, but it goes something like
1. Download the src rpm for the existing odbc ersion
2. Unpack the rpm and replace the source tree with the new version.
3. Update the version number in the spec file
4. Re-build the rpm and test
If it works, you can then use this rpm to install the updated driver on
all the systems where you need it.
The advantage of doing this is you get standard installs on all systems
and because it is an rpm update, you will be alerted to updates/new
versions that come form your vendor.
The downside is that your still going to be responsible for monitoring
for security issues and updating your rpm and re-installing when any
occur. However, I don't think there is any fix for this. Creating new
rpms from existing ones is at least quite easy.
Tim
--
tcross (at) rapttech dot com dot au