|
|
Posted by Zvonko on 11/26/15 11:52
Erland, thanks for the prompt response.
So generally, I am considering that it is far quicker to let everything
regarding computing and large insert be done directly in the database. But I
can not inform my user what is going on.
Then I should do everything on a client computer. But then there is a lot of
bottlenecks during server-client communication and a very poor performance,
but my users get a beautifull status bar and counter and stuff.
What to do, and what you guys are doing? Just a discussion (as this is a
discussion board)
Thanks
Zvonko
"Erland Sommarskog" <esquel@sommarskog.se> wrote in message
news:Xns97FC7BE8A37D8Yazorman@127.0.0.1...
> In general terms it's not possible.
>
> For a specific procedure it could be possible depending on what it does.
> A simple case is a procedure that runs a cursor. In this case you could
> send informative messages with RAISERROR WITH NOWAIT. (Not PRINT, because
> PRINT gets buffered.) Then again, the end user is better served if you
> skip the cursor and perform the processing directly.
>
> A similar approach could be applied to procedures that performs several
> updates, although chances are good that all the time is spent on a
> specific statement.
>
> And for a procedure which consists of a single statement it is about
> impossible. Possibly, you could have a parallel thread which runs a
> query with NOLOCK that determins how many rows have been updated/inserted.
> But if what's takes time is to locate the rows, this is not a very
> meaningful operation.
>
> Add to this that a query may be delayed to blocking, in which case you
> have no clue how long time it will take.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|