Re: Client ignores sqlnet.ora file...

Thanks for the pointer -- I looked in the registry and on both the working and the non working clients and TNS_ADMIN wasn't in either registry. On the problem machine, I put a TNS_ADMIN key everywhere ORACLE_HOME was found per your instructions below and the problem was solved! Thanks again.

--Darrin

In article <933882605.10787.0.pluto.d4ee154e_at_news.demon.nl>,   "Sybrand Bakker" <postmaster_at_sybrandb.nospam.demon.nl> wrote:
> Use regedit and try to find the TNS_ADMIN key (it should be in
> HKLM\software\oracle)
> Your IT department may have set it to a networked drive.
> If the registry key is not there, or if it's there and it is wrong,
set it
> to c:\orant\network\admin
>
> Hth,
>
> Sybrand Bakker, Oracle DBA
>
> <signal7_at_my-deja.com> wrote in message
news:7ockhm$mls$1_at_nnrp1.deja.com...
> >
> >
> > 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.
>
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Fri Aug 06 1999 - 09:28:12 CDT