Hi Daniel,

From your descriptions, I understood that your concerns are your simple SELECT statement
will cost 2-3 seconds. Have I understood you? If there is anything I misunderstood, please feel
free to let me know.

First of all, SQL Server is on your local server or remote server? If you link SQL Server by
means of network, it may be an network performance issue. Does that server has a heavily
workload? If so, I think bottle-neck of hardware may lead to this kind of latency.

Secondly, we could do the following trying to find more detailed information about it
1. Use Estimated Execution Plan(write the statement and then press <Ctrl> + <L>)
Detailed information about who are causing the performance is shown

2. Use Profiler, tracing whether there will be any other statements run before your simple
SELECT query

Thank you for your patience and cooperation. If you have any questions or concerns, don't
hesitate to let me know. We are here to be of assistance!


Sincerely yours,

Mingqing Cheng
Microsoft Developer Community Support
---------------------------------------------------------------
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

If there is no blocking going on, then this query (with your
description) should return instantaneous.

1. If the query

select count(*) from sometable (NOLOCK) where id=@SomeID

returns immediately, then you might be looking at a locking problem.

2. If the query

select count(*) from sometable where id=@SomeID OPTION(MAXDOP 1)

returns immediately, you might have hit the parallelism bug

3. the last interesting one would be

select count(*) from sometable (INDEX=0) where id=@SomeID


By the way: does your table by any chance have a nonclustered index, but
no clustered index? Just checking...

Hope this helps,
Gert-Jan



[quoted text, click to view]

--