SQL Server存储过程直接调用正常，网站远程执行无插入无报错

嘿，这种本地跑正常但网站远程调用就掉链子的问题确实头疼，不过大概率是权限、事务隐式回滚或者上下文环境差异搞的鬼，咱们一步步来揪出问题：

1. 先盯紧远程调用的数据库账号权限 #

首先得确认网站连接数据库用的那个登录账号，有没有weatherdata表的INSERT权限——别以为另一个表能插就万事大吉，两个表的权限配置可能不一样。你可以跑这段SQL查一下：

USE 你的数据库名;
EXEC sp_helprotect @username = '网站用的登录账号', @objname = 'weatherdata', @grantorname = 'dbo';

另外也顺手确认下这个账号有没有该存储过程的EXECUTE权限，虽然其他功能正常，但多查一步没坏处。

2. 给存储过程加个错误捕获和日志 #

很多时候远程调用时出现了隐性错误，但存储过程没做处理，导致事务悄悄回滚，网站还收不到报错。你可以给存储过程套个TRY/CATCH块，把错误信息存到日志表里：

ALTER PROCEDURE 你的存储过程名
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRY
        BEGIN TRANSACTION;
        -- 你的插入逻辑
        INSERT INTO weatherdata (...) VALUES (...);
        -- 可以加个行计数返回，方便网站端确认
        SELECT @@ROWCOUNT AS 插入行数;
        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;
        -- 先自己建个ErrorLog表存错误信息
        INSERT INTO ErrorLog (错误时间, 错误信息, 错误编号)
        VALUES (GETDATE(), ERROR_MESSAGE(), ERROR_NUMBER());
        -- 也可以把错误抛回给网站
        THROW;
    END CATCH
END

这样远程调用后，去查ErrorLog就能看到具体哪里出问题了。

3. 检查SET选项的上下文差异 #

本地执行和网站远程调用的数据库连接SET选项可能不一样，比如ANSI_NULLS、QUOTED_IDENTIFIER这些，有些存储过程依赖特定选项才能正常跑。你可以在存储过程开头强制设置必要的选项：

ALTER PROCEDURE 你的存储过程名
AS
BEGIN
    SET ANSI_NULLS ON;
    SET QUOTED_IDENTIFIER ON;
    SET ARITHABORT ON;
    SET NOCOUNT ON;
    -- 后面的业务逻辑
END

也可以看看网站的连接字符串有没有特殊配置，比如ADO.NET里的Enlist=true可能影响事务上下文。

4. 验证插入数据的合法性 #

本地能插不代表远程传的参数没问题——比如非空字段传了NULL、日期格式不对、字段长度超限这些，都可能导致插入失败但没报错。除了上面加的@@ROWCOUNT返回，你也可以在存储过程里加参数验证，比如：

IF @某个必填参数 IS NULL
BEGIN
    RAISERROR('某个必填参数不能为空', 16, 1);
    RETURN;
END

5. 查SQL Server的系统错误日志 #

有时候远程调用的错误不会返回给网站，但会写到SQL Server的系统日志里。你在SSMS里找【管理】->【SQL Server日志】，翻一翻有没有相关的错误记录，比如权限不足、资源访问失败之类的。

6. 对比两个存储过程的差异 #

既然另一个上传xml到wsdatatemp的存储过程能正常跑，把两个存储过程的代码仔细对比下：

• 是不是weatherdata表有触发器？触发器执行失败会导致插入回滚；
• 是不是插入weatherdata的语句用到了本地资源（比如本地文件、链接服务器），远程调用时网站服务器访问不到；
• 事务处理逻辑有没有不一样？比如另一个存储过程明确提交了事务，这个没做？

按这些步骤排查下来，应该能很快找到问题根源。

内容的提问来源于stack exchange，提问作者Simon Mallett