ADO读取Excel出现字符串被截断而不完整的原因与解决办法
分享人：熊鑫
日期：2013/11/25
前些日子处理了ADMB06 （数据导入导出）的问题单，问题描述：插件位置字段超过255插入数据库就会截断。保存到数据库中就只有255的长度。插件位置是T类型的字段。按道理说不应该截取到255的长度。
然后跟踪程序发现。他导入EXCEL的时候是用ADO直接连接EXCEL,直接读取的EXCEL里面的数据。
最开始还以为是数据格式的问题，调试好久还是不行，于是在网上狂资料，终于搞清楚了原因，原来是因为在使用ADO.NET读取Excel表格时，OLEDB（Excel 2000-2003一般是是Jet 4.0，Excel 2007是ACE 12.0，即Access Connectivity Engine，ACE也可以用来访问Excel 2000-2003）会默认扫面Sheet中的前几行来决定数据类型. 
     Excel并不像Access一样，一列中的单元格的数据类型可能不一样，用ADO.NET读取Excel时，ole db(JET) 会扫描sheet中前几行，默认8行（这个值可在注册表中设定）来决定当前列的数据类型。
字符串截取2个字符之间      这个值是由下面注册表项的路径
        Excel 2000-2003 : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel\
        Excel 2007 : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Access Connectivity Engine\Engines\Excel
2012:
      中的TypeGuessRows值决定，其取值范围为十进制闭区间0-16
      考虑一列数据，如果前8行都是数字，那么JET扫描没有问题。 
      如果8行内的数据类型不一样，JET会采用一个都适合的数据类型来匹配，通常为varchar
或unicode varchar。 

      现在的问题是，前8行的数据如果短小，JET匹配了varchar，只有255字符。而实际可能是adLongVarChar或者其它更大的类型。 
       
      设置前面的TypeGuessRows=0，这样会查询16384行，查询完后匹配一个最合适的数据类型，不过这个长度对于我来说已经绰绰有余，于是就用了0。 
      不过对于大文件，就可能会导致效率问题，具体的根据是实际情况而定。 
      再说一下如果决定前8行中使用varchar还是unicode varchar： 

      JET会根据上面的注册表项的值来决定，这个值就是JET一次性扫描的行数，如这个值通常默认为8，也就是说JET在判定一列数据的类型时只扫描前8行来匹配一个最合适的数据类型，但是如果8行以内字符串在255个字符以内，8行以外的字符串却大于255个字符，那么这个时候使用ADO读取Excel就会出问题，会将后面大于255个字符的串截断。那么我们可改
变那个注册表的值来解决该问题，但是这个值的范围规定在十进制0-16之间，为了保险起见可设置为0，那么这时会扫描整个页面再匹配合适的数据类型，这个时候就肯定不会出错，但这样也有个缺点，那就是Excel文件超级大的时候，就会引起效率问题。
 
   

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。