Re: Client ignores sqlnet.ora file...

You might want to check oracle.ini under your c:/winnt compare yours and the working client's(if you have one)

Under dos prompt do: tnsping <<sid>> on both clients, see what happens. When you do this, it will tell you which host, which port are connect to.

Hope this will help.

Thanks, Kurt.

Ps. I just installed Oracle products(SQL*Plus, SQL*Net, Databrower...) on 2 NT work stations for my users, shared the same frustration.

In article <7ockhm$mls$1_at_nnrp1.deja.com>,   signal7_at_my-deja.com wrote:
>
>
> 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 Thu Aug 05 1999 - 15:15:49 CDT