Have you looked at the execution plan? You need to identify where the bottlenecks are occuring in order to know where to go to work. The others have pointed out...

I'm working up a comparison between TOP, MAX and ROW_NUMBER that addresses this problem. You can use all three. They have different strengths and weaknesses. You can use them as...

I'm working from home today so I don't have all my reference material at hand. If I miss a detail here & there, someone will correct me.

Select statements put a...

Sorry, I guess I wasn't clear, you don't need an UPDLOCK on the UPDATE because that's what it does. For example, and this is a bit contrived, you need to...

A select creates shared locks on the table. If you want to limit access as part of a single transaction, a good idea, you need to put a UPDLOCK hint...

Two things, get an index on the tables, especially a clustered index. Put that on the most likely access path, meaning, if they always select by PK, on the PK...

Problem is, in our shop, the developers jumped on it with both feet. It's everywhere. We're slowly backing it out. We get a lot resistance because using it allows for...

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...