存储过程太快地将控件传回- VB6

Question

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

这些步骤如下：

1. 存储要在记录集中更新的记录ID (并非所有记录都将被更新--只有大约20000条记录)，通过记录集调用
2. 循环，并在存储过程结束时调用记录集
3. 中每个记录ID的存储过程(对于第1部分提到的记录集中的每个记录)，更新表中的一个标志以说明更新已完成。

我发现一些奇怪的行为。在完成更新并继续处理下一条记录之前，存储过程似乎正在将控制权传递回VB6。随后，存储过程将超时(在另一个记录ID上)。因此，即使存储过程没有运行(因为它超时了)，仍然有一些标志可以说是已更新的(步骤3)。这是否是正常行为，即存储过程在完成工作之前将控制传递回VB6？

我对此进行了搜索，我发现这可能是因为SQL Server优化存储过程的方式。我希望只有在更新完成后才能将控制传递回VB6。不是这样的吗？

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

Answer 1

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

1)记录1.运行存储过程并创建事务。出现对象的超时。2)记录2.成功运行存储过程。返回VB6以更新数据库中的标志。3)记录3.成功运行存储过程。返回VB6以更新数据库中的标志。4)记录4.成功运行存储过程。返回VB6以更新数据库中的标志。5)程序结束。存储过程回滚事务(事务现在包含记录1-4)。因此，记录1-4不被删除。

Answer 2

你能..。

• 在studio中运行代码并查看发生了什么并返回报告？如果是这样，我将更新这个答案，因为这将帮助我们理解它是代码/连接还是sql.

。

还有一些事情要调查，因为我们不知道你们检测的是什么.

• 在您的vb应用程序中使用相同的代码路径，只将存储过程中的sql更改为非常简单的内容，但具有与其所做的操作相同的签名(如有读取，即/ basica读取；如果有删除，则基本删除；更新和添加)，以查看发生了什么。

还有其他一些想法..。

• 如果您正在使用MSSQL，它就像有人打开查询窗口并将数据库绑定一样简单。这是很容易测试的。我以前也遇到过同样的麻烦。在此之前，我已经运行过存储过程，该存储过程通常会立即运行，但会在一夜之间运行而不运行。结果发现另一个人把他们的查询窗口打开了。关上他们的窗户，它终于跑了。看看这个，可能是个桌子锁。不管是应用程序在执行，还是由另一个用户对DB进行查询。检查以确保应用程序每次使用时都关闭到DB的连接。