I don't normally ignore Gail's requests, but in this case, I could not resist:

http://www.sqlservercentral.com/Forums/FindPost708104.aspx

Ensure your sarcasm detectors are buffered against overload before reading.

Paul

Oh well that's ok then! :doze:

At least you didn't cross-post above the allowable of maximum of...hey...where is that...

Morning Flo!

It is a lovely sunny and crisp day in Wellington. The sunlight is sparkling off the sea in the harbour, and all is good with the world.

I hope...

Here's another approach (using a large hammer):

DECLARE@sql VARCHAR(500);

SET@sql = 'ALTER DATABASE ' + DB_NAME() + ' SET RECOVERY BULK_LOGGED;'

EXECUTE(@sql)

IF@@error != 0 RETURN;

;WITHCTE (UserID, SeqNo, UserName, LastLoggedIn) AS

(

SELECTUserID,

ROW_NUMBER() OVER (PARTITION...

Do you recall I said something about example code...? 😉

Paul

Good point Flo!

Unless you use the solution posted by Lynn...

Saints be praised 😉

Wayne,

With an empty proc cache, isn't that what you would expect?

Once the proc in question has run once, you should see a cache hit instead of a cache miss with...

We're testing some fusion drives at the moment.

I am not aware of a way to do that directly, and judging by the lack of response, neither is anyone else.

If it disturbs you that much, consider starting jobs...

You should install the tools 'on top' of the existing installation and then re-install the service packs and cumulative updates to bring everything up to the latest available.

Paul

Your select will probably be taking Shared locks on the data as it reads it in. Shared locks are incompatible with the update and exclusive locks that the updates...

It is probably because the batch needs to be compiled and the data it needs might not be in memory. Once you have run it once, the chances are...

See this article[/url] on SQL Server Central by Ian Stirk for some ideas and example code.

Paul