0

After spending several days reading threads here and troubleshooting numerous messages regarding ODP.Net errors between my development machine and production, I want to run my take aways by the experts here to make sure a) I am correct in my assumptions, and b) there isn't a better way of solving this in the future.

My basic take away is that I should always start by looking in the GAC of my ultimate destination server to identify the version of the Oracle.DataAccessClient.dll. Then I should make sure that the version of the DLL I add as a reference in VS matches what is on the final destination machine. I'm not totally sure why I need to match what is in the GAC since I'm copying the dll to the bin directory anyway, but that's not really my question.

So what happens when your development, staging/testing and production environments don't have exactly the save version of the DLL? Based on some threads Deploying and Configuring ODP, it seems like I might be able to just copy the instant client files directly into my applications bin directory and not worry about what is already on any of the machines. Is that correct?

Any other thoughts or suggestions? Thank you.

Community
  • 1
  • 1
Trebor
  • 686
  • 2
  • 9
  • 33
  • What happens is to light a fire under IT and have them get the environments matched up. Oracle is *special* in the sense that the client needs both managed and unmanaged dll's to be syncronized. So you can't just deploy Oracle.DataAccessClient.dll. But hey, PL/SQL is a 3GL. You can write your whole app with it! Do I sound bitter? – Keith Payne Jan 07 '14 at 20:24
  • I can't really blame the IT department here. Part of the afore mentioned systems are my own and support multiple client development environments. For the work I've done in the past, the Oracle client version has not been that big of an issue. – Trebor Jan 07 '14 at 21:04
  • Final solution that worked - http://stackoverflow.com/questions/21128613/getting-web-config-to-specify-version-of-odp-net-thats-different-from-installed – Trebor Jan 16 '14 at 00:39
  • You should post it and flag it as the answer. That way someone searching might discover it based on the way you phrased the question. – Keith Payne Jan 16 '14 at 01:57

1 Answers1

0

Solved finally - The solution was to use the Oracle Managed Driver instead of the Unmanaged driver. This link was very helpful in explaining benefits along with the referenced video showing step by step how to make the change from unmanaged to managed. Oracle ODP.net Managed vs Unmanaged Driver

I also had to use a tnsnames-less configuration (copying tnsnames.ora didn't work for me as described in the video). I.e. I used Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521‌​)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl)));User Id=oracle_user;Password=oracle_pwd;" as part of my connection string. I've tested on three different systems so far and all seem to workgreat. To make it easier to manage I just pull my parameters from my app/web.config file and populate the above string.

Community
  • 1
  • 1
Trebor
  • 686
  • 2
  • 9
  • 33