TMSTable.Open hangs

[AndreyZ]

Could you also please specify the service pack of your Windows XP (SP1, SP2, SP3).

I'm also still using the trial version of SDAC. Could that be the problem?

This is unlikely.

[Kire]

Service Pack of XP is SP3

Thread that mentioned the trial issue regarding access violation is this (old) one:

http://forums.devart.com/viewtopic.php? ... dac#p42484

[AndreyZ]

I checked this question in the following environment:
Windows XP SP3 (I created a new virtual machine for it)
RAD Studio 2007 11.0.2902.10471
SDAC Trial 6.2.7
Microsoft SQL Server: 10.50.1600
Microsoft SQL Server Native Client 10.0: 10.0.1600.22
, but could not reproduce the problem.
Please try the following:
1. Try using the latest SDAC version 6.2.8 and check if the problem persists.
2. Try creating a new application that uses ADO components and check if the problem occurs in this situation.
3. Try using a new virtual machine with clean Windows XP SP3 (as I did) and check if the problem occurs in this situation.

[Kire]

I finally managed to reproduce one access violation in a smaller project. I've sent you the sample project by e-mail.

Although this is not the access violation that occurs at shutdown, I believe it is related to it.

Thanks in advance.

Erik

[AndreyZ]

Thank you for the information. We have reproduced the problem and the investigation of the problem is in progress. As soon as we have any results we will let you know.

[Kire]

Thanks for the update!

If you believe the issue has also to do with the random access violations at shut down of the application, please let me know. Otherwise I'll keep trying to reproduce that problem too.

Regards,
Erik

[AndreyZ]

We are not sure if this AV has anything to do with random AVs that you encountered on your application closing. We are investigating this question now. We will let you know as soon as we have finished the investigation.

[Kire]

Is there any update on this item? It's been a month now and we are desperately waiting to proceed with the implementation or decide to choose for another solution.

Regards,
Erik

[AlexP]

hello,

We are still working on this problem.
We will notify you as soon as we have any results.

[AndreyZ]

This problem is fixed in SDAC 6.5.9. Please try using it and confirm that the problem is solved.

[Kire]

Hi,

Version 6.5.9 seems to have fixed all access violations.

Thanx for fixing these issues!

Only real problem we are encountering now is that all data of the tables is stored in memory when openend? Since we have some tables that are up to one GB this is consuming a lot of memory. Is there a way to work around this?

[AndreyZ]

It is good to see that the problems with AVs are fixed.

The point is that when a query is opened and data is read out of it, the memory is allocated for the data on a client computer. To avoid this, you can read data by portions and free the data memory that is already not needed. To achieve such behaviour, you should set the UniDirectional property to True. Here is a code example:

Code: Select all

MSTable1.UniDirectional := True;
MSTable1.Open;
while not MSTable1.Eof do // read all data
  MSTable1.Next;

In this case, all the needless data memory that was read, will be released automatically. Note that, if UniDirectional is True, you cannot modify data, only read in one direction. For more information about the UniDirectional property, please refer to the SDAC documentation.

[Kire]

UniDirectional is not the ideal solution for us, since we also modify data using the TMSTable.

In the meantime we came up with a different approach which I hope is valid.

These big tables are all child tables of one other simple table. We step through the parent table using a secondary key and used to use SetRange to position the other tables to the right primary index of these tables. Since SetRange is not available in TMSTable we replaced those calls with FilterSQL.

FilterSQL is used to restrict the dataset on the server side according to the documentation. However the memory usage is still huge after opening the table and is not released after the first FitlerSQL assignment to the table. We figured that the data initially fetched when opening the table is not freed after the first FilterSQL usage.

Now we make sure that before opening the table there is always a FitlerSQL condition set. In fact using the BeforeOpen event. This seems to do the trick. Hope you can confirm this is a valid solution.

Regards,
Erik

[AndreyZ]

Yes, it is a valid approach. The FilterSQL property is used to change the WHERE clause of the SELECT statement and reopen a query. So, if you want dataset contain only data that is restricted by FilterSQL, you should set FilterSQL before opening a dataset.

[Kire]

At the moment all major issues regarding SDAC seem to be gone. First version of our software running without BDE is being tested.

Thanx for the support, fixes and suggestions !