Concurrent queries error

On my server running SQL Server 2000 (SP3). I frequently get this
informational message in the Event Viewer log.

17052 :
This SQL Server has been optimized for 8 concurrent queries. This limit has
been exceeded by 2 queries and performance may be adversely affected.

The application that I am running is a vendor application so I do not have
access to the code. I contacted the vendor, but they have never seen this
problem and cannot recreate it. I checked the Microsoft Knowledge Base for
help, but I came up empty. It seems like it should be a simple
configuration change.

Any advice?
Thanks,
JeffI found the answer many times by just searching this site. Should have
done that first.

Go ahead and remove this thread.

Jeff

Concurrent Procedure Execution

Hi,
Think of that there is a db which is used by many users. An there is a proc
which is called frequently by all users. For concurrent callings of this
proc by many differents users, Does there occur several execution time
intervals as parallel or are the concurrent callers wait each other? AND Can
we or Do we have to use BEGIN and COMMIT TRAN pairs for an atomic process in
such situations?
Thanks in Advance.
Emre GuldoganOn Thu, 10 Mar 2005 15:42:22 +0200, "Emre Guldogan" <ask me please...>
wrote:

>Think of that there is a db which is used by many users. An there is a proc
>which is called frequently by all users. For concurrent callings of this
>proc by many differents users, Does there occur several execution time
>intervals as parallel or are the concurrent callers wait each other?
Hi Emre,
Different users can execute the procedure simultaneously; they will
execute in parallel. Of course, if the procedure locks data, this will
block other users trying to use the same data, whether through the same
procedure or not. For most data retrieval procedures, this should not be
an issue, so execution would be simultaneous; for data modification
procedures, locking and blocking might lead to actual execution being
serial, but that depends on the code of the procedure, the transaction
isolation level and whether transactions are used or not.

>AND Can
>we or Do we have to use BEGIN and COMMIT TRAN pairs for an atomic process i
n
>such situations?
If you need atomic processing, you should indeed use BEGIN TRAN and
either COMMIT or ROLLBACK TRAN. If different users execute the proc
simultaneously, the transactions won't interfere (but they might block
each other, as indicated above).
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)