|
|
去坛子里搜索imex，字段数据类型不一致会导致这个问题
可以看看下面的文字：
Sub query()
Dim conn As Object
Dim sql As String
Sheet2.Cells.Clear
Set conn = CreateObject("ADODB.Connection")
conn.Open "provider=microsoft.jet.oledb.4.0;extended properties='excel 8.0;imex=1';data source=" & ThisWorkbook.FullName
sql = "select number from [n1$]"
sql = Trim(sql)
Sheet1.Range("b2").CopyFromRecordset conn.Execute(sql)
Set conn = Nothing
End Sub
---------------------------------------------------------------------------
Sub query2()
Dim conn As Object
Dim sql As String
Sheet2.Cells.Clear
Set conn = CreateObject("ADODB.Connection")
conn.Open "provider=microsoft.jet.oledb.4.0;extended properties=excel 8.;data source=" & ThisWorkbook.FullName
sql = "select number from [n1$]"
sql = Trim(sql)
Sheet1.Range("b2").CopyFromRecordset conn.Execute(sql)
Set conn = Nothing
End Sub
上面两段代码 不同之处，也是关键之处在于ado连接字符创扩展属性imex不同赋值，默认imex=0。
MS原文如下：
-----------------------------------------------------
……Excel 不会像关系数据库那样为 ADO 提供有关其数据的详细架构信息。因此，驱动程序必须至少扫描几行现有数据，才能有根据地猜测各列的数据类型。“要扫描的行数”的默认值为八 (8) 行。可以指定从一 (1) 行到十六 (16) 行的整数值，或指定零 (0)，扫描所有现有行。这可通过向连接字符串添加可选的 MaxScanRows= 设置，或在 DSN 配置对话框中更改要扫描的行数设置来完成。
但是，由于 ODBC 驱动程序中存在一个错误，所以目前指定“要扫描的行数”(MaxScanRows) 设置不起作用。换句话说，Excel ODBC 驱动程序（MDAC 2.1 和更高版本）始终扫描指定数据源中的前 8 行，以确定各列的数据类型。
……
使用这两种 OLE DB 提供程序时都应考虑的问题
混用数据类型时应注意的事项如上文所述，ADO 必须猜测 Excel 工作表或范围中各列的数据类型。（这不受 Excel 单元格格式设置的影响。）如果同一列中既有数字值，也有文本值，会出现严重的问题。Jet 和 ODBC 提供程序将返回占多数的类型的数据，但对于占少数的数据类型，则会返回 NULL（空）值。如果该列中两种类型数据的数量相等，提供程序将优先选择数字型数据，放弃文本型数据。
例如：
?在被扫描的八 (8) 行中，如果该列包含五 (5) 个数字值和三 (3) 个文本值，则提供程序将返回五 (5) 个数字和三 (3) 个空值。?在被扫描的八 (8) 行中，如果该列包含三 (3) 个数字值和五 (5) 个文本值，则提供程序将返回三 (3) 个空值和五 (5) 个文本值。?在被扫描的八 (8) 行中，如果该列包含四 (4) 个数字值和四 (4) 个文本值，则提供程序将返回四 (4) 个数字和四 (4) 个空值。
因此，如果列中包含不同类型的值，唯一的解决方法是将该列中的数字值存储为文本，然后在需要时使用 Visual Basic VAL 函数或同等功能的函数将其还原为数字。
作为解决只读数据问题的一种替代方法，可在连接字符串的“扩展属性”部分中使用“IMEX=1”这一设置来启用导入模式。这可强制执行 ImportMixedTypes=Text 注册表设置。但在此模式下，执行更新操作时可能会出现意外的结果。
-------------------------------------------------------
（郁闷）当我们设置IMEX＝1时将强制混合数据转换为文本，但仅仅这种设置并不可靠，IMEX＝1只确保在某列前8行数据至少有一个是文本项的时候才起作用，它只是把查找前8行数据中数据类型占优选择的行为作了略微的改变。例如某列前8行数据全为纯数字，那么它仍然以数字类型作为该列的数据类型，随后行里的含有文本的数据仍然变空。
另一个改进的措施是IMEX＝1与注册表值TypeGuessRows配合使用，TypeGuessRows 值决定了ISAM 驱动程序从前几条数据采样确定数据类型，默认为“8”。可以通过修改“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel”下的该注册表值来更改采样行数。但是这种改进还是没有根本上解决问题，即使我们把IMEX设为“1”，TypeGuessRows设得再大，例如1000，假设数据表有1001行，某列前1000行全为纯数字，该列的第1001行又是一个文本，ISAM驱动的这种机制还是让这列的数据变成空。
产生这种问题的根源与Excel ISAM[3]（Indexed Sequential Access Method，即索引顺序存取方法）驱动程序的限制有关，Excel ISAM 驱动程序通过检查前几行中实际值确定一个 Excel 列的类型，然后选择能够代表其样本中大部分值的数据类型[4]。也即Excel ISAM查找某列前几行（默认情况下是8行），把占多的类型作为其处理类型。例如如果数字占多，那么其它含有字母等文本的数据项就会置空；相反如果文本居多，纯数字的数据项就会被置空。
现具体分析在第1节程序代码Extended Properties项中的HDR和IMEX所代表的含义。HDR用来设置是否将Excel表中第一行作为字段名，“YES”代表是，“NO”代表不是即也为数据内容；IMEX是用来告诉驱动程序使用Excel文件的模式，其值有0、1、2三种，分别代表导出、导入、混合模式
解决方法
从以上的分析中可以得知，当某列数据中含有混合类型时，在.NET中使用Microsoft.Jet.OLEDB.4.0来读取Excel文件造成数据丢失是不可避免的，要解决这个问题只能考虑采用其它数据读取方法。
在.NET中读取Excel文件的另外一种方法是回到使用传统COM组件，这种方法在很多技术文章或论文中都有涉及，本文不作赘述。需要指出的是，使用COM组件来读取Excel文件数据的效率较低，在作释放的时候有可能碰到不可预知的错误，特别开发Web应用的程序应该慎重使用。
本文提出另外一种利用读取CSV纯文本格式解决此问题的方法。
（1）在读取Excel的.xls类型的文本数据之前，先将其转换为.csv格式，在Excel中直接另存为这种格式就可以达到转换的目的。CSV文件又称为逗号分隔的文件，是一种纯文本文件，它以“,”分隔数据列，本文表1的数据表用CSV格式存储后用纯文本编辑器打开的表现形式如表3所示。
表3 采用CSV格式保存的表1数据
需要指出的是，CSV文件也可以用Ole DB或ODBC的方式读取，但是如果采用这些方式读取其数据又会回到丢失数据的老路上，ISAM机制同样会发挥作用。
（2）采用普通的读取文本文件的方法打开文件，读取第一行，用“,”作为分隔符获得各字段名，在DataTable中创建对应的各字段，字段的类型可以统一创建成“String”。
本文原文
（3）逐行读取数据行， 用“,”作为分隔符获得某行各列的数据并填入DataTable相应的字段中。 |
|
沪公网安备 31011702000001号 沪ICP备11019229号-2
发表于 2009-6-23 16:45
楼主
