Problem:

We are using CData's connectors with FireDAC to issue a SQL statement. When executing the SQL statement when EurekaLog is enabled, we get a generic exception error: E0434352 on the Query.Open. EurekaLog reports this exception as:

CLR (.NET) Exception
HRESULT: 8007002 (The system cannot find the file specified)
Module clr.dll
Code: E0434352
Address: 72D128F1 (001028F1)

Reason:

This issue is not related to EurekaLog:

1. One of our customer has confirmed that this issue happens even in a project without EurekaLog: 

   > When not running with EurekaLog, I still get the error like this: EExternalException with message 'External exception E0434352'. I found that if I don't close the database connection when I destroy the FDQuery to the AWS database this error occurs very frequently (connection timeout?). So I added a statement in the Destroy event of the Query to set the FDConnection.Connected := False; This seems to solve the problem;

2. CData's support has confirmed the same thing: "we tried to manually load the 'VCRUNTIME140_CLR0400.dll' and 'vcruntime140.dll' libraries in absence of EurekaLog and managed to reproduce the issue".

Communicating with CData's support suggests that the issue seems to be caused by loading VCRUNTIME140_CLR0400.dll and/or msvcr100.dll. Since EurekaLog is Delphi native code, it does not reference .NET/CLR run-time (VCRUNTIME140_CLR0400.dll) and it does not reference C++ run-time (msvcr100.dll). In other words, EurekaLog does NOT load VCRUNTIME140_CLR0400.dll/msvcr100.dll. You can verify this with empty Delphi project by enabling EurekaLog for it.

The mentioned DLLs can be used/loaded by other components in your application. For example, EurekaLog may load MAPI DLL to send e-mails, and that MAPI DLL may reference the mentioned DLLs.

Solution:

It looks like CData may be using "current directory"/relative paths to find/load DLLs. Loading one of the above mentioned DLLs either changes current folder or overrides DLL search paths, so that is why CData is no longer able to find/load the DLL.

Until the issue is fixed on CData's side (assuming it is a bug): you can workaround it by finding the DLL in question (by using the Process Monitor tool from SysInternals) and placing it into any of DLL search paths. For example, into your app's folder.

Our customer confirms that he is able to fix the issue by placing the required DLL into DLL search paths:

> I found an error about CData.Firem.SalesForce.dll using Process Monitor: PATH NOT FOUND. So I added this dll in the application's folder, and my application works fine now. If I remove the DLL - then I get the error again.

Summary:

1. As this issue is not related to EurekaLog - we would suggest to seek help from CData's support;
2. We would also suggest trying Process Monitor tool (from SysInternals) to check which file your application is unable to open;
3. You can also try sxstrace tool or "Break on module load" IDE's breakpoint to determinate who is loading the offending library.