Forum Discussion
Kudo CommanderPower BI refresh failing with SQL error 596 – “session is in the kill state”
Power BI refresh failing with SQL error 596 – “session is in the kill state”
Hi Community,
We are facing an intermittent Power BI dataset refresh failure with the following error:
Microsoft SQL: Cannot continue the execution because the session is in the kill state.
A severe error occurred on the current command. The results, if any, should be discarded.
(SQL Error Number: 596)
Environment details:
Data source: SQL Server (on-prem)
Accessed via: On-premises data gateway
Dataset contains large fact tables with joins and aggregations
Error occurs during scheduled incremental refresh (not every time) (schduled for every 2 hours once)
Questions to the community:
Is this purely a SQL Server–side issue, or are there Power BI–specific optimizations that can reduce the chance of session termination?
Are there recommended Power BI best practices to avoid SQL sessions entering a kill state?
Any guidance or real-world experiences would be greatly appreciated.
SQL error 596 (“session is in the kill state”) is fundamentally SQL Server side: it means the SQL session executing your refresh query was killed (explicitly via KILL, by a DBA/job, by failover, resource governor, timeouts/cancellation, or an underlying severe error that forces the session to die). Power BI / the gateway is just the client that happened to be using that session.
1) Make sure incremental refresh is truly folding
If your RangeStart/RangeEnd filter isn’t folding all the way into SQL, Power BI may pull far more data than expected, making queries slow/heavy and more likely to be killed. In Power Query, verify folding on the step that applies RangeStart/RangeEnd (View Native Query should be enabled).
2) Reduce refresh query cost (biggest “Power BI-side” win)
Avoid complex M transformations before the foldable filter.
Push heavy joins/aggregations into:
a SQL view
or (better) a stored procedure / prepared table
Keep the Power BI query as close to SELECT ... FROM <prepared object> WHERE Date between RangeStart/RangeEnd as possible.
Hi manoj_0911
SQL error 596 is fundamentally a SQL Server–side termination, not a Power BI bug, but Power BI refresh patterns can definitely make it more likely to happen. This error means the SQL session used by the gateway was forcefully killed while a command was executing, which commonly happens due to resource pressure (memory, tempdb, CPU), query timeouts, blocking, or an automated kill from SQL Server (for example via resource governor, maintenance jobs, failover, or monitoring tools). The reason you only see it intermittently during incremental refresh is that incremental refresh still runs heavy range-based queries and aggregations, and when these overlap with peak load, index maintenance, backups, or long-running blocking sessions, SQL may terminate the connection and Power BI surfaces it as error 596. From a Power BI side, the best mitigations are to ensure incremental refresh is truly folding to SQL (verify query folding), reduce transformations in Power Query, avoid unnecessary joins or calculated columns during refresh, and keep partition ranges small enough to limit each refresh window’s workload. On the SQL side, make sure the filtered date columns used for incremental refresh are indexed, check for blocking and deadlocks during the refresh window, review Resource Governor or any automated kill scripts, and confirm tempdb is not under pressure. In real-world setups, this issue almost always disappears once the SQL workload is stabilized and the refresh window is aligned away from heavy database activity, rather than by changing Power BI alone.
5 Replies
- tayloramy
Super User
HI manoj_0911,
This error is coming from your SQL Server source. Someone (or some automated process) with elevated rights to the SQL Server killed your session.
THis is not an issue with Power BI or Fabric. I recommend you reach out to your database administrator to investigate why your queries are getting killed.
- cengizhanarslan
SQL error 596 (“session is in the kill state”) is fundamentally SQL Server side: it means the SQL session executing your refresh query was killed (explicitly via KILL, by a DBA/job, by failover, resource governor, timeouts/cancellation, or an underlying severe error that forces the session to die). Power BI / the gateway is just the client that happened to be using that session.
1) Make sure incremental refresh is truly folding
If your RangeStart/RangeEnd filter isn’t folding all the way into SQL, Power BI may pull far more data than expected, making queries slow/heavy and more likely to be killed. In Power Query, verify folding on the step that applies RangeStart/RangeEnd (View Native Query should be enabled).
2) Reduce refresh query cost (biggest “Power BI-side” win)
Avoid complex M transformations before the foldable filter.
Push heavy joins/aggregations into:
a SQL view
or (better) a stored procedure / prepared table
Keep the Power BI query as close to SELECT ... FROM <prepared object> WHERE Date between RangeStart/RangeEnd as possible.
- Poojara_D12
Hi manoj_0911
SQL error 596 is fundamentally a SQL Server–side termination, not a Power BI bug, but Power BI refresh patterns can definitely make it more likely to happen. This error means the SQL session used by the gateway was forcefully killed while a command was executing, which commonly happens due to resource pressure (memory, tempdb, CPU), query timeouts, blocking, or an automated kill from SQL Server (for example via resource governor, maintenance jobs, failover, or monitoring tools). The reason you only see it intermittently during incremental refresh is that incremental refresh still runs heavy range-based queries and aggregations, and when these overlap with peak load, index maintenance, backups, or long-running blocking sessions, SQL may terminate the connection and Power BI surfaces it as error 596. From a Power BI side, the best mitigations are to ensure incremental refresh is truly folding to SQL (verify query folding), reduce transformations in Power Query, avoid unnecessary joins or calculated columns during refresh, and keep partition ranges small enough to limit each refresh window’s workload. On the SQL side, make sure the filtered date columns used for incremental refresh are indexed, check for blocking and deadlocks during the refresh window, review Resource Governor or any automated kill scripts, and confirm tempdb is not under pressure. In real-world setups, this issue almost always disappears once the SQL workload is stabilized and the refresh window is aligned away from heavy database activity, rather than by changing Power BI alone.
Hi manoj_0911,
I would also take a moment to thank cengizhanarslan , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference.
I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.
Regards,
Community Support Team.Hi manoj_0911,
I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We are always here to support you.
Regards,
Community Support Team.
