Tokyo 10.2.3 EAccessError

[Aggie85]

Howdy Maxim!

I have a large program using TVirtualQuery against TkbmMemTables very stable for the most part.

Since updating to Tokyo 10.2.+, I get several places in my program where setting an instance of TVirtualQuery's SQL property generates an EAccessError and the call stack shows it is in ProcessSQLChanged.

I cannot reproduce this in a small program.

I have Unidac Professional which I currently only use TVirtualQuery.

What is the best way to get source code for TVirtualQuery so I can help y'all detect these kinds of problems with a better callstack / line of code where it happens.

Thanks in advance,

Aggie85

[Aggie85]

Howdy Maxim!

Any comment... I am starting to find the setting of the SQL property causing the same ProcessSQLChanged EAccessError in more and more places in my program.

All the best,

Aggie85

[Aggie85]

Maxim,

I just ordered an upgrade to the source version of TVirtualQuery so I can tell y'all where it is causing issues.

I have no idea if it the linker or a bug as it happens randomly and it is happening in more places now in my application as I add new modules.

After I get the source for TVirtualQuery, I will try and see if I can narrow it down.

Thanks,

Aggie85

[MaximG]

We will be waiting for any details of the described issue.

[Aggie85]

Howdy Maxim!

I have the Unidac source build installed and I am now building my application.

Since I have a few things to go through and it is the beginning of my day and the end of yours, hopefully I will be able to isolate the issue before you come back to work.

I really hope it is a Devart bug and NOT a C Builder linker issue - that way I know it will be fixed in my life time <lol>!

I really appreciate y'alls great product and support.

All the best,

Aggie85

[Aggie85]

Howdy Maxim!

Well, after spending over 9+ hours trying various compiler / linker options, here is where it ALWAYS crashes if my program is statically linked:

procedure TCustomDADataSet.CheckIRecordSet;
var
ClassType: TClass;
begin
if (UsedConnection <> nil) then
ClassType := UsedConnection.GetIRecordSetClass
else
ClassType := nil;

RIGHT HERE >>>>>> if ((ClassType <> nil) and not IsClass(FIRecordSet, ClassType)) or (FIRecordSet = nil) then begin
FreeIRecordSet;
CreateIRecordSet;
end;
end;

If I link with packages, the same code ALWAYS works and I have no issues. I am hoping y'all can find a workaround that fixes the problem. Trying to distribute a couple hundred BPLs is a REAL PITA.

Please let me know if I can be of any help and I appreciate the help.

All the best,

Aggie85

[MaximG]

Thank you for providing the information. Unfortunately, the provided description is not enough to reproduce the issue. The code snippet provided by you is used in the products of many of our users and does not cause any issues. Therefore, in order to investigate the causes that lead to the error, please try to compose and send us a small sample, execution of which using the CheckIRecordSet method will result in an error. For this, use the e-support form (https://www.devart.com/company/contactform.html)

[Aggie85]

Howdy Maxim!

I was afraid of that. In the past, I have seen similar issues with the C Builder ILINK32 on large applications.

I haven't seen it in years though until I updated to 10.2.x.

Quick question: since I only use TVirtualQuery in Unidac at the moment, is there any harm in commenting out the IF statement?

All the best,

Aggie85

[MaximG]

You have the version with source code of our product, so you can comment out the fragment of our code that you want and then, test your projects operability after this