• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 318
  • Last Modified:

Form freeze during Client/Server Transaction

Delphi experts:

How to render the client application form while running a large volume Client/Server transaction?  The from either freezes or blanks out while doing other windows applications until the transaction finishes.
0
skyrider_tieus
Asked:
skyrider_tieus
1 Solution
 
mhervaisCommented:
did you try to issue sometimes
application.processmessages ?
0
 
mullet_attackCommented:
if you're using ADO Query, put the Application.Processmessages in the OnFetchProgress event. It gets called periodically during processing. BDE TQuery has no such event.

Other option is to put your transaction in it's own thread.

Mark
0
 
cheka021100Commented:
it is a compatible method to solve this kind of problem to make another thread which encapslute the database process code .
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
skyrider_tieusAuthor Commented:
It's not a ADO Query.  It's a Client/Server dataset application via ODBC to MS SQL. I did try some simple thread object, but it won't work.  Shall I wrap up more transaction code in the thread object?
0
 
skyrider_tieusAuthor Commented:
To mhervais

Application.processmessages works with some botches.  It refreshes the form till encountering ApplyUpdates and CommitUpdates transactions. Is there a way getting around to it?
0
 
mhervaisCommented:
Please Skyrider, English is not my mothertongue and I don't get you clearly, can you be more explicite about your question?
0
 
skyrider_tieusAuthor Commented:
I'm using Cache update in my program. Application.processmessages solves part of the problem.  It works fine before executing ApplyUpdates and CommitUpdates methods.
0
 
mhervaisCommented:
Skyrider and how many updates are you holding in cache ?

there is a bad issue with this affair. it took me about one month of night and day debugging to find it :

when you read and write with TDataset (even if you only read, even if you do not ask caching) the dataset does not flush the cache until you close the table. TBDE dataset has the commit update method for that, but I am not using BDE.

What happens is that if you don't take care, you use more and more memory, and then windows begins to swap virual memory (huge performace decrease) and if it continues, you can even get a genral memory fault.

It is not franky a memory leak, because if you do close the table (or commitupdates with TBDEDATASET), the memory is release. However I do not consider this situation as clean.

In my progs, I close and reopen the tables frequently in order to avoid the problem.

All this to say that the cache should hold a small amount of data (hence the duration of applyupdates should not be an issue).

My opinion is that if you hold a large amount of data in the cache, you have a design issue in your program.

Hope it helps, Marc
0
 
skyrider_tieusAuthor Commented:
Dear mhervais

It really helps. Thanks a lot.
I'm migrating records 30,000 and above
between heteorogeneous databases. BDE(ODBC) is employed.  One single table might hold 30,000 records and above in it. Tables are closed and opened during transactions. But the problem lies in the voluminous records transaction for one big table. During this lengthy cache update, the form freezes.  
   
0
 
skyrider_tieusAuthor Commented:
A quick and straight forward solution to this problem.
0
 
mhervaisCommented:
glad about that.

when I asked the question about it here, nobody knew.

I had to stand on it night and day to find it, because you simply cannot run debugging tools on such huge quantities.  

I guess it must be one of borland's most hidden secrets :-)

Regards, Marc
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now