# SyteLine Freezing for Everyone: Find the SQL Head Blocker > Source: https://netray.co/erp-help/syteline-sql-blocking-long-running-queries-diagnose > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer When several SyteLine users freeze at once, a single session holding locks and blocking a chain of others is a common cause. Query sys.dm_exec_requests for blocking_session_id, walk the chain to the head blocker, read its statement and open transaction, and decide whether to wait, fix the caller, or end the session. ## Kind how-to ## System syteline ## Erp Infor SyteLine (CloudSuite Industrial) ## Module SQL Server / Database ## Query SyteLine hangs frozen forms blocking session SQL Server how to find the blocker ## Alternate Queries - SyteLine form not responding waiting on SQL - find head blocker SQL Server SyteLine - SyteLine slow everyone frozen at once - sp_who2 blocked by SyteLine ## Applies To Infor SyteLine 8.x and CloudSuite Industrial on Microsoft SQL Server 2016 and later ## Steps ### How to find and handle the head blocker **Items:** - Confirm it is blocking and not a CPU, memory or network issue: ask whether many users froze on different forms at the same time. - Run the blocking query below on the SyteLine database server. - Find the session with no blocking_session_id that others point to; this is the head blocker. - Read its login, host, program and the text of its last statement, and check open_transaction_count. - Identify the owner: a user in the middle of a large post, a scheduled job, a report, an integration, or a forgotten open transaction. - If it is a legitimate long operation, wait or contact the owner. If it is idle with an open transaction, ask the owner to finish or close it. - Only as a last resort, KILL the session, knowing it rolls back and rollback itself can take as long as the work done. - Afterwards, find why the transaction was long: missing index, custom code, a report on the live database, or a nightly job overlap. ## Sections ### Blocking versus the other causes of slow **Body:** Blocking happens when one session holds locks on rows or pages that another needs. It looks like a frozen form with no error. The wait ends when the blocker commits, rolls back or disconnects. Compare this to deadlock, which resolves itself with an error, and to a resource problem, where everything is slow rather than stuck. A tell-tale sign is that some users are fine while others on the same table hang. Another is that the issue clears suddenly when someone closes a form or a job finishes. Checking wait types helps: heavy LCK_M_ waits point at blocking rather than CPU or disk. ### The query to run **Body:** This lists every request that is currently waiting on another session and shows what the blocked and blocking sessions are doing. Run it a few times a few seconds apart to see whether the same chain persists. A chain that persists for minutes with an idle head blocker is the case that needs human action. The idle-with-open-transaction pattern is typical of a client left open in the middle of a multi-step operation, or custom code that began a transaction and failed to commit on an error path. The session is sleeping, so no CPU use appears, but its locks remain. **Code:** -- Who is blocked and by whom SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time, DB_NAME(r.database_id) AS db, s.login_name, s.host_name, s.program_name, t.text AS running_sql FROM sys.dm_exec_requests r JOIN sys.dm_exec_sessions s ON s.session_id = r.session_id CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t WHERE r.blocking_session_id <> 0; -- Inspect a suspected head blocker (replace 123) SELECT s.session_id, s.status, s.login_name, s.host_name, s.program_name, s.open_transaction_count, c.most_recent_sql_handle FROM sys.dm_exec_sessions s JOIN sys.dm_exec_connections c ON c.session_id = s.session_id WHERE s.session_id = 123; ### Deciding whether to kill **Body:** Killing is not free. SQL Server must roll back everything the session did inside its open transaction, and for a big posting that can run longer than the original work, during which the locks are still held. Check progress with KILL 123 WITH STATUSONLY rather than killing again. Never kill a session without knowing its owner and what it was doing, especially a posting, cost or MRP process, since the application may leave partial data that its own retry logic expects. Prefer to have the owner stop it from the application. Treat KILL as an incident action and log who ran it and why. ## Pitfalls - Killing the first blocked session instead of the head blocker; the chain remains. - Running large reports or exports against the live transactional database during posting hours. - Repeating KILL on a rolling back session; check STATUSONLY instead. - Missing that the head blocker is a sleeping session with an open transaction because it shows no CPU. - Restarting the application server, which drops clients but may leave SQL transactions to roll back on their own timeline. ## Ai Angle SyteRay can run this kind of read-only DMV query on request and answer in plain terms: who is the head blocker, what they were running, how long, and who likely owns it, so the first five minutes of an incident are not spent writing SQL. It does not kill sessions. Ending one remains a human decision with a named approver. ## Faq ### How is this different from the deadlock error? **Answer:** Blocking has no error: a form just waits until the blocker finishes. Deadlock is a circular wait that SQL Server breaks by rolling back one session and raising error 1205. The investigation differs too. Blocking needs a live look at the chain, deadlock needs a captured graph. ### Why does the blocker show as sleeping? **Answer:** The session finished its last statement but never committed or rolled back, so it holds locks while doing nothing. This is typical of a client waiting for user input mid-transaction or custom code that skipped a commit on an error path. ### Can reports cause this? **Answer:** Yes. A large report or SSRS query using locking reads on busy tables can block postings, and postings can block the report. Point reports at a replica or reporting copy where possible, and avoid running heavy ones during peak transaction hours. ### Does rebooting fix it? **Answer:** It clears the blocking by dropping connections, but the cause returns. Without finding the statement, the owner and the reason it held locks so long, you will meet the same chain again, probably at a worse time. ## Search terms syteline freezing, syteline form not responding, sql server head blocker, sys.dm_exec_requests blocking_session_id, syteline blocking session, sp_who2 blocked, syteline slow sql, kill session rollback status only --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json