SyteLine: Transaction Deadlocked, Chosen as the Deadlock Victim

How to diagnose and reduce SyteLine deadlocks

1. 1Record the time, user, form and action when the 1205 error appeared.
2. 2Pull the deadlock report from the system_health extended events session using the query below, matching the timestamp.
3. 3Read the graph: identify the two victim and survivor processes, the resources (key, page, object) and the statements.
4. 4Map the statements to SyteLine: stored procedures such as posting, ship, or inventory routines, or a custom IDO method or event.
5. 5Check for missing or wrong indexes on the locked table; deadlocks on page locks often vanish with a better index.
6. 6If custom code is involved, make it touch tables in the same order as standard code and keep its transactions short.
7. 7Add a limited retry on the application or integration side for the victim transaction.
8. 8Consider read committed snapshot isolation only after testing and a conversation with Infor support.

Capture the deadlock graph

-- Recent deadlock graphs from system_health
SELECT CAST(xed.event_data AS xml) AS deadlock_graph,
       xed.timestamp_utc
FROM (
  SELECT CAST(target_data AS xml) AS td
  FROM sys.dm_xe_session_targets st
  JOIN sys.dm_xe_sessions s ON s.address = st.event_session_address
  WHERE s.name = 'system_health' AND st.target_name = 'ring_buffer'
) t
CROSS APPLY td.nodes('//RingBufferTarget/event[@name="xml_deadlock_report"]') AS q(n)
CROSS APPLY (SELECT q.n.query('.') AS event_data, q.n.value('(@timestamp)[1]','datetime2') AS timestamp_utc) xed
ORDER BY xed.timestamp_utc DESC;

-- Optional: write graphs to the SQL error log (turn off after capture)
DBCC TRACEON (1222, -1);

Common pitfalls

• !Treating a one-off 1205 as a bug when a retry would have succeeded; look for frequency and pattern first.
• !Leaving trace flag 1222 on permanently, which bloats the error log.
• !Adding indexes blindly to tables you do not own; test and document them.
• !Enabling snapshot isolation without checking tempdb sizing and vendor support.
• !Blaming SQL Server when the conflicting statement comes from a custom event or integration that holds transactions open.