obscure tnsnames.ora problem,

[Guest_imported]

Hi all,

We have this weird problem regarding tnsnames.ora that I cant quite figure
out. OK, here's the background:

Networked PCs with shared drive H:
Application installed on C: drive
tnsnames.ora within C: drive in application directory.

When running application, everything works fine within until ONE specific
procedure is done by ONE of the tools within the app.
Now, this procedure does NOTHING abnormal, all it does is write data from
DB to a file, NOTHING ELSE...


Once this particular procedure is run, when trying to access the other tools
within the app causes a "TNS cannot resolve... " blah blah error !!

Looking at the code, it IS in fact at each point in code that tries to open
and ADO connection to the database.

Why IN THE WORLD would the thing work UNTIL that procedure runs, and then
NOT ??

What we found was that the H: shared drive had a "tns_admin" default oracle
directory, and when we removed ALL existing tnsnames.ora files from C: and
moved to the H: drive, everything worked FINE...!

So, the problem is fixed, BUT, i'd love to know why it acted in this way....

any ideas ???

 

[RickSpr]

Maybe when you wrote data to the file, you changed the current directory (with ChDir). Whenever (or at least usually) a program opens a file without specifying a full path name, Windows searches the current directory first. So if there's a tnsnames.ora in the directory you changed to, from then on that's the one that will be used.

One way to prevent this problem would be to save the current directory before the ChDir, and then return to that directory after writing the file. Another would be to avoid the ChDir at all, specifying a full path name for the file you're writing to. Rick Sprague