The OUTPUT is an identifier for the trace you just created. You need to capture it as part of the execution, but you don't need to keep it unless you...

I'd definately check the execution plan on that. It might be easy to write and maintain, but I suspect it's doing multiple table scans. That's going to hurt, a lot.

Well, don't be stingy, show your solution.

First, look up JOIN syntax in the Books Online. You're using ANSI 89 syntax. Most database systems support ANSI 92 or better.

You must have more than one row in one...

Sorry I wasn't clear. I agreed with the outer join approach, assuming your indexes support it.

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.