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

ADO读取Excel出现字符串被截断而不完整的原因与解决办法 然后跟踪程序发现。他导入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_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文件超级大的时候，就会引起效率问题。??? ? 易飞服务部 3