we have develope BL and Dal using the LLBL pro odp 2 now we are trying to deploy the website to a 64bit server but we got critical Errors

when i try to get SPs from the Generaterd code i get it fine but when we try to fetch Entities we recive Error (Oracle.DataAccess.Types.OracleNullValueException: Invalid operation on null data)

the only thing we did is to remove the odp 1.1 becouse we are deploying to 64 bit the 1.1 assambly not working

thanks

rotem or

Hello,

what version of llbl do you use?Do you use adapter or selfservices? Did you have any call stack for your error?

Also, be sure you install the same ODP.NET version at the client as well.

Otis wrote:

Also, be sure you install the same ODP.NET version at the client as well.

But how we need to install the same version of development 32-bit environemnt on 64-bit production server? (Our version of LLbL 2.0.0.0)

PeterS wrote:

Otis wrote:

Also, be sure you install the same ODP.NET version at the client as well.

But how we need to install the same version of development 32-bit environemnt on 64-bit production server? (Our version of LLbL 2.0.0.0)

Have you tried the latest 64bit version of odp.net? .NET code shouldn't be a problem, 32 bit or 64 bit. The problem is likely in the oracle client which is java + c code which is used by odp.net's managed dll.

Your code works fine on 32bit with the same version of the ODP.NET provider?

Otis wrote:

PeterS wrote:

Otis wrote:

Also, be sure you install the same ODP.NET version at the client as well.

But how we need to install the same version of development 32-bit environemnt on 64-bit production server? (Our version of LLbL 2.0.0.0)

Have you tried the latest 64bit version of odp.net? .NET code shouldn't be a problem, 32 bit or 64 bit. The problem is likely in the oracle client which is java + c code which is used by odp.net's managed dll.

Your code works fine on 32bit with the same version of the ODP.NET provider?

We have installed a latest ODP 64 bit version accrording to Oracle support's step-by-step instructions. After adding runtime policy all works fine instead of our generated code in cases of _adapter.FetchEntity. I maked some tets on 32-bit configurations with latest ODP 32 bit version. You can see, that 32 bit version instead of 64 bit adds some support for 10.1* Oracle.DataAccess. After removing Oracle.DataAccess of version 10.1* from GAC you have exectly this error.

So, QueryDinamicEngine of generator in some cases can make switch to newest ODP, and in another cases can't and call explicitly to old version of ODP (10.1.0.400).

Thanks for your quick response.

Sounds like an Oracle issue, did you contact them for this issue?

Walaa wrote:

Sounds like an Oracle issue, did you contact them for this issue?

Thanks you, Walaa, for response,

Yes.

This is instructions from Oracle support :

As discussed on the phone .

I was not sure whether you have installed ODP.Net 64 bit or 32 bit. The version described 10.2.0.1 appears to be a 32 bit only version.

As you have a new Server to install on here are the suggested steps to install a working ODP.Net on 64 bit windows (AMD64 or intel64).

1. Download Oracle client 64 bit from OTN http://www.oracle.com/technology/software/products/database/oracle10g/index.html

This is the 64 bit version for windows. http://www.oracle.com/technology/software/products/database/oracle10g/htdocs/10201winx64soft.html

1. Download ODP.Net 10.2.0.3 - 64 bit version from OTN http://www.oracle.com/technology/software/tech/windows/odpnet/64-bit/index.htm

2. Ensure you have installed .Net Framework v1 or v2 (64 bit this is important as 32 bit is not compatible)

Get it from msdn.microsoft.com 64bit framework

1. Follow Install instructions for installing Oracle 64 bit client.

2. Follow install instructions for ODP .NET 64 bit client

Ok, so the assembly redirect bindings of Oracle's policy file or in the config file of your application apparently dont' always work.

Could you test the following: - using the Runtime Library sourcecode (please download the latest from our website (customer area) - open in the OracleDQE folder, the file AssemblyInfo10gDotNet20.cs and replace the reference to our strong key (which we obviosly don't ship with the code ) with an empty string or a reference to your own strong key - open makefile10g_20 in notepad - in the csc line, add: /platform:x64 as a parameter to csc - at the top you'll see references specified and a reference folder. Make sure the folder points to the folder where the .NET20 ormsupportclasses dll is found, and make sure that the path to the odp.net dataaccess dll is correct for your situation. - save - on the command line in the oracle dqe folder, type vsvars32<enter> this will make sure you can use the csc.exe compiler (C# compiler) test this by typing: csc /?<enter> this should give a list of commands

   proceed with typing:

mkdir DotNET2.0\bin<enter> nmake /nologo /f makefile10g_20 clean<enter> nmake /nologo /f makefile10g_20<enter>

You now should have in DotNET2.0\bin a DQE dll for oracle 10g, build for 64bit, referencing the ODP.NET 64bit latest version.

Then, reference THAT DQE dll in your application and try it again on 64bit.

If needed, there's an option to build the ormsupport classes on 64bit as well.

We don't have a 64bit OS running here at the moment, so I can't test what you suggested. It's a weird issue, the dll's should be selected properly, so it's not a code error somewhere, but if this is solved by building the runtime libraries on 64bit with the latest odp.net, why not