Thanks again for replying.

1. I originally wrote it as a single select. Unfortunately, the view has nolocks so SQL Server would put together the view first and then get information from the audit table, which was changed at the same time the view was put together, and join the data, which was then out of sync. As I explained in my earlier post, this created problems in our app. Using the temp table solved the problem, as much as it pained me to do.

2. The actual procedure doesn't use SELECT *; I just figured it was easier to read SELECT * than to list out all columns. I guess I forgot to add a comment saying that I had cleaned up code for that and other proprietary reasons.

3. I'll try without the convert. Will it be that much of a boost for the problem I'm having though?

4. Unfortunately, your suggestion won't work for us because this will only pull the last row changed and not all of the rows changed since the last time the proc was run. See 1 for the other reason I can't use it.

Here's an outline of the code fired. I realize that the first comments will be about optimization and other design issues that I've been trying to work around for awhile. Not much can be done other than what I'm already doing here due to a multitude of reasons. But the COMMIT TRAN clearly comes after all actions were done. The SELECT from the other procedure started in the middle of tran and ended after the COMMIT TRAN. The code is generated in the front end but it did properly put the transaction together properly.

BEGIN TRAN

INSERT INTO mt(...) VALUE (...)

EXEC proc

DELETE FROM A WHERE ... --triggers fired for changes table

DELETE FROM T WHERE ... --triggers fired for changes table

INSERT INTO mt(...) VALUE (...)

EXEC proc

DELETE FROM A WHERE ... --triggers fired for changes table

DELETE FROM T WHERE ... --triggers fired for changes table

INSERT INTO mt(...) VALUE (...)

EXEC proc

DELETE FROM A WHERE ... --triggers fired for changes table

DELETE FROM T WHERE ... --triggers fired for changes table

-- Changes proc fired here. Created Temp table by this point

INSERT INTO mt(...) VALUE (...)

EXEC proc

DELETE FROM A WHERE ... --triggers fired for changes table

DELETE FROM T WHERE ... --triggers fired for changes table

-- This was the record not included

INSERT INTO mt(...) VALUE (...)

EXEC proc

DELETE FROM A WHERE ... --triggers fired for changes table

DELETE FROM T WHERE ... --triggers fired for changes table

INSERT INTO T VALUES (...)--triggers fired for changes table

INSERT INTO A VALUES (...)--triggers fired for changes table

INSERT INTO DifferentTbl (...)

INSERT INTO DifferentTbl (...)

INSERT INTO DifferentTbl (...)

INSERT INTO DifferentTbl (...)

INSERT INTO DifferentTbl (...)

INSERT INTO DifferentTbl (...)

COMMIT TRAN

-- Insert into temp table in the other proc.

So, it seems what shouldn't happen with transactions is in this case. I guess I'll try to step through all of the different actions to do a closer lock analysis and see if anything rears its ugly head. But I know I'm missing something.