Holy cow! You guys posted all that in the time it took me to read the first couple of posts. Slow down doggone it. You're making me look more stupid...

You set a stop time as part of the trace definition. That will stop the trace automatically for you.

From the BOL:

sp_trace_create [ @traceid = ] trace_id OUTPUT

...

Not if it's working off a good set...

It sure looks like you could just use the ROW_NUMBER function to get the incremental counts that you want instead of looping through with a cursor or a WHILE loop...

Nice one AJ.

After you recover and you set up new backup routines, in addition to msdb, be sure to backup the master database too.

Good luck.

From what I've seen in the past with duplicate indexes, the optimizer will just pick one. To realize the use of two, you'd have to have an index hint forcing...

Itzik Ben-Gan gave a presentation last year at the PASS summit that showed the same query getting different results with very small data sets, all because of NOLOCK. It really...

But even the read contention is only halved unless the index is covering. If it's not covering it still has to go to the table or the cluster to get...

It should work. Are you sure you're in the right database? Are you looking through Management Studio? You might need to refresh in order to see the change.

Yeah, I've got them ethics things too. That and there seem to be laws against using sticks on the students. When did that happen?

Just so long as you quantify your post to read "some knowledge" because I'm basically a newbie on SCOM myself. I've been working with it for, probably close to three...

Try modifying this query to exclude specific tables:

SELECT QUOTENAME(TABLE_SCHEMA) AS schemaname, QUOTENAME(TABLE_NAME) AS name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE'

Quick and dirty would be like this, Jeff will come...

Some operation within your code is attempting to perform math functions and it's dividing by zero. You need to determine which field is causing the problem. Without your code, data,...

I don't know if there is another forum for it. I've posted my own questions here.

Getting specific information regarding SQL Server and SCOM is tough. Definately you want to look...