Invincible wrote:It was mentioned briefly in the chat Q&A part of GoToMeeting, they said the performance is pretty similar. Maybe a bit faster due to fewer context switches.
First great session yesterday, it's look like very promising, what I missed was a performance comparison between Managed and Unmanaged provider.
Tridus wrote:Yes I know that but Charts and Numbers are better :)
It was mentioned briefly in the chat Q&A part of GoToMeeting, they said the performance is pretty similar. Maybe a bit faster due to fewer context switches.
Did the precedence order change with the release version?
I have the following in my app.config
<setting name="TNS_ADMIN" value="C:\Code\OlbElerts\OTSElerts2010\OTSElerts\bin\Debug"/>
But, when I run my code and get a DataSourceEnum from the OracleFactory, it's referencing a tnsnames in an entirely different directory.
The order didn't change in production. We just eliminated the last two. The new order is below.
I believe your problem is that you are using the <settings> tag when you should be using the <dataSources> tag.
The following precedence order is followed to resolve the data source alias specified in the
Data Source attribute in the connection string.
<oracle.manageddataaccess.client>section in the .NET config file.
tnsnames.orafile at the location specified by
TNS_ADMINin the .NET config file.
tnsnames.orafile present in the same directory as the
I double-checked the current documentation and it still seems like the TNS_ADMIN is supposed to be within the <settings> tag.
The other thing is that, the tnsnames.ora that the OracleClientFactory appears to be reading is definitely not in the same directory as the exe. I modified the tnsnames.ora in my %ORACLE_HOME%/network/admin directory with a unique alias and that is what's being read and returned when I GetDataSources.
I eventually, completely renamed my %ORACLE_HOME%/network/admin/tnsnames.ora, and then it finally started readying the tnsnames in the executable directory. So something about the precedence order may not be documented correctly, especially if a full client is installed on the development machine.
You're right about the <settings> tag. I was thinking of the alias and descriptor setting, which is under the <dataSources> area.
Back to your original issue. The precedence order is correct. What happened was that your ODP.NET instance used the TNS_ADMIN defined in your machine.config. And that TNS_ADMIN pointed to the %ORACLE_HOME%/network/admin directory where the existing tnsnames.ora was found. Because anything in your .config files have precedence, the TNS file in your executable directory was never checked.
This was a new ODAC 12c install feature whereby the Oracle Universal installer copies over an existing tnsnames.ora to your new Home, then also references it in the machine.config. If you open your machine.config, you'll see the TNS_ADMIN entry. If you delete it, you can continue using the TNS file in your executable directory.