为什么从ASP.net调用存储过程时会忽略alter约束？

因此，我有一个执行以下操作的存储过程（修改了数据参数）：

这都在一个存储过程中，当我从ManagementStudio执行它时，它运行得非常好，但当从ASP.net调用它时，它跳过了alter约束。我知道它至少在执行存储过程，因为我收到一条消息说更新与约束冲突

---

作为记录，我知道这一切都可以通过更新级联解决，但该选项被上层管理层拒绝

当您使用ManagementStudio执行存储过程时，这是在您的帐户下完成的，该帐户可能具有管理员权限

---

当您从asp.net执行sp时，您可能使用了另一个帐户，这是不允许的。

您肯定是在调用该存储过程，而不是另一个存储过程，或者更糟糕的是，代码中应该指向该过程的某些内联SQL？从ManagementStudio和ASP.NET运行该过程应该没有任何区别……它们是该过程的唯一行吗？如果是这样的话，第二个alter不会总是抛出一个错误吗？可能是执行此操作的帐户的权限问题。集成安全设置为true，因此它们可能都是通过我的Windows帐户进行的。我会再核实一下。但是，这难道不会使整个存储过程崩溃，而不仅仅是它的一部分吗？或者，它会一直收费，直到找到权限范围内的内容吗？如果帐户有权执行该过程，但没有更改权限，则不会。所以是的，@Hans Kesting的回答似乎很有可能。我以为integrated security=true使用了我的Windows帐户？与management studio中用于成功运行存储过程的Windows帐户相同。编辑：刚刚在服务器档案器中检查了它，ASP.net和ManagementStudio都使用相同的登录信息运行。不管怎样，我解决了问题。这个存储过程实际上运行得很好，它之前的那个被弄糟了。问题在于，只有在与运行此存储过程相同的条件下，前一个存储过程才会抛出错误。如果子表中缺少条目，则不会抛出错误。对不起，浪费了你的时间。

ALTER TABLE dbo.ReceiptInfo NOCHECK CONSTRAINT Credits_ReceiptInfo_FK1;
UPDATE ReceiptInfo SET CreditAccount=@CreditAccount WHERE  CreditAccount=@OriginalAccount;
ALTER TABLE dbo.ReceiptInfo CHECK CONSTRAINT Credits_ReceiptInfo_FK1;