October 16, 2005 at 3:10 pm
Is there any posibility to make a progress bar for a stored procedure executing on a server
(not local machine).
I cant seem to catch more than one prints(to send some progress messages), something about Delphi and Ado.
For now im even thinking about starting a program on the target computer(with a parameter from 1 to 100, with just one window and a progress bar) from my stored procedure by
executing some ...
xp_cmd 'Target\\ProgressAplication' + @progressValue.
but there must be an easier way .....
but if there isnt, can i do something similar to threads, in SQL?
something like launch a procedure and continue with the execution without waiting
for it to finish?
October 17, 2005 at 10:30 am
Hi there,
There are a couple of problems you will need to consider in the implementation. First is that when a proc is executing on the server, it may not execute in a linear fashion. That is, it may start, run for a while, sleep for a while, run some more, and so on. This may have the effect of causing your progress bar to look a little unpredictable. A strange behaving progress bar may do more harm than good.
One solution you may want to consider is using a secondary table that is updated from the running proc. For example, every hundred rows, your running proc may increment a row/column in the progress table. Your client application, in a separate thread from the initial call, can query the progress table on a periodic basis and update the progress bar appropriately. This approach requires that the client application establish a "handle" that will allow the client app to query the table for correct progress data. One approach I have used in the past is to use the client machine name + proc name + datetime stamp as a handle.
An alternative approach, allowing the proc to create the handle, has problems when the client is routed through a middle tier, perhaps for connection pooling purposes. In this case, the proc may not know which client initiated the call. Further, if the app is stateless, then the proc would likely be run in a fire-and-forget mode, thus preventing the middle tier from returning a handle to any client.
This approach is basically a poor man's semaphore, but it works "good enough" to monitor long-running queries. There are more sophisticated approaches based, but I like this for its simplicity.
Hope this helps
Wayne
October 17, 2005 at 1:23 pm
thank you, i never thought of that, i was too busy tring to catch several PRINTS,
and one extreme solution was to write an extended procedure to send some packets using sockets and the client aplication will monitor that socket .... but this is much better
and simple, thank you!
February 8, 2006 at 4:37 am
Please could u send me some sample code on how u could do it?
February 8, 2006 at 2:33 pm
tell me the language ... it depends a lot on the language.....
February 23, 2006 at 4:32 am
Please could u send me the sample code for a remote progress bar in C#.NET
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply