Interesting sqlnet observation

Question

While doing a setup for a blog article I'm working on, I noticed something very interesting with tns locating its config files.
The whole purpose of the exercise was to demonstrate the interaction of ORACLE_HOME and TNS_PING, in both the registry and as and environment variable on a Windows client.
Here's the setup. I have a stock Oracle 10.2.0.4 client installation on XP-Pro. OHOME is C:\oracle\product\10.2.0\client_1. To prepare for the exercise I create three more directories:
C:\oracle\product\10.2.0\client_2\network\admin
c:\oranet\admin_1
c:\oranet\admin_2each directory got identical copies of both sqlnet.ora and tnsnames.ora
The plan was to add ORACLE_HOME as an environment variable, add TNS_ADMIN to the registry, then TNS_ADMIN to the environment, with each setting pointing to a different directory of the 4 available. After each change, execute tnsping and observe what it reports as "Used parameter files:"
Here's my results as I progressed
Only setting is the real OHOME in the registry - used OHOME\network\admin
Within the cmd session, set ORACLE_HOME=C:\oracle\product\10.2.0\client_2 - tnsping used sqlnet.ora in that directory
add TNS_ADMIN=c:\oranet\admin_1 to the registry- tnsping used that directory
add TNS_ADMIN=c:\oranet\admin_2 to the session environment - tnsping used that directory
To this point, each change was stacked on top of the previous, and each result was what I expected at that point (though as I write this and think of what came later, I'm questioning that. More later)
Next, with all four indicators in place (OHOME in registry and environment, TNS_ADMIN in registry and environment) I started deleting sqlnet.ora from the directories in reverse order, to see where it would go if it couldn't find it in the "preferred" location.
First step of this phase was to delete sqlnet.ora from the directory indicated by TNS_ADMIN as the environment variable. tnsping found sqlnet.ora in the directory indicated by ORACLE_HOME in the environment. So far, so good.
Next I deleted THAT sqlnet.ora (%ORACLE_HOME%\network\admin\sqlnet.ora) and repeated tnsping. Here's where things got strange. The "Used parameter files:" was followed by just a blank line, followed by tns information, and a failed ping due to a TNS-12557: TNS:protocol adapter not loadable. But it DID show the address resolution for mysid.
So the big mystery is if it gave up looking for a sqlnet.ora file (apparently didn't revert to the indicators in the registry) then where did it find a tnsnames.ora file? Why didn't it fail over to the registry for an indication on where to find sqlnet.ora? My first impulse was to set sqlnet client tracing on to get a closer look, but of course with it not finding a sqlnet.ora file, there's no place to turn the tracing on ..
Another question (that I didn't think about on my initial test, but alluded to above) was that at the second step, I added the env variable ORACLE_HOME, and that took precedence over the registry. But when I then added TNS_ADMIN to the registry, THAT took precedence over the session environment. That countered my thought that any session level setting would take precedence over any registry setting.

Answer 1

sb92075 wrote:
You know I'd prefer not to, but this exercise is designed specifically to explore the influences in a Windows client.OK, I'll spell it out.
Oh, good grief! I thought you knew me better than that ... My comment was based on the assumption that you had seen enough of my postings to know I have healthy dislike of Windows.
I don't have Oracle on Windows so I can't test myself.
Does Oracle on Windows use tnsnames.ora or .tnsnames.ora file if it exists in OS User's "HOME" folder?I never thought about that. Since the dot-name construct is specifically a *nix convention it never occured to me to try it on Windows.  I'll add it to this morning's tests.