Oracle DataAccess 4.112.3.0 and 4.122.18.3 compatibility issues — oracle-tech

    Forum Stats

  • 3,708,737 Users
  • 2,241,117 Discussions
  • 7,840,566 Comments

Discussions

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Oracle DataAccess 4.112.3.0 and 4.122.18.3 compatibility issues

42910004291000 Posts: 3
edited September 2020 in ODP.NET

Has anyone used Oracle UDTs with Visual Studio 2017, I'm finding the older 11g client works whilst the newer 18c client fails to populate my record collections

I built a solution using Oracle AQ using Visual Studio 2017 .Net targetting 4.7.2 - x86 project build due to age of some of the dlls - Oracle 12c database version 12.1.0.2.0

I used the Microsoft Create Custom class wizard to create the classes for the Oracle UDT.

The Class consists of a data set of 4 arrays, 2x  numeric, string and timestamp information.

The application successfully receives an Oracle AQ message (sent by a PLSQL package) which is then decoded and passes the required data via the record of arrays back to the Oracle query.

This works perfectly with the older 11.2 client (Oracle DataAccess dll 4.112.3) but rebuilding or running the project (using a binding redirect) to use the 18.3 client (Oracle DataAccess 4.122.18) does not work properly and I can get an error ORA-06531: Reference to uninitialized collection. I get this error when requesting larger data sets ie > 1 or 2 records . Small 1 or 2 record datasets are returned correctly

The project when built using the older 4.112.3 dll returns all data requests without any issue for small or very large data sets

Both the oracle client versions has been registered on the server.

Checking the returned data I see that the timestamp array is not being populated. Single stepping the application I can see that the AQ messages are identical going in to the call (m_AQTx_Queue.Enqueue(_message);)  where _message is an object of type OracleAQMessage regardless of the Oracle DataAccess .dll but being passed back to the oracle database is a different matter. With the later DLL failing to populate the timestamp array. I've tried various directives but to no avail. It does not matter whether the application is run on the development server which has both client versions or another server with just the later client installed in all cases the later client does not work correctly

Given that just changing the oracle client version causes the issue, then either I have some incompatibility somewhere or maybe a size restriction, can't be mapping otherwise small data sets would not work either.

Have tried searching for suggestions but this is a very odd issue and nothing found.

Anyone out there with ideas, didn't want to install the older oracle client just to get this to work.

Thanks

John

Answers

  • Alex Keh-OracleAlex Keh-Oracle Posts: 2,720 Employee
    edited August 2020

    I searched for an existing ODP.NET bug with similar symptoms, but could not find any. It's either a new ODP.NET bug or the root cause lies with another DB component.

    My guess is that something changed in the Oracle Client, maybe ODP.NET, maybe OCI, or another layer component between 11g and 18c that's not accounting for 12c DB behavior.

    This is probably something that can't be debugged without looking at the client and DB traces to understand how the error manifests. I would recommend opening an SR with Oracle Support to identify the root cause and fix the bug.

    Another thing you could try is use the latest 18c patch or 19c patch version. If this is a known issue and has already been patched, it would be in the latest 18c and 19c patches.

  • 42910004291000 Posts: 3
    edited August 2020

    Thanks Alex, I'll talk do my DBA's and raise up a request. was using odac 18.3, but will download and try 19c client, with that thought in mind maybe the ODAC 12.2 client as well although its better to go later than earlier.

  • 42910004291000 Posts: 3
    edited August 2020

    Well that was a bad idea - sort of, installed 19.3 and 12.2 in different homes on another drive but somewhere along the line have managed to break my working 11.2 version, may have been the machine wide install the 12.2 client suggests. Updated the path variable to the original 11.2 install but still no success, so back to debugging how a search path can make such a difference. Guess Oracle are the next port of call

  • Alex Keh-OracleAlex Keh-Oracle Posts: 2,720 Employee
    edited August 2020

    The assumption with machine-wide install is that you are upgrading and want the new ODP.NET version to be used by all apps on the machine. Machine-wide install will place ODP.NET into the GAC. You can unGAC ODP.NET so that the 12.2 version doesn't override your use of other ODP.NET versions on the same machine. Keep in mind there are separate GACs for 32-bit .NET 4 and 64-bit .NET 4.

  • edited September 2020

    Hi John,

    Don't mean to hijack your thread but how did you get Oracle.DataAccess dll with version 4.122.18.3 ? My application requires this dll and would be interested in downloading and installing it.

  • Alex Keh-OracleAlex Keh-Oracle Posts: 2,720 Employee
    edited September 2020

    You can get unmanaged ODP.NET 4.122.18.3 installing Oracle DB Client 18c or ODAC 18c.

Sign In or Register to comment.