your best bet is to have an identity field as your PK and a non-clustered index that's imported in. The advantage here, is that you can import the data,...

but an auto-number should be present for easier dba operations.

The tolerance thresh hold, while waiting for a response from a computer, is about 3 seconds. I know I am guilty of having processes that run longer than 16...

won't there be performance issues with this? just wait for them to have problems and you will be their messiah when the sh!t hits the fan. It will...

understood, but the NOLOCK is fine for me 😉

I appreciate your help, but using UPDLOCK on the joining tables has caused me more pain.

I am using:

DECLARE @val bigint

--assuming T1 and T2 were just inserted into/update with...

could be fun. so, basically...

UPDATE Table1

SET ...

FROM Table1

INNER JOIN #UPD_TEMP

ON Table1.ID = #UPD_TEMP.ID

I'll discuss that with my colleagues. It may be excessive, like you said because I put...

usually between 1 and 10 after the filtering is done.

I have about 30 update and insert statements that don't want to play nice with each other. Some derived, and others join a series of inner and left joins....

yeah, I used UPDLOCK at first. The description Microsoft gives for this lock is very deceiving. It caused more deadlocks for me, because it would still lock the...

that is how I determined it was Page locks.

It basically makes sure that any previous transactions finnish before proceeding. The "READCOMMITTED" won't allow a dirty read. So then I can do a "NOLOCK" below, because I...

ok I did something like this (and I have a feeling I am going to get flack for it)....

DECLARE @val bigint

SELECT @val=COUNT_BIG(*) FROM Table1 WITH (READCOMMITTED)

UPDATE...

I stripped all the transactions out, but thanks.

I am working on something that I think will alieviate this problem, but I have to wait for "peak time" to see if...

if he can't add the field he needs to use temp tables