.NET SQL Server DataAdapter 返回错误的字段类型？
我正在使用面向 .Net 2.0 框架的 Visual Studio 2010，连接到 SQL Server 2008。表中有一个类型为 varchar(50) 的名为 Box_no 的字段。该字段的内容大部分是数字，有些是空的。允许空值，但没有空值。
下面是查询该表并在网格中显示的代码（其他省略）：
DataTable dtRaw = new DataTable();
SqlDataAdapter sdaRaw;
if (rbRestrictCount.Checked)
{
sdaRaw = new SqlDataAdapter("Select top 50 * from MyTable where ID >= \'" + numericUpDown1.Value + "\' Order By ID",
Properties.Settings.Default.ConnStr);
};
sdaRaw.Fill(dtRaw);
dataGridView1.DataSource = dtRaw;
非常简单。问题是根据 ID 的值（即搜索从哪里开始），字段 box_no 有时以科学记数法显示 - 2.4e+.... 等 - 其他时候它显示为文本。它在表中明确定义为 varchar，但数据适配器在创建 DataTable 结构时似乎试图推断不同的字段类型。有什么办法告诉它不要这样做吗？
I'm using Visual Studio 2010 targeting the .Net 2.0 framework, connecting to SQL Server 2008. Have a field called Box_no of type varchar(50) in a table. The field's contents are mostly numbers, some are empty. Nulls allowed but there aren't any.
Here's the code which queries this table and displays in a grid (the else omitted):
DataTable dtRaw = new DataTable();
SqlDataAdapter sdaRaw;
if (rbRestrictCount.Checked)
{
sdaRaw = new SqlDataAdapter("Select top 50 * from MyTable where ID >= \'" + numericUpDown1.Value + "\' Order By ID",
Properties.Settings.Default.ConnStr);
};
sdaRaw.Fill(dtRaw);
dataGridView1.DataSource = dtRaw;
Pretty straighforward. The trouble is according the vaue of ID (i.e. where the search starts from), the field box_no is sometimes displayed in scientific notation - 2.4e+.... etc. - other times it displays as text. It's definitely defined as varchar in the table but it seems as if the data adapter is attempting to infer a different field type when it creates the DataTable structure. Is there someway to tell it not to do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在将其分配给数据源之前尝试此操作
try this before assigning it to the data source
抱歉，但已经发现了问题 - 科学记数法实际上在数据本身中 - 它是从 XLS 电子表格导入的，这似乎导致了 700K 记录中的 69K 条记录出现此问题。谢谢
Sorry but have found the issue - the scientific notation is actually in the data itself - it was an import from an XLS spreadsheet which seems to have caused this on 69K out of 700K records. Thanks