OCI.DLL issue with Oracle Instant Client

[mario.niesser]

Dear Devart-Team,

We are currently in the process of moving from Delphi XE with ODAC 8.1.4 to Delphi XE6 with ODAC 9.4.11.
With the newly compiled x86-executables we now have issues on some clients.

On clients with an Oracle Full Client, everything works as expected - It seems that ODAC uses the Oracle Homes stored in the registry and uses one of the x86 Oracle Homes for an x86-executable.

On clients that only have an Oracle Instant Client and therefore have no Oracle Homes in the registry, it seems that ODAC uses the windows path variable to search for an oci.dll.
If the first entry in the path variable is a x64-Oracle-Instant-Client the x86-application fails to start with error message: "Cannot load OCI DLL: C:\App\Oracle\product\instantclient_11.2.0_x64\oci.dll".
When I swap the order of the instant client entries in the path variable so that the x86 entry is first, everything works fine. As the order of the entries depends on which of the clients was installed first we see no chance in influencing the order on the clients.

With the old ODAC version 8.1.4 that we were using for quite some time, we had none of those issues (on the same clients with the same settings)

Is there some sort of switch that makes the new ODAC components behave as 8.1? How did the old ODAC components determine which of the available instant client oci.dll's is the correct one to use? The order in the path variable does not seem to influence it.

[mario.niesser]

As we do not have the source codes of the ODAC components we tried to find out a bit more about what is happening behind the scenes by using sysinternals dependency walker.

ODAC 8.1.4:
LoadLibraryExW("oci.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) called from "ODAC8_1TEST.EXE" at address 0x0057C8C2.

ODAC 9.4.11:
LoadLibraryW("C:\app\oracle\product\instantclient_11.2.0_x64\oci.dll") called from "ODAC9_4TEST.EXE" at address 0x00768D06.
Unloaded "Unknown" at address 0x02A30000.
LoadLibraryW("C:\app\oracle\product\instantclient_11.2.0_x64\oci.dll") returned NULL. Error: %1 ist keine zulssige Win32-Anwendung (193).

How ODAC9 resolves the path of the oci.dll and why this is different to the former versions remains unclear for us.

A simple example on how you should be able to reproduce the issue:
-Install Oracle Instant Client x86 (no Oracle Home is created)
-Install Oracle Instant Client x64 (no Oracle Home is created)
-Make sure that the InstantClientx64-path is listed first in the path variable. If not change it (and reboot)
-Create a new project with a TOrasession and add e.g. a button to initiate the Orasession.connect
-Start the application and establish the DB connection

[AlexP]

Now the full library loading path is used in order to avoid problems with incorrect loading when using several clients. In you case, you should either change the path variable or add the data about clients to the registry.

[mario.niesser]

Hi Alex,
Thanks for your feedback.

As I am not able to influence the oracle client installations on the clients, I'm not able to add the data (Oracle homes) to the registry. If I like it or not I have to live with the predominant conditions on the clients.

I have to check about the idea of changing the path variable though. As far as I understand your idea, it would mean that on application startup I would have to remove all oracle-related x64 paths from the path variable for this session to make sure that the ODAC algorithm is just able to find x86 oracle clients.
This solutions does not really seem too reliable to me because I'm not able to influence the predominant pathnames on the clients in any way. Example: If a user installs the oracle client to a path named C:\test I would not be able to identify this as a path that I would have to remove from the path variable.

I really hope that you can offer us a different solution - maybe a flag that makes it possible to switch between the new and old dll-loading behaviour. The old one worked flawlessly for us and our customers and I fear that we soon run into serious trouble if we have to stick to our old dev environment (XE+ODAC 8.1.4).

[heidenbluth]

Hello Alex,

We are facing similar problems on machines having different copies of Oracle's instant client. ODAC loads the first OCI DLL found using the Windows serach path regardless of processor architecture.

Whereas the Windows LoadLibrary('OCI.DLL') function automatically searchs the PATH for a DLL having the same processor architecture, ODAC loads the first one found matching the name only. Your function GetDefaultHome iterates the PATH for a matching OCI DLL. Therefore, it tests using CheckHomePath() function. This code does not check the processor architecture of the DLL.

We would suggest including a check for matching processor architecture to the CheckHomePath() function. That would solve the problem quickly. Nevertheless, it would be much faster letting Windows do that instead of repeatedly searching by code.

This is some sample code we found to check processor architecture of the (not yet loaded) OCI DLL:

Code: Select all

// returns true if the dll is 64-bit, false if 32-bit, and null if unknow
function UnmanagedDllIs64Bit( ADllPath: String): Boolean;
begin
  try
    case GetDllMachineType(AdllPath) of
      IMAGE_FILE_MACHINE_AMD64,
      IMAGE_FILE_MACHINE_IA64: Result := True;
      IMAGE_FILE_MACHINE_I386:  Result := False;
      else begin
        Assert(False);
        Result := False;
      end;
    end;
  except
    on E:EFOpenError do begin // DLL is in use
      Result := False;
    end;
  end;
end;

[AlexP]

Thank you for the sample, we will consider the possibility to use these code to solve the problem with library files.

[mario.niesser]

Hi Alex

I discovered that a new ODAC version (9.4.14) was published recently.
Taking a look at the revision history it appears that no solution concerning the issue mentioned before was implemented in the new ODAC version.
It's important for us that ODAC is able to distinguish between x86 and x64 oci.dlls for our customers PCs having oracle instant clients (without oracle homes).
The solution user heidenbluth suggested sounds like it would completely solve our issue.
Do you have an estimate when you will be able to implement such a solution?

Best regards
Mario

[AlexP]

Unfortunately, we can't use the provided code. We continue investigation of the problem solution.

[wchris]

We have also issues with customers that cannot load OCI.dll on various installations. We have all range of oracle versions from 8i to 12 mixed with all ranges of windows OS versions on x32 or x64 machines.

We are about to release all our customers with a new version of our software, some of them have 300 pc running the app so we cannot request them to make configuration changes on all PC that were running well before.

Could you not just add a compatibility switch to process homes like previous versions to avoid changing configurations ?

[AlexP]

We have added client library version check. Now the application will work with a corresponding library version. This fix will be available in the next build.