Asp.net SQL事务：TSQL与VB.NET？

我们正在跟踪一个应用程序中的严重超时错误

我想知道在应用程序中使用SQL事务与使用TSQL语句写入存储过程有什么区别（如果有）。我们需要重新构造存储的进程和vb代码，以使其正常工作，我不确定这是否值得目前的努力

Public Sub RetrieveTData(ByVal cID As String, ByVal cnn As SqlConnection) As Boolean

    Dim sqlTran As SqlTransaction
    cnn.Open()
    sqlTran = cnn.BeginTransaction

    Try
        If Not DataAlreadyTransferred(cID) Then

            Dim Command As New SqlCommand("usp_BigNasty_CopyDataFromDB1toDB2")
            Command.CommandType = CommandType.StoredProcedure
            Command.Transaction = sqlTran
            Command.Parameters.AddWithValue("@cID", cID)
            Command.Connection = cnn

            Command.ExecuteNonQuery()
            sqlTran.Commit()
        Endif

    Catch ex As Exception
        sqlTran.Rollback()
        Throw
    Finally
        cnn.Close()
    End Try

End Sub

由于try/catch是如何编写的，我们无法确定超时是否发生在

datareadyTransfered（）

或

usp\u bigstary\u CopyDataFromDB1toDB2

中。我们可以重新构造此代码，但需要一周左右的时间才能将其投入生产（今天的test/dev没有出现错误）

DB1—其他应用程序也使用的永久存储
DB2—工作集，仅由Web应用程序使用

DataAlreadyTransferred（cID）

首先检查DB2是否有记录的副本，如果DB2有，并且这些记录是干净的，则删除它们（数据可能在DB1中发生了更改，我们需要最新的版本）。如果DB2的数据是脏的，则不删除任何数据

usp_bigstary_CopyDataFromDB1toDB2

从大约20-30个不同的表中复制行，并通过perm副本将行从DB1复制到DB2，基本上创建了一个工作集，Web应用可以从中访问

我们意识到这是低效的，正在研究改进的方法，只是还没有时间

我相信，通过在应用程序代码中包含事务，它锁定了比实际需要多得多的表。如果我们将它们移动到存储过程中，一次锁定的表就会减少，从而提高了我们消除今天所看到的死锁条件/超时问题的机会。只是对这件事不太确定

---

感谢您的支持。

您的交易在往返和多次通话中的开放时间超过了需要的时间

我建议使用单个存储过程来测试、清理和写入=对服务器的一个原子调用

---

我也会考虑复制来保持数据的实时性，甚至DB2也包含DB1。让DB引擎来做吧？

进一步调查后，我们发现许多涉及的表上没有索引。在为这个过程中涉及的查询创建了推荐的索引之后，我们的超时问题似乎消失了（现在）

---

我仍将研究优化整个过程，因为它的数据量仍然非常缓慢…

我们目前正在考虑将应用程序代码移动到单个存储过程中，这可能最终成为这里的最终解决方案，在这种情况下，我还希望交易在该过程中，而不是在应用程序代码中。。另外，DB2是DB1的一个小得多的子集，否则我会像您建议的那样在一开始就推动复制。