从 MS Access 执行存储过程导致超时

Posted 2023-05-07

【中文标题】从 MS Access 执行存储过程导致超时

【英文标题】：Executing Stored Procedure From MS Access Causes Timeout

【发布时间】：2016-03-14 00:18:57

【问题描述】：

最奇怪的事情。我有一个使用 SQL Server 2012 后端在 Microsoft Access 2010 中开发的简单程序。我现在正在尝试将其部署到生产环境中，即 Access 2016 和 SQL Server 2014 后端。

我已经在新环境中编译、压缩和修复了...但是我无法让Access执行这个简单的存储过程。更糟糕的是，它仍然可以很好地执行其他几个存储过程......但是其中一些它超时并拒绝执行？

这是我的 VBA 和存储过程：

 Private Sub GenerateUnitKey(UnitColumns As String)
    Dim Msg, Style, Title, Response As Variant
    Dim lngProcessID As Long
    Dim Conn As ADODB.Connection
    Dim Cmd As ADODB.Command
    Dim CurrentConnection As String

    CurrentConnection = LinkMasterConnection()

    Msg = "Are you sure you want to update the UnitKey with the selected columns?"
    Style = vbYesNo + vbCritical + vbDefaultButton2
    Title = "Save Campaign?"
    Response = MsgBox(Msg, Style, Title)

    If Response = vbYes Then
    Call OpenSixHatLoader("Generating Unit Key Across Campaign Records", 1, "")

    Set Conn = New ADODB.Connection
    Conn.Open CurrentConnection
    Set Cmd = New ADODB.Command
    With Cmd
        .ActiveConnection = CurrentConnection
        .CommandText = "usp_GenerateUnitKey"
        .CommandType = adCmdStoredProc
        .CommandTimeout = 30
        .Parameters.Append .CreateParameter("@UnitColumns", adVarChar, adParamInput, 4000, UnitColumns)
        .Execute
        End With
    End If
End Sub

和存储过程：

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[usp_GenerateUnitKey]
@UnitColumns AS VARCHAR(4000)
AS      
SET NOCOUNT ON
DECLARE @SQL AS VARCHAR(MAX)
UPDATE tblStagingTable SET UnitKey =''

SET @SQL = 'UPDATE tblStagingTable SET UnitKey = ' + @UnitColumns + ' FROM tblStagingTable st'
EXEC(@SQL)

-- UPDATE Interests to match Staging Table
UPDATE tblInterests SET UnitKey = st.[UnitKey] FROM tblInterests i
INNER JOIN tblStagingTable st ON i.StagingTableID = st.StagingTableID 

我相当有信心代码没有任何问题...正如我所说的那样，它在我的开发环境中运行良好...而且我可以手动执行 SQL Server 中的存储过程。我的 SQL Server Native Client 11.0 连接在执行其他存储过程时工作......但对于其中一些它不起作用。我想我需要在 SQL Server 本身或 Native Client 11.0 驱动程序中配置一些东西？

不幸的是，它也不例外。我已将 CommandTimeout 属性设置为 0 并让它运行几个小时，希望它会抛出异常并给我一个线索，但什么也没有……它只是在试图执行时被冻结。任何建议或想法都将不胜感激，因为这让我非常难过，因为它应该没问题！

【问题讨论】：

冻结在哪一行代码？

首先想到的是you should not be naming your stored procedures with an "sp_" prefix。很长一段时间以来一直不鼓励这种做法，但也许在您的生产环境中使用新（更）版本的 SQL Server，这已成为一个问题。

@HansUp 在 .Execute 行。

@GordThompson ... 很有趣。我以前从未听说过，尽管我确实记得在过去的几年里，一位雇主将 sp 的命名约定改为以 usp 为前缀。我从来不知道为什么......但也许就是这样？我一定会阅读这篇文章，谢谢

当您的 Access 代码冻结时，SQL Server 端发生了什么？

【参考方案1】：

我会先启动 SSMS，然后从 SQL 工作室输入 执行 xxxxx ''

并确保它运行（并使用您当前用于 Access 的 SAME 登录和连接到 SSMS。

我还会考虑创建一个传递查询，并将该查询保存在访问权限中。 （如果 sp 不返回记录，则设置返回记录 = false）。然后在代码中运行任何 proc，你可以去：

With CurrentDb.QueryDefs("qryPass")
  .SQL = "exec usp_GenerateUnitKey '" & UnitColumns & "'"
  .Execute
End With

您注意到上面的代码是多么简单 - 所以如果 sp 在 SSMS 中工作，那么试试上面的代码。

【讨论】：

感谢您的回复。是的，它确实可以从 SSMS 执行。我现在就试试你的方法。

我赞成响应和替代解决方案，但不幸的是它有同样的问题:(

这可能与服务器是虚拟机这一事实有关吗？

【参考方案2】：

这是一个困难的问题，我花了大约 3 天的时间进行故障排除才能找到解决方案。虽然我对最终解决方案不满意，因为它应该刚刚工作......但最终我的服务器是虚拟机的理论被证明是正确的。当我在专用服务器上将完全相同的设置部署到 Microsoft Access 2016 32 位和 SQL Server 2014 32 位时，与我尝试部署到的 Azure VM 和 1&1 云服务器相比，它的工作方式完全符合预期。

SQL Server 与 VM 的集成从我所读到的所有内容中变得越来越好，但显然还有一段路要走。也许 SQL Server 需要发布一个特殊的 VM 版本。感谢所有花时间研究此问题的人。