So I had the idea of installing the Oracle 32 bit "Instant Client" on the PC for the exclusive use of this old app.
Unfortunately I cannot get the CTD to work with the Oracle "Instant Client" in any configuration! Just to remove all variables I tried it on a fresh Windows XP install and connected using SQLTalk. If I use the full Oracle 11g (32 bit) client then SQLTalk connects fine. If I use the Oracle 11g Instant Client it does not - I get the error "SQL Error 21019". The instant client does connect using Oracle's own SQL*Plus so it is definitely breaking down somewhere between Oracle & CTD.
Has anyone any experience with connecting older CTD/SQL Windows app to Oracle using the Instant Client?
(or, even better, connecting older CTD/SQL Windows app. to Oracle using the full 64 bit Oracle 11g client? so I wouldn't have to mess around with this Instant Client option!!)
Did you correctly set the TNS_ADMIN environment variable? The Instant Client relies on this (i believe so), it has to point to the directory where the tnsname.ora file resides.
And, of course, the PATH variable has to include the "bin" directory of the Instant Client before any other Oracle related stuff.
On an Oracle DBA's recommendation several years ago, we always use the full client - not the instant one.
I thought this was so obscure that nobody would respond, so thanks for taking the time.
Your info. that TD42 works is valuable. I could consider upgrading this app to a later version of TD but not the 5.x versions that would require months of rewrite.
p.s. As for the TNS_ADMIN var, I did set it on the first system I tried but not on the fresh XP install, where I just put TNSNAMES.ORA in the Instant Client directory. SQL*Plus works so it seems OK like that.
You could consider virtualizing the application to keep it separate/isolated from everything else.
We use Novell's ZenWorks Application Virtualization product, but you could use VMWare's product or something from other competitors.
We create a "virtualized package" that included the TD runtime and Oracle client, plus a TD-build "launcher" executable for launching exe's sitting outside of the "virtualized package." This allows us to update our client's applications without having to worry about the TD runtime and Oracle client. When we decide to upgrade TD and/or the Oracle client, we just have to drop a new version of the "virtualized package" on clients' computers.
It's a very beneficial approach to deployment. It means "zero-install" on client computers, no worries about any conflicts between our applications and other applications, and no worries about security settings on client computers because our applications run in a "sandbox". Very cool.
Who is online
Users browsing this forum: [Ccbot] and 0 guests