we deploy our application with a few Oracle dlls:
These dlls origin from the package "ODAC1120320Xcopy_32bit". That way there shouldn't be any need to install any Oracle client onto the client machines.
This works successfully on machines with Windows 7 as OS, regardless of whether any client is installed or not.
On computers with Windows XP though the behaviour is somehow undefined. We have one machine that can connect, on that machine the 10g client is installed.
Two other XP-machines with Oracle 8.1 client are not able to connect.
The Oracle server is 10g. Any hints for a solution are very welcome.
Oracle 8.1 client never was supported with ODP.NET. ODP.NET was first supported with Oracle 9.2 client. In any case, I would recommend using the 11.2 client with ODP.NET for any xcopy deployment, even against a 10g DB server.
BTW, I am neither approving or disapproving of using only a few select DLLs from the xcopy deployment package. I do want to caution that such a deployment is not tested by Oracle and is not officially supported. It's certainly possible that this setup works for your specific application. It's also possible it won't work for every application as some key functionality may be missing when some DLLs are excluded.
I expected that no matter whether a client is installed or not, the program would use the Oracle-binaries present in our application folder. This is why we're shipping the program with these dlls (from the 11.2 client xcopy version).
Nonetheless thanks for your opinion about delivering only part of the package ;-)
Now, what we have found being the resolution for not being able to connect on these clients is adding a system variable NLS_LANG with a value of "AMERICAN_AMERICA.WE8ISO8859P1". I have no clue how this related to the connection, but it definitely solves our problem.
But of course I'd still be interested, why this variable makes the connection failure disappear.
When Oracle designs and tests ODP.NET xcopy, it tests it under specific scenarios it was designed for, then documents those scenarios as supported. When users deviate from the supported scenarios, then odd behavior can ensue. I'm not going to call these bugs because ODP.NET was never designed to support alternative configuration setups.
I don't know the root cause of this error, but it's likely due to the removal of one of the files from the standard xcopy deployment or interplay between the 8i client and ODP.NET. My guess it's something to do with the latter.
I'm fully in agreement with everything Alex has posted, but since you mentioned setting NLS_LANG it makes me curious if on machines that are having issues if NLS_LANG is set incorrectly or to NA in the registry and this is being "picked up". This has been known to cause issues. It may not be relevant but perhaps worth verifying.
Mark, it looks as if the registry key HKLM\Software\Oracle\NLS_LANG is actually set to 'NA'. There's also a HKLM\Software\Oracle\KEY_blablahome\NLS_LANG entry which is set to something useful, but I guess (lacking any knowledge) that my very simplistic set of dlls doesn't 'see' that entry and then uses this 'NA'?
I don't know for sure that the NA entry is the cause of the issue. It might be possible to confirm this is the case by running the application on a machine with NA in the registry and using SysInternals Process Monitor to verify that the registry key with NA is read and used. I'm not sure if that is possible in your environment or worth the trouble.
As Tridus suggests, you might also consider trying the current beta of the managed provider as it reduces many of these sorts of problems.
I'll probably try this out next week (if I have the time to do so...), access to the machine is no problem.
Last time I glanced over the features of the managed provider, I found it had too many restrictions compared to the current ODP.NET provider, so it's not very likely that I'll try this one out (except I have too much spare time, which is even more unlikely ;-) )
Thanks a lot for all the comments to everybody and have a great weekend,