Client ignores sqlnet.ora file...

Before anyone responds to this, please read fully --

I have an NT client that the IT dept. configured with sqlnet 2.x before I got it in my department. I uninstalled sqlnet and installed sqlnet 2.3.3.0.0(I'm not sure what the exact older version was, but it was an upgrade, anyway). After installation, I do the usual things:   Install Applications
  Install Applicaton ODBC Driver
  Use SQL*Net EasyConfig to setup tnsnames.ora

After doing all of this, the application responds with an error message - ORA-12154 Cannot resolve service name. I did a search on the web and all anyone would say is that there's a syntax error somewhere in tnsnames.ora, BUT this is NOT the case. I replaced the entire c:\orant directory tree from a working client and it still didn't work, same result, etc.

So, I then went on a search an destroy mission through the system32 directory and found at least 7 dll's out of place: core35.dll, core35o.dll, nlsrtl32.dll, ociw32.dll, ora73.dll, ora7nt.dll, and orant71.dll. All of these files are supposed to load from c:\orant\bin, but were getting loaded from c:\winnt\system32 instead. I moved them out of the way so the proper files would be loaded, but still no luck getting the application to work.

Finally after much reading and banging my head on this for the last 2 days, I decided to enable tracing/logging in the sqlnet.ora file. Guess what -- no matter what changes I make to this file, it doesn't make *ANY* difference - it's as though it doesn't exist. No trace files are created, no log files are created, and sqlnet is trying to lookup/connect with oranamesrv0 via tcp/ip. Since my network doesn't use the Oracle names server component, this fails and I get the catch-all message ORA-12154!

Ok -- I've checked to see that ORACLE_HOME is set right and I've scoured the system looking for duplicate sqlnet.ora files without finding any. Do any of the other guru's out there have any ideas what to look at? If worse comes to worse, I will setup the the Oracle Names Server with DDO(dynamic discovery option) this weekend, but it would be far more convenient if I didn't have to do this just for one lousy machine.

Thanks
--Darrin

ps -- re-installing NT isn't really a good option as it will incur a

      time/materials charge from the IT department to restore the
      system to a useable state.

pps -- the sqlnet.ora and the tnsnames.ora file do reside in
       c:\orant\network\admin just like it does on the rest of
       the machines.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Thu Aug 05 1999 - 13:18:15 CDT