当我输入超过列长度的数据时,它不会在 ASP.NET 中引发异常
问题很简单。
我的数据库中有一个数据类型为 NVARCHAR(20) 的列。因此,当我尝试在此列中输入包含 22 个字符的数据时,它只会忽略最后 2 个字符,而不是引发异常!
这是正常现象吗? ..以及如何保护数据库免受此类问题的影响?
PS:当然我使用验证控件和服务器验证,但是如何保护数据库,是否有某种高级约束不仅仅是指定列的长度,因此它会抛出异常并且不接受输入的日期?
编辑
try
{
using (SqlConnection conn = new SqlConnection(ConnStr))
{
string Command = "SET NOCOUNT ON; INSERT INTO [Countries] (CountryName, IsVisible) VALUES (@Name, @IsVisible);";
using (SqlCommand comm = new SqlCommand(Command, conn))
{
comm.Parameters.Add("@Name", System.Data.SqlDbType.NVarChar, 20);
comm.Parameters["@Name"].Value = Name;
comm.Parameters.Add("@IsVisible", System.Data.SqlDbType.Bit);
comm.Parameters["@IsVisible"].Value = IsVisible;
conn.Open();
comm.ExecuteNonQuery();
return "Successfully added " + Name + " to the countries.";
}
}
}
catch (SqlException SqlEx)
{
string ErrorMessage = "";
for (int i = 0; i < SqlEx.Errors.Count; i++)
{
ErrorMessage += SqlEx.Errors[i].Number + " : " + SqlEx.Errors[i].Message + "\n";
}
return ErrorMessage;
}
嗯,这是我正在使用的代码,顺便说一句,我只是尝试直接从 Sql Management Studio 插入比列长度更大的数据,它实际上显示了您刚才描述的消息!
The question is simple.
I have a column in my database of data type NVARCHAR(20) .. so when I try to enter a data in this column that's for example contains 22 characters, it just ignores the last 2 characters instead of Throwing an exception!
Is this is normal ? .. and how to secure the database from such an issue ?
P.S: Of course I use validation controls and server validation, but how do I secure the database, is there's some kind of an advanced constraint more than just specifying the column's length, so it throws an exception and not accept the entered date ??
Edit
try
{
using (SqlConnection conn = new SqlConnection(ConnStr))
{
string Command = "SET NOCOUNT ON; INSERT INTO [Countries] (CountryName, IsVisible) VALUES (@Name, @IsVisible);";
using (SqlCommand comm = new SqlCommand(Command, conn))
{
comm.Parameters.Add("@Name", System.Data.SqlDbType.NVarChar, 20);
comm.Parameters["@Name"].Value = Name;
comm.Parameters.Add("@IsVisible", System.Data.SqlDbType.Bit);
comm.Parameters["@IsVisible"].Value = IsVisible;
conn.Open();
comm.ExecuteNonQuery();
return "Successfully added " + Name + " to the countries.";
}
}
}
catch (SqlException SqlEx)
{
string ErrorMessage = "";
for (int i = 0; i < SqlEx.Errors.Count; i++)
{
ErrorMessage += SqlEx.Errors[i].Number + " : " + SqlEx.Errors[i].Message + "\n";
}
return ErrorMessage;
}
Well this is the the code I'm using, and btw I just tried to insert a bigger data than the column's length directly from the Sql Management Studio and it actually displayed the message you were just describing!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
问题出在这两条线之间。
SQL Server 永远不会看到超过 20 个字符。 .Net 正在进行截断。
我不记得 SQLParameter 的文档,Google 搜索更快。
http://www.eggheadcafe.com/software/aspnet/30873895/sqlparameter -问题.aspx
The problem is between these two lines.
SQL Server NEVER gets to see more than 20 chars. .Net is doing the truncation.
I can't remember the documentation for SQLParameter, a Google search was faster.
http://www.eggheadcafe.com/software/aspnet/30873895/sqlparameter-question.aspx
有几个区域会在数据到达表之前截断数据,而不会产生错误。
正如 @Richard 针对您的具体情况指出的那样,它正在被 ADO 截断。
如果调用具有 varchar(20) 参数的存储过程并向其传递 22 个字符的数据,SQL Server 中的参数处理引擎也会截断它。
但是,如果您编写的插入状态尝试直接将 22 个字符填充到 varchar(20) 列中,那么您将看到错误。
基本上,参数处理块正在默默地“修复”它。然而如果你去掉参数那么它就会失败。这就是为什么这个问题实际上与@gbs 引用的问题完全相同。
显然,摆脱参数远非理想。
There are several areas that will truncate the data prior to it reaching the table without generating errors.
As @Richard pointed out for your specific case it is being truncated by ADO.
If you called a stored procedure that had a varchar(20) parameter and passed it 22 characters of data, the parameter processing engine in SQL server would truncate it as well.
However, if you wrote an insert state that tried to directly stuff 22 characters into a varchar(20) column, then you would see the error.
Basically, the parameter processing piece is silently "fixing" it. Whereas if you get rid of the parameters then it will fail. Which is why this question really is an exact duplicate of the one @gbs referenced.
Obviously, getting rid of the parameters is FAR from ideal.