SSIS中ADO NET连接正常但OLE DB报错，删除CSV随机行后恢复

核心原因分析 #

• OLE DB与ADO.NET的类型推断逻辑差异
  OLE DB驱动（如Microsoft SQL Server Native Client或ACE OLEDB Provider）默认仅采样CSV的前8行来推断列数据类型。如果前8行中某列的取值均为数字/日期，但后续行出现字符串、特殊字符等不符合推断类型的值，就会触发Invalid character value for cast specification转换错误。而ADO.NET的类型推断逻辑更宽松，会保留更多字符串类型或自动兼容混合格式，因此不会报错。

• Excel保存CSV时的隐性修复
  用Excel打开CSV并删除任意行后再保存，Excel会自动完成以下操作：

  • 规整换行符（如将LF转为CRLF）或修复行内格式错误（比如不闭合的引号）；
  • 改变OLE DB的采样范围：删除一行后，原本超出前8行的异常数据行进入采样范围，驱动会重新推断正确的列类型；
  • 清除隐藏的控制字符，这类字符在OLE DB转换时会被误判为非法值，但ADO.NET可正常处理。

实用解决办法 #

• 强制OLE DB扫描全部行推断类型
  修改OLE DB连接字符串，添加MaxScanRows=0参数（表示扫描所有行来确定列类型），示例连接字符串：

  Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\CSV_Folder\;Extended Properties="text;HDR=Yes;FMT=Delimited;MaxScanRows=0;"
  

• 手动指定列数据类型
  在CSV文件所在目录创建schema.ini文件，明确定义每列的类型，避免驱动自动推断出错。示例内容：

  [your_data.csv]
  ColNameHeader=True
  Format=Delimited(,)
  Col1=ID Integer
  Col2=ProductName Text Width(255)
  Col3=Price Double
  Col4=CreateDate DateTime
  

• 预处理CSV文件
  用纯文本编辑器（如Notepad++）打开CSV，检查并修复：

  • 不闭合的引号、不一致的分隔符；
  • 隐藏控制字符（可开启显示所有字符功能排查）；
  • 编码问题（保存为UTF-8带BOM格式，适配OLE DB驱动）

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