XE6 ClientDataSet AV尝试从Firebird加载数据

Question

我有一个带有FireDac FDConnection和FDSqlQuery，DataSetProvider和ClientDataSet的简约项目，试图访问我今天从SourceForge下载的Firebird 2.5软件包随附的示例Employee.FDB。

除了FDConnection的弹出信息选项卡中的数据库名称和FDQuery的Sql（已设置为）外，所有内容均已设置为默认值，因为它们离开了调色板select * from employee。

FDQuery可以正常打开，但是一旦我尝试在IDE中运行CDS或运行我的应用程序，就会遇到访问冲突。

这是我的全部代码：

  FDQuery1.Open;
  Caption := IntToStr(FDQuery1.RecordCount);  // this shows 42 on the form's caption
  CDS1.Open;  // AV here

因此，FDQuery可以打开，但CDS不能。

在运行时，异常发生在这里：

  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;

例外味精是

项目FBTest1引发了异常类$ C0000005，消息为“在0x0075d05b发生访问冲突：读取地址0x00000000”。

在IDE中，如果尝试在CDS上设置Active = True，则会收到类似的异常，该消息表示发生在DSnap200.Bpl中。

它是在运行时第一次发生，我有某种“事件报告”弹出窗口可以将其报告给Embarcadero。第一次见到。

如果我用SqlConnection和SqlQuery代替FDac组件，则会收到相同的错误。

因此，我想我的问题是，是否可以通过使用像该项目一样简单的项目的默认属性设置来激发CDS的行为，即我错过了一步，还是EMBA QC？

Answer 1

Solved! Thanks to Graymatter's suggestion to try Using MidasLib, I've got to the bottom of the problem and fixed it so that the app now works using Midas.Dll. I'm posting this as an answer, rather than a comment, firstly because it's a bit too long for that, but, more importantly, the cause was actually rather strange and the solution may assist anyone else who runs into the problem.

First, I tried Using MidasLib, and the app ran fine, w/o the AV that the q is about.

So, reassured that the problem doesn't arise with the current MidasLib code, I went back to trying to get the app to work with Midas.Dll. I checked the Midas.Dll versions in the XE6 bin directory and \Windows\SysWOW64, and they were both as I was expecting, 20.0.16277.1276 dated 16 June 2014.

Tracing into CheckDBlient in DataSnap.DSIntf and observing carefully, the penny dropped and I realised what was happening:

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 in its registration, and this wasn't pointing to XE6's bin directory or SysWOW64, but to another location that was not of my creation and which contained a version of Midas.Dll dating from 2007. Oddly, unlike a copy I have of the Dll dating from the D7 era, this Dll does not have version info on its property page but it has a creation date of 9 August 2002 and a file size of 351Kb.

So, once I'd found that, fixing the problem was as simple as renaming that Dll so that the OS won't load it, and re-registering the version in SysWOW64.

Where the rogue Midas.Dll came from isn't clear, but it certainly arrived since last week, because it isn't in the back-up I happen to have from last Thursday evening.

The only things I've installed since then are a handful of 3rd-party GUI utilities for managing/accessing Access, IB and Firebird databases, so the culprit seems to have been one of them.