XE6 ClientDataSet AV trying to load data from Firebird
I have a minimalist project with FireDac FDConnection and FDSqlQuery, DataSetProvider and ClientDataSet, trying to access the Employee.FDB example that comes with the Firebird 2.5 package I downloaded from SourceForge today.
Everything is set to default values as they fall outside the palette except for the database name in the FDConnection Popup tab and FDQuery Sql which is set to select * from employee
.
FDQuery opens fine, but as soon as I try to open CDS, in the IDE, or run my application, I get an access violation.
This is all my code:
FDQuery1.Open;
Caption := IntToStr(FDQuery1.RecordCount); // this shows 42 on the form caption
CDS1.Open; // AV here
So FDQuery opens fine, but CDS doesn't.
At runtime, the exception happens here:
function TCustomClientDataSet.CreateDSBase: IDSBase;
begin
CreateDbClientObject(CLSID_DSBase, IDSBase, Result);
Check(Result.SetProp(dspropANSICODEPAGE, DefaultSystemCodePage)); <-- Exception here
Check(Result.SetProp(dspropUTF8METADATA, NativeUInt(True)));
Check(Result.SetProp(dspropUTF8ERRORMSG, NativeUInt(True)));
end;
The exception to msg is
The FBTest1 project raised the $ C0000005 exception class with the message 'access vioaltion to 0x0075d05b: reading address 0x00000000'.
In the IDE I get a similar exception if I try to set Active = True on the CDS the message was written to DSnap200.Bpl.
The first time this happened at runtime, I got some kind of "Incident" pop-up message suggesting to report this to Embarcadero. This is the first time I've seen it.
If I replace SqlConnection and SqlQuery for FDac components, I get the same error.
So I guess my question is, can CDS be triggered by this behavior by simply using the project default property settings as easy as this, i.e. I skipped a step or is it most likely an EMBA QC thing?
source to share
Resolved! Thanks to Graymatter's suggestion to try using MidasLib, I have at the bottom of the problem and fixed it so that the application now works with Midas.Dll. I am posting this as an answer, not a comment, firstly because it is too long for this, but more importantly, the reason was rather strange and the solution could help anyone else who runs into the problem.
First, I tried using MidasLib and the app works fine, without the AV that q is talking about.
So, assured that the problem does not occur with the current MidasLib code, I went back to try and get the application to work with Midas.Dll. I checked the Midas.Dll versions in the XE6 bin directory and \ Windows \ SysWOW64 and both were as I expected, 20.0.16277.1276 dated June 16, 2014.
Tracking in CheckDBlient in DataSnap.DSIntf and observing carefully, a penny dropped and I figured out what was going on:
procedure CheckDbClient(const CLSID: TGUID);
[...]
begin
[...]
if DbClientHandle = 0 then
begin
Size := 256;
SetLength(FileName, Size);
if RegQueryValue(HKEY_CLASSES_ROOT, PChar(Format('CLSID\%s\InProcServer32',
[GUIDToString(CLSID)])), PChar(FileName), Size) = ERROR_SUCCESS then
SetLength(FileName, Size) else
begin
[...]
end;
DbClientHandle := LoadLibrary(PChar(FileName));
This gets the path to Midas.Dll from the InProcServer key on registration, and it did not point to the XE6 bin or SysWOW64 directory, but somewhere else that was not my creation and which contained a version of Midas.Dll dated from 2007. Oddly enough, unlike the copy I have in a D7-era Dll, this Dll has no version information on its property page, but has a creation date of August 9, 2002 and a 351KB file size.
So once I found that fixing the problem was as easy as renaming this Dll so the OS won't load it and re-register the version to SysWOW64.
Where the exile Midas.Dll came from is not clear, but he certainly has arrived since last week because it is not in the backup that I happen to be from last Thursday night.
The only thing I have installed since then are several third party GUI utilities for managing / accessing Access, IB and Firebird databases, so the culprit seems to have been one of them.
source to share