ADO读取Excel出现字符串被截断而不完整的原因与解决办法.doc

易飞服务部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行（这个值可在注册表中设定）来决定当前列的数据类型。 这个值是由下面注册表项的路径 Excel 2000-2003 :HKEY_LOCAL_MACHINESOFTWAREMicrosoftJet4.0EnginesExcel Excel 2007 :HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice12.0Access Connectivity EngineEnginesExcel2012: 中的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，那么这时会