Devart Forums

I am not sure who would manipulate the version information in the file ressource. If you are uneasy you can discover the information by function call once the library has been loaded. But it seems no good to load the librares without beeing sure to using it.

Our customer has an Oracle 11.1 client as default and an Oracle 11.2 client in use. Our application uses DevExpress grids for displaying data. He got access violation errors when using the FilterRow. We got some feedback using Eurekalog and discovered that the application used a mix of Oracle 11.1 subordinate DLLs and Oracle 11.2 OCI.DLL. After changig the default to 11.2 the problem has been resolved.

We got similiar problems before, for example an exception "entry point of xxxxx not found in DLLxxxxx", because the newer OCI DLL doesn't find functions in the already loaded older subordinate DLLs.

Please consider that this is also a performance issue. Many customers have their Oracle client installed on a network drive. Loading the OCI with all its subordinary libraries for the only purpose to read the version number costs a couple of seconds. If you intend to allow the application user to choosing the Oracle client, the chances are good that you have preloaded the entire OCI just for fun. Furthermore, you have the stability problems discussed before.

Hello,

These *.dlls are loaded not only when receiving the client version, but also when calling other methods from OCI.DLL. That's why defining of the client version with the help of the file version won't solve this problem. We are working on solving this problem.