存储过程过于迅速地将控制权传回 - VB6

Question

我有一个存储过程正在更新一个非常大的表（超过1亿条记录）。存储过程正在更新此表中的记录。

步骤如下：

1. 在记录集中存储要更新的记录ID（并非所有记录都会更新 - 仅约20000）
2. 遍历记录集并为记录集中的每个记录ID调用存储过程
3. 每次存储过程完成时（对于第1部分中提到的记录集中的每个记录），更新表中的标志以表示更新已完成。

我发现了一些奇怪的行为。看来存储过程在完成更新之前将控制权传递回VB6并继续处理下一条记录。然后，存储过程稍后（在另一个记录ID上）超时。因此，即使存储过程没有运行（因为它超时），也有标记说更新（步骤3）。这是正常的行为，即存储过程在完成工作之前将控制权传递回VB6吗？

我已经用Google搜索了这个，我发现它可能是因为SQL Server优化了存储过程的方式。我希望在更新完成后，只能将控制权传递回VB6。情况不是这样吗？

请注意，我意识到可能有更好的方法来解决这个问题。我的问题具体涉及SQL Server在完成工作（更新）之前将控制权传递回VB6。

Answer 1

以下文章证明了这个问题的解决方案：http://weblogs.sqlteam.com/dang/archive/2007/10/20/Use-Caution-with-Explicit-Transactions-in-Stored-Procedures.aspx。看来发生了以下行为：

1）记录1.运行存储过程并创建事务。 SQL命令对象的超时发生者。 2）记录2.成功运行存储过程。将constrol返回到VB6以更新数据库中的标志。 3）记录3.成功运行存储过程。将constrol返回到VB6以更新数据库中的标志。 4）记录4.成功运行存储过程。将constrol返回到VB6以更新数据库中的标志。 5）程序结束。存储过程回滚事务（事务现在包含记录1-4）。因此，记录1-4不会被删除。

Answer 2

你能......

• 在sql management studio中运行代码，看看会发生什么并报告回来？如果是这样，我将更新这个答案，因为这将有助于我们了解它的代码/连接或sql。

其他要调查的事情，因为我们不知道你测试过的是什么情况......

• 在你的vb应用程序中使用相同的代码路径，并且只将存储过程中的sql更改为非常简单的东西，但具有与其正在执行的相同的签名（即/如果有读取则是/ basica读取，如果存在则基本删除正在删除，同样用于更新和添加）以查看会发生什么。

另外，其他一些想法......

• 如果你正在使用MSSQL，那就像有人打开查询窗口那样简单，它会占用数据库。这很容易测试。我之前遇到过同样的麻烦。我之前运行存储过程没有超时，通常会立即运行但是会在一夜之间运行而不会运行。只是为了实现另一个人打开他们的查询窗口。关闭他们的窗口和poof它终于运行。检查一下，它可能是一个表锁。无论是应用程序正在执行此操作，还是由另一个用户向数据库发出查询。检查以确保您的应用程序每次使用时都关闭与数据库的连接。