well...the question is, did it lead to a sequencing/message number skip? if not, then you solved one problem! :)
the dead lock issue, i find that when i think of it like this, it helps me sometimes identify areas in my stored procs that could cause this...
-transaction 1 locks row 100 (does an update/insert/delete)
-transaction 2 locks row 200
-transaction 2 wants to do an update on on row 100, but now has to wait..
-transaction 1 wants to do an update on row 200, but now has to wait.
-deadlocked..they both wait endlessly for each other to commit/roll baack.
-the mighty hand sql-server chooses on as a deadlock victim
are there multiple updates happening within the transaction that could cause this? that's may be something to look at...