Server :分布式事务冲突

Question

给定一个SQL脚本：

1. 开始交易。它是从服务器X启动的
2. 从涉及表A到表B的查询中选择into (=新表)
3. 在表C中选择表A (=新表)
4. 提交。

没有错误发生。这还不是一个分布式事务，因为所有事情都发生在一个服务器上。

现在假设3变成：

1. 在表C中选择表A，但表C位于不同的服务器上(我必须通过EXECUTE('SELECT * INTO ...') AT [remoteserver]实现这一点，因为在FROM子句中允许使用3前缀语法，而在into子句中不允许)

现在Server告诉我，这个语句(3)与(现在是分布式的)事务中的另一个语句生成冲突。

为了向您展示错误的来源，并证明分布式事务确实在我的设置上有效，我现在注释掉步骤2)！

现在整件事都成功了。因此，第二步)使问题发生。但是步骤2)基本上只对表A和一些其他表进行连接选择，以生成表B，而不生成其他任何内容。

在这种情况下(在分布式事务版本中)，为什么步骤3)不能执行而没有问题，但是相同的非分布式事务版本工作得很完美？可能会有什么冲突？

Answer 1

好了伙计们。发现了这个问题，而且很有趣。是另外一回事。我没有提到，没有提到我也创建了表A，因为我认为它与问题无关，所以：

将步骤2)替换为

2) Create Table A **with** a primary key.

现在，非分布式版本工作，分布式版本执行而不是(即步骤3)。

将步骤2)替换为

2) Create Table A with **no** primary key

现在，和两个版本都可以正常工作。

但我并不在乎，因为当我用创建表时，整个过程也会正常工作，在事务的之前，是一个主键。它只是使用create语句在中创建主键事务导致分布式版本无法工作。

如果有人知道为什么，请在这里写:)

Answer 2

看起来查询2和查询3不兼容。要找出原因，请调查每个查询所导致的锁。这样做的一种方法是：

1. 开始交易
2. 运行查询2(或3)
3. 可以在视图sys.dm_tran_locks中找到锁。
4. 回滚或提交，不重要

也许你可以在你的问题上附加由此产生的锁？