ta for the update - this is still running without issue

rebuilt properly (using record id for all selects/updates/inserts) - and been running for a while with no deadlocks.... still dont understand what was causing them though as the ids were...

ya i got to that - going to rebuild using recordid as key as will be quicker than trying to work out what the hells happening here as am really...

the uniqueness of that column is handled from my app - as you can see from deadlocks - it is always using different id's

tbl is for a temp quick and dirty process I am running - max 90k records - default value for user id is '-'

as such no unique index, just added...

hmm - seems to still deadlock - normally against itself:

Deadlock graph150823671sa0X0116

2015-06-12 11:31:09.347<deadlock-list>

<deadlock victim="processa58e3048">

<process-list>

<process id="processa58e3048" taskpriority="0" logused="2204" waitresource="RID: 29:1:11558:16" waittime="2754" ownerId="2184117293" transactionname="user_transaction" lasttranstarted="2015-06-12T11:31:06.563" XDES="0xaf8403b0" lockMode="U"...

not sure where my deadlock post has gone with the graph attached (prehaps some sort of review)

anyway - graph showed it was conflicting with a similar proc (markascomplete) used the...

fyi deadlock graph attached

the 2 conflicting statments in this instance are:

303: MarkAsCompleted 'C0239484'

192: MarkAsKO 'C0239494'

As such seems to be conflicting with another proc - im reviewing now

sorry for delay - my profilers not picking up the graphs - will ppost soon - the deadlock issue is worse with the new code

Should be ok - as stated each user will only ever have 1 record locked 😀

spaghettidba (6/12/2015)

---

BTW, your code assumes that only one row at a time can be...

thanks guys, going to try spaghettidba solution - alos have started a profiler so will post a graph as soon as it occours again.

Ta

i have a feeling with(nolock) could be causing this!!

mutant ants 😀 - any guidance on why it shouldnt be used (does it have monsterous overhead or something), or is it just as it forces 1 read at a...

thanks - i have opted for slightly simpiler way of doing it:

using the app lock sp - basically queues up the calls to proc so only 1 user can use...