SSRS 报告调用的存储过程中的事务处理是什么？

Question

考虑以下：

CREATE PROCEDURE dbo.usp_trantest AS
SELECT @@TRANCOUNT as trancount;
GO

当我usp_trantest从 SSMS 中手动调用时，trancount 为 0。如果我运行包含查询相同存储过程的数据集的 SSRS 报告，则 trancount 记录为 1。

执行 SSRS 方法的 T-SQL 跟踪显示存储过程调用的跟踪事件，该事件与我从 SSMS 所做的相同。

是否有一些行为可以根据 SSRS 上下文而改变？比如，为动态 sql 调用或其他东西打开一个隐式事务，或者 SSRS 在 T-SQL 之外创建一个事务上下文？

编辑：

在某人（谢谢，陌生人！）的现已删除的答案中，建议 SSRS 报告的数据集可能已选中“处理查询时使用单个事务”。原来如此！

我做了一些进一步的测试，在未选中此设置的@@TRANCOUNT情况下，无论是在 SSMS 中运行还是从 SSRS 报告中运行都是一样的。

因此，我们似乎可以得出结论，此数据源设置确实会导致 SSRS 报告在运行查询之前在数据库上创建事务上下文。由于这个额外的事务没有出现在 T-SQL 跟踪中，我们可以假设它是使用 API 方法而不是 T-SQL 语句打开的。

Answer 1

在 SSRS 报告的数据源上，有一个属性“处理查询时使用单个事务”。有几种不同的行为与标记此复选框相关：

1) 正如您所注意到的，如果选中此复选框，SSRS 将使用显式事务来处理使用此数据源的数据集。当没有标记时，没有显式交易。

2) 如果未选中此复选框，则使用数据源的数据集将使用与服务器的单独连接并行执行。如果选中该复选框，则数据集将使用单个连接并按顺序进行处理。

此外，使用此复选框可能有不同的动机。其中两个主要是：

1）读取一致性：如果您使用快照隔离，您可能希望所有数据集在单个时间点上保持一致。在这种情况下，使用单个显式事务并使用快照隔离级别可以确保事务内的所有语句与单个时间点一致。

2)性能：根据多种因素（这实际上是一个单独的主题），您可能会发现并行运行不同数据集的查询与串行运行不同数据集的查询之间存在巨大的性能差异。