At the risk of sounding too much like Tech Support, do you have any triggers?

A deadlock happens when two process try to lock two tables in opposite order.  A trigger is one common way for tables to get locked in an unexpected order.

-- Bruce

Rule of thumb: disable the triggers individually to isolate the problem.

I may be mis-interpreting your error logs, but I would start by checking any triggers on your NAME_ADDRESS table.

Hope this helps -

ASI has added code to a trigger on the Name table to fix a prior problem with the system inserting duplicates into the Institute table, the trigger is:  asi_Name_Insert_update.  Here is what ASI told us:

"...back in 15.0 and 15.0.1, we had a defect where if you changed a Customer Type from a non-company type to a company type and then back to a non-company type, you will get duplicate rows on the Institute table. We modified the asi_Name_Insert_Update to fix the problem by adding the piece that we are now telling you to comment out.

Our fix for that other defect works fine for most client but causes the locking problem you are seeing for clients with high transactions/multiple users doing edits at the same time."

So the fix they added to the trigger appears to be causing our deadlocks. They suggest we comment the code out and then run a nightly procedure to fix the records in a batch mode rather than with every change on the name table. Here is what they told us:

"Edit the asi_Name_Insert_Update trigger to remove (comment out) this block of code from the very end of the trigger:

  IF UPDATE(MEMBER_TYPE) OR UPDATE(COMPANY_RECORD) OR UPDATE(MEMBER_RECORD)
   BEGIN
   EXEC [dbo].[asi_FixDuplicateIndividualRows]
 END

Then just set up a task to run that stored procedure (asi_FixDuplicateIndividualRows) on a regular basis (nightly, perhaps).

The cost of this is that if member types are updated back and forth between individual and company member types, there will be bad data in the database associated with those specific contacts until this stored procedure is run. If such modifications are never made (you never change a contact from a 'company' member type to a 'member' member type and back, or vice-versa), then you can eliminate the call to this stored procedure entirely....what a user might see if they change a member record's customer type from a non-company type to a company type and then back to a non-company type would be a CP shutdown and the error: Violation of PRIMARY KEY constraint 'PK_Institute'”
 

We are trying this in test before we apply to prod -

Jean B