C# 如何防止存储过程输入被自动截断？

我们使用标准的

System.Data

类和，从C#连接到SQL Server，并且我们有许多存储过程将

VARCHAR

或

NVARCHAR

参数作为输入。我们发现，当一个长度超过参数最大长度的字符串作为该参数的值传入时，SQL Server和C#应用程序都不会抛出任何类型的错误或警告。相反，该值会自动截断为参数的最大长度

因此，例如，如果存储过程输入的类型是

VARCHAR（10）

，我们传入

'U R PRETTY dumby'

，则存储过程将以

'U R PRETTY'

的形式接收输入，这很好，但完全不是我们想要说的

我在过去所做的检测这些截断的工作是使参数输入长度比所需长度大一个字符，然后检查输入长度是否等于新的最大长度。因此，在上面的示例中，我的输入将变成

VARCHAR（11）

，我将检查长度为11的输入。此检查将捕获长度为11或更长的任何输入。这是可行的，但感觉不对。理想情况下，数据访问层将自动检测这些问题

是否有更好的方法来检测提供的存储过程输入的长度超过允许的长度？

DbCommand

是否应该知道输入长度限制

另外，出于好奇，是什么导致我们的输入被无声地截断？

对所有变量和参数使用

VARCHAR（8000）

、

NVARCHAR（4000）

甚至

N/VARCHAR（MAX）

。这样，在分配@variables和@parameters时，您就不需要担心截断问题。截断可能发生在实际数据写入（插入或更新）时，但这并不是静默的，它将触发一个硬错误，您将发现它。您还获得了存储过程代码不必随模式更改而更改的额外好处（更改列长度，代码仍然有效）。通过使用一致的参数长度，还可以获得更好的计划缓存行为，请参见

---

请注意，对@variables/@参数使用MAX-types会对性能造成轻微影响，请参阅。

您是否可以摆脱字符限制，改用CHECK约束？@MikeChristensen-您是否可以稍微扩展一下您的意思？我们的表已经使用正确的数据类型（和长度）、FKs和

CHECK

约束进行了适当的约束。我所关心的是在我们在任何存储过程逻辑或查询中使用输入之前检测到超出限制的输入。你说的是存储过程参数。您可以将其设置为

VARCHAR（MAX）

，然后检查存储过程中的长度吗？是否可以有空格。。？？如果不是Nick，则使用装饰功能也很有帮助：