Access violation, 64 bit , static MidasLib

[PaulT2]

This may be an SDAC issue, or a Delphi issue, however, using ADO components, the problem does not present. Trying to convert our key client side product to 64 bit highlighted this problem. The software is quite complex - involving RemObjects SDK, plus a good number of 3rd party components, however I've eventually managed to narrow down the circumstances and have built a clean VM to further isolate the issue.

The new development environment is a clean install of XE2 Update 4, HotFix 1, along with the latest SDAC 6.2.7. This is running under a freshly built 64 bit Windows 7 Pro VM with all current windows updates applied.

You can find a very simple sample project uploaded to YouSendIt at the URL listed below. In the zip file is also a small script to create a table in tempdb and insert a few records.

The actual problem only seems to present under the following conditions :-

1). 64 bit
2). SDAC is used (in preference to ADO)
3). MidasLib is included in the project uses clause
4). The table being accessed has a similar structure to that in the sample project. Crucially, there must be a primary key defined.

Change any one of the above elements and the problem does not show. I can only think this is either SDAC or possibly TClientDataSet related. If you're able to offer some insight I'd be grateful as this seems to be the one thing left preventing deployment of our client software under 64 bit.

http://www.yousendit.com/download/QlVpW ... 00&s=19102

[AndreyZ]

Hello,

Thank you for the information. I have reproduced the problem and the investigation is in progress. I will notify you when I have any results.

[PaulT2]

Hi Andrey

I'm assuming you haven't reached a conclusion on the issue yet, but are you able to give me an update on where your investigation is leading ?

Are you able to see if the problem is with SDAC or Delphi? If it's the former, I know you'll get a fix relatively quickly, if it's the latter I have less faith that we'll get a fix in any meaningful time frame.

Thanks,

Paul.

[AndreyZ]

It seems that this problem is connected with SDAC. We are now investigating this question. As soon as we have any results, we will let you know.

[AndreyZ]

We have investigated the problem. It occurs that Midas generates AV if the PSGetKeyFields method (that returns the information about key fields) returns not empty string. You can reproduce this problem with ADO if you create persistent fields and for your UserId WideString field add pfInKey to the ProviderFlags property. We cannot influence such Midas behaviour.

[PaulT2]

Thanks Andrey. Now you've explained how to duplicate the problem with ADO, I've had a look on Delphi Quality Central. For future reference, I believe this bug in Midas may already have been reported as #104240. After following your comments and duplicating the problem in ADO myself,I've added notes to the QC entry to that effect.

It doesn't help me, but a workaround if you only need read only access would appear to be to set the ReadOnly property of the TMSQuery to true. I would guess that under the hood this works because in read only, the key fields possibly do not need to be known and therefore PSGetKeyFields is not called...

Looks like we have to stick with 32 bit on the client side at the moment as I don't want to deliver Midas.DLL separately again.

[AndreyZ]

Thank you for the information, it could be helpful to other users that visit our forum.