[sims] Transaction was deadlocked on lock resources with another process and has been chosen

[kennysarmy]

Anyone seen this error before when just browsing for a student?

 

Transaction was deadlocked on lock resources with another process and has been chosen as a deadlock victim. Rerun the transaction: System Data SqlClientSqException.

[CamelMan]

Anyone seen this error before when just browsing for a student?

 

Transaction was deadlocked on lock resources with another process and has been chosen as a deadlock victim. Rerun the transaction: System Data SqlClientSqException.

Just started getting something similar on our Attendance officers machine: Transaction (Process ID 51) was deadlocked on thread | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

 

Only getting it when adding the attendance marks of students - did you find a resolution for this?

[Steve21]

KB50454 Transaction (process ID **) was dead locked on locked resources with another process and has been chosen as the dead lock victim re run the transaction

KBA-456956-T4B1V7

 

Notes

Transaction (process ID **) was deadlocked on locked resources with another process and has been chosen as the dead lock victim re-run the transaction

This error can occur during any process within SIMS .net

 

Workaround

This is caused by two users attempting to update the same SQL table at the same time. Re-try the process at a later time and the error will not occur.

 

"Working as intended" Might be two people trying to do same marks at once? Or think it's different issue? (Is an old KB in all fairness so guess could be a newer bug)

 

Steve

[ITGURU]

Sorry to bring up an old threat but found this result on a search on our SIMS issue. In the last few weeks, i've had users reporting the Deadlock Victim fault code and crashing SIMS.

On contacting Capita support they tell me it is NOT a database or software issue and happens if 2 or more users are attempting to update the same SQL table at the same time. Please restart the affected machine(s) and continue the process at a later time.

We've NEVER had this issue before, and the only change was a migration from SQL 2012 to SQL 2016.

Has anyone else seen this issur occur/increase since migrating to sql 2016?

[SpreadsheetJockey]

If it's only been in the last few weeks, perhaps your DM or equivalent may have been running bulk updates to student records etc. in relation to the school census?

[CAM]

It happens now and then. Working as intended (although the application could handle the error considerably better!)

[ITGURU]

All unrelated unfortunately. it happens early morning when our cover supervisor is in, even before other staff get logged on.

[cullingsh]

Does SIMS SQL 2016 instance still need to be run in sql 2012 compatibilty mode, and is it?

[ITGURU]

Not sure on that one! I'll have to check in the morning.

[zak786]

Hi all,

 

Just wondering if anyone got anywhere with this?

It's a constant issue in my school, happens even when only one user is on SIMS

[Jwadman]

Hi All,

 

Did anyone get to the bottom of this?

I have had extensive support from our support provider but we are still not any closer to resolving them.

 

We are getting these almost daily and we can't point to what may have changed.

 

We have changed times for all data extractor runs.

Support provider has gone into the logs and can see the two user ID's that are causing the deadlock but they dont correlate with any info that could tell us which user this is. (We know the one reporting the issue).

 

The three attendence users are all getting these deadlock errors, even when working in different tables (year groups).

 

We just ran an update on our SQL release last night (29th Novemeber). We were on 2012 with no service pack.

We've now been upgrade to SP4 and will monitor.

 

We are also having a patch made from SIMS to remove old intouch messages that are 3 years or older rather than the standard 1 year patch.

This is probably unrelated to our deadlock errors but we do have a large database size.

 

I'll keep you updated if any of the changes make a difference.