Hello,

I have some queries (even an import from a csv file) which may take several seconds. When running these queries from Delphi, Windows decides that my application is "not responding". Is there a solution for this problem? I did try to run the queries in a thread but without success.

Beni.

The message simply means that application main (UI) thread is not
processing messages - windows 7 i think has 5 sec as the threshold.

Your query is blocking the main thread so you need to make it finish sooner:

- are your queries optimized  ?

- are your results sets sensitive or not ?

- you could use the OnProgress/OnStatusMessage to try to pump the
message queue (i.e. use Application.ProcessMessages)

- for anything that does not need to run on main UI thread move it to
worker thread(s) (threads work just with EDB so if you did not have
success with this then tell us what the problem was as it does work just
fine so maybe we can help).

Raul


On 8/8/2013 6:28 PM, Beni wrote:
> I have some queries (even an import from a csv file) which may take several seconds. When running these queries from Delphi, Windows decides that my application is "not responding". Is there a solution for this problem? I did try to run the queries in a thread but without success.

Thanks for your help. I did manage to solve my problem with the OnProgress event by calling the PeekMessage function from time to time.

What I did before was to run an import query (IMPORT TABLE [TableName] FROM [FileName] etc) in a Delphi application. The file I was importing from had over 60 000 records and it took more the 5 seconds to complete it. So windows decided that my application is “not responding”. I put this query on a secondary thread but had the same behavior (“not responding”). The session wasn’t defined on the secondary thread, only the query.

Beni

>What I did before was to run an import query (IMPORT TABLE [TableName] FROM [FileName] etc) in a Delphi application. The file I was importing from had over 60 000 records and it took more the 5 seconds to complete it. So windows decided that my application is “not responding”. I put this query on a secondary thread but had the same behavior (“not responding”). The session wasn’t defined on the secondary thread, only the query.


In that case I hope you're not doing anything else with that session whilst the thread is running. A prime rule is to totally isolate ALL of the database components apart from the engine in any secondary thread.

Roy Lambert [Team Elevate]

No, I do nothing with the session on the main thread. My problem was with some queries on larger tables displaying results in grids etc. On some older/slower computers the queries may take more time and windows was setting my application as not responding.

Beni

>No, I do nothing with the session on the main thread. My problem was with some queries on larger tables displaying results in grids etc. On some older/slower computers the queries may take more time and windows was setting my application as not responding.
>

That may have been why you were trying a thread but my point was that if you use ElevateDB (or DBISAM) in a thread you need to fully isolate things (and you haven't) otherwise you may have an additional problem later.

Roy Lambert [Team Elevate]

Beni,

To rephrase what Roy mentioned, if you create a thread, you will need to instantiate another copy of your datamodule for the thread to use. The tread cannot reference the datamodule (or any other components) on the main thread. The thread you create must be totally isolated from the main thread.

Barry

Barry


>To rephrase what Roy mentioned, if you create a thread, you will need to instantiate another copy of your datamodule for the thread to use. The tread cannot reference the datamodule (or any other components) on the main thread. The thread you create must be totally isolated from the main thread.

OK who mentioned datamodule

Unless you have a specific datamodule which has just those components on it that are required for the thread I would advise against the use of one.

Over the years I've gone from plonking tables on forms to datamodules and back to plonking tables on forms. My major app has two datamodules, one with the engine, session, database and a few common bits on it and a second with all the lookup tables used throughout the app. The first's OnCreate event is where stuff gets hooked up (eg database path set). All the other tabkes / queries are on the forms on which they are used.

For threads I generally pass in the session/database in the thread.Create method and use those as templates to create the local instances - they  are only ever read never written to in the thread.

Roy Lambert

I think that could be confusing.

The rules are really quite simple : you simply need a unique session,
database and query/table for each thread.

However that is accomplished - datamodule or runtime creation.

manual :
http://www.elevatesoft.com/manual?action=viewtopic&id=edb2&product=rsdelphiwin32uni&version=XE4&topic=Multi_Threaded_Applications

Raul

On 8/10/2013 11:27 PM, Barry wrote:
> To rephrase what Roy mentioned, if you create a thread, you will need to instantiate another copy of your datamodule for the thread to use.

OK who mentioned putting tables in the datamodule

You can still put the TEDBTable, TEDBQuery and TDatasource on each form. But the thread still needs its own instantiated datamodule that contains the TEDBDatabase, TEDBEngine, TEDBSession.

Barry