Check the execution plan. I'll be you're seeing tons of table or index scans.

You can't join outside the OUTPUT clause, but since you've put the records into a table variable (you might want to use a temp table for this instead) you can...

Just to be a bit contrarian, I agree with Jeff & Gail on TableA, but on Table B, I'd look at making the foreign key value from TableA the leading...

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.