Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How can I have a active window when application is executing long job like SQL job?

3 views
Skip to first unread message

Vahid Gachkaran

unread,
May 6, 2008, 1:30:55 AM5/6/08
to
Hello
I have a problem.
How can I have a active window when application is executing long job like
SQL job?
I have a waiting progress component in my form but when SQL job is running
waiting progress component don't work properly and it's to freeze.

Thanks.

Remy Lebeau (TeamB)

unread,
May 6, 2008, 12:55:06 AM5/6/08
to

"Vahid Gachkaran" <gach...@gmail.com> wrote in message
news:481f...@newsgroups.borland.com...

> How can I have a active window when application is executing
> long job like SQL job?

By performing the job in a separate thread.

Also, make sure your SQL itself is optimized, and the database is indexed
properly. That will greatly increase performance if you are not already
doing so.

> I have a waiting progress component in my form but when SQL job
> is running waiting progress component don't work properly and it's
> to freeze.

That is because you are running the job in the main thread, blocking the
message queue from processing new messages until the job is finished.


Gambit


Vahid Gachkaran

unread,
May 6, 2008, 2:10:03 AM5/6/08
to
Thank You,
Do you have a demo or example for this problem?


"Remy Lebeau (TeamB)" <no....@no.spam.com> wrote in message
news:481fe68d$2...@newsgroups.borland.com...

MikeR

unread,
May 6, 2008, 7:41:44 AM5/6/08
to
Vahid Gachkaran wrote:
> Thank You,
> Do you have a demo or example for this problem?

A couple of tutorials:

http://sklobovsky.nstemp.com/community/threadmare/threadmare.htm
http://cc.codegear.com/Item.aspx?id=14809

A Google search of the newsgroups will turn up more that you want to see.
Mike

David HAROUCHE

unread,
May 6, 2008, 8:24:20 AM5/6/08
to
You also could separate the SQL select in two parts :

1st step :
a) Take the time...
b) select count(*) from <your clause...>
c) compute the processing duration in milliseconds !
d) Set your progressbar max property to count(*)

2nd step :
a) Set a OnTimer Event with an interval of (processing time/count) that
will make your progressbar increasing by 1 !
b) select * from <your clause...>
c) when the select statement ends, shut the timer off !

--> your progress bar should have been correctly updated !

DH


Chris Morgan

unread,
May 6, 2008, 8:24:24 AM5/6/08
to
> b) select count(*) from <your clause...>

Usually select count(*)... takes as long as the selection
you are counting. So this will not speed up, or appear to
speed up, the application.

cheers,

Chris


David HAROUCHE

unread,
May 6, 2008, 9:22:55 AM5/6/08
to
> Usually select count(*)... takes as long as the selection
True ! But as told by someone in another post, be sure that your database is
correctly indexed... and a good DBMS as SQL Server, maintains (if told) a
cache of last fetch, which, in our case, will be the same !

> you are counting. So this will not speed up, or appear to
> speed up, the application.

What you could do too, is to write a stored procedure, if available, so that
the indexes used should be maintained by the DBMS.

Some SQL also allow you to specify a NEXT <value> statement with a SELECT,
that will take the next <value> records of the last fetch ! So meanwhile,
the user could broadcast a message to Windows, trapped by any application as
a progress indicator !

DH


Chris Morgan

unread,
May 6, 2008, 11:57:37 AM5/6/08
to
>> you are counting. So this will not speed up, or appear to
>> speed up, the application.
> What you could do too, is to write a stored procedure, if available, so
> that
> the indexes used should be maintained by the DBMS.

A stored procedure won't speed up the query either, just makes
it slightly easier to call. And any decent database maintains its
indexes (indices?) automatically anyway, and maintains a cache of
recent queries, so it can retrieve them easily if nothing else
has changed.

If you have a complex query, it may take some time to return.
A single-threaded GUI app will become unresponsive during
this operation. Your choices are either to accept this, or use a 2ndary
thread to retrieve the data.

cheers,

Chris


Remy Lebeau (TeamB)

unread,
May 6, 2008, 1:13:35 PM5/6/08
to

"David HAROUCHE" <met...@hotmail.com> wrote in message
news:48204cfc$1...@newsgroups.borland.com...

> a) Set a OnTimer Event with an interval of (processing time/count)
> that will make your progressbar increasing by 1 !
> b) select * from <your clause...>
> c) when the select statement ends, shut the timer off !

That won't work. TTimer is a message-based timer, and the SQL query is
blocking the message queue from processing messages (hense Vahid's original
posting).


Gambit


David HAROUCHE

unread,
May 6, 2008, 1:34:39 PM5/6/08
to
>>SQL query is blocking the message queue from processing >>messages

Even when using a specific ODBC driver ?

DH


David HAROUCHE

unread,
May 6, 2008, 1:33:07 PM5/6/08
to
Sure threads are a good thing...

DH


Remy Lebeau (TeamB)

unread,
May 6, 2008, 2:04:12 PM5/6/08
to

"David HAROUCHE" <met...@hotmail.com> wrote in message
news:4820...@newsgroups.borland.com...

> Even when using a specific ODBC driver ?

Yes.


Gambit


0 new messages