With the info provided, I suspect your classic ASP app is now picking up the DLLs in the new Oracle Home and trying to find the TNS entries in the new Home's tnsnames.ora file. That's what happens when the new Home bin directory gets added to the front of the Windows Path setting.
To resolve this, go to your Windows Path setting and move the new Oracle Home bin directory to later in the path after your 9i Home bin directory.
To get your new Home to work, copy over the tnsnames.ora file from 9i to the parallel location in the new Oracle Client Home. To ensure you don't run into any issues using ODP.NET and accidentally loading 9i DLLs, set the DllPath setting in your .NET config file to point to the new Oracle Home bin directory. That ensures you load DLLs from the new Home, not the 9i one.
An easier overall solution is to use the managed ODP.NET driver instead. It doesn't have any dependent DLLs that require setting a directory path location, which means it will never interfere with what your 9i Home tries to load from the Windows Path.
Thanks for the reply.
A couple of questions.
1. I uninstalled the latest oracle client to bring the server back online and everything seems to function fortunately except for i must now be missing oraoledb it seems. How does one go about getting this back so i can get this back up and running?
2. I am curious about this managed odp.net driver you mentioned. Can you explain a bit further to me how this works?
3. What I need to do on the development side to utilize the managed driver?
also, this is the current path after the uninstall. do you think this has anything to do with my oraoledb issue?
When I search the server i see the OraOLEDB.dll in c:\Oracle\ora9i\bin which is in my path. I wonder if that the install of that latest client messed up the ordering perhaps and this is causing my issue currently?
Also, isn't/wasn't the OraOLEDB.dll part of mdac or am i dreaming?
I got my oraoledb issue fixed by simpy re registering the dll by doing a regsvr32 c:\Oracle\ora9i\bin
This seemed to take care of it.
I am still interested in learning more on this managed driver? I am wondering if it is really just referencing a different dll and then utilizing the a similar connection string and migrating it over without installing a client or how this thing works specifically?
OraOLEDB is a COM component. Only one instance of a COM component can be active and registered at one time. When you installed the new Oracle Client, it registered a OraOLEDB version and inactivated the older version. When you de-installed the new version, OLE DB was un-registered, but the de-installer does not know you would like to re-register your 9i OLE DB version. You have to manually re-do this yourself.
Managed ODP.NET is a 100% managed driver. It does not require dependent Oracle Client files that the unmanaged ODP.NET driver does. The ODP.NET doc has some more description on the feature. Here's an article and hands-on tutorial on how to use it:
OraOLEDB only comes with Oracle software. It does not come with MDAC, though MDAC may have its own version of Oracle OLE DB.
Thanks for the explanation and the links.
I have been running through the links slowly here. In the app the way the connection is occurring is via a connection string within the app. I simply tried changing the reference over to the managed driver and change the references to oracle dataaccess over to the managed and all works locally still. When i published however to the server that does not have the client installed I am getting the following error:
ORA-12154: TNS:could not resolve the connect identifier specified
I am guessing the client software must be doing something in this case? Any idea how to resolve this?
I don't understand how the client (which seems to me to be sort of the middle man between the .net app and the database) handles the connection to the dbase as there must be something occurring here.
Alex, Thanks again for the assistance.
I am still running into the ORA-12154: TNS:could not resolve the connect identifier specified error.
I found your video explaining similar steps you reference in the tutorial and that is my current method I am attempting to follow.
Everything seems to function on the development side. It is when I deploy to the server that I am getting the error. I have place the tnsnames.ora file in the dir you mention as well. When I deploy to the server I have also attempted to place the tnsnames.ora file in the bin folder to see if that would fix it but i get the same error. Seems like that is the problem that it doesn't know how to resolve the datasource name (orcel in your examples) perhaps? Any ideas what I am missing?
I should note that the name i am using as a datasource i have validated that is in the tnsnaes.ora file as well. I have seen a few posts making sure to double check this which I have.
Ed Stevens has one of the best explanation series of various connectivity issues you might encounter that I have seen.
Here's a link to a part of that series that covers the ORA-12154 error:
Take a look at that and hopefully it will be enough to get the issue resolved for you.
The tutorial I linked to (ODP.NET, Managed Driver Introduction) has a section in the middle of it that describes the different ways to set up your connect identifier info so that managed ODP.NET can find it. The set up is different from the regular Oracle Client.
Mark, thanks for the response and the link. I read through it and I know that my tnsnames.ora functions as i can login via sql plus without issue and oracle has been running using it for some time on this box for the classic asp app that currently resides on that machine.
For me, the client install piece and how this knows where to look to establish the connection is a bit of a blackbox mystery to me.
Alex, thanks for the link. Funny, I have been running through this throughout the day. The method I have been following is that titled:
Connect using the Local Naming Parameters file, tnsnames.ora:
but still get the same error for some odd reason.
One other thing, do you guys know when I publish do i need to include the tnsnames.ora in the bin folder? I am assuming i do?
maybe this has something to do with it too. My solution has 3 projects, one for the dbase layer that contains all interaction with the dbase, one for the wcf layer and the last for the UI. do you think have them. currently the UI is not using he wcf layer at this point so there is a reference pointed from the UI layer to the dbase. maybe I should be pursuing this option instead?
Connect using the .NET Application Configuration File:
I am not able to get the "Connect using the .NET application configuration file" to work for some reason. I think it may have to do with that i am not sure where in my code i reference the alias we setup in the app.config. I set it as part of the datasource one uses for the connection string but when I did this i get the 12154 error again.
One further thing here. My local machine has a reference to TNS_Admin and points to a network location. I am assuming that is how i am getting the connection using local naming parameter to work perhaps.
The server where I am trying to publish doesnot have tns_admin setup. do you think i need to set that up perhaps? If so, will this mess any of the existing setup up do you think?