版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://annie-/logs/60276495.html
Excel文件：
如上结构的Excel文件，用SQL Server的“导入数据”功能来将其导入SQL数据库中。
结果发现在“内部电话”列中，所有带有文字的电话号，被导入后字段值全部为NULL
SQL数据表：
通过在SQL中设置（在导入导出中，目的方选择新建表），发现数据库默认将“内部电话”列识别为float型，因为其新建表对应字段就是float类型的。
看来是SQL认为包含文字的那些电话号码无法转换成数字，所以是无效的数据，从而采用NULL来代替。
通过查询微软网站，发现MS大意如是说：SQL在导入Excel混合数据列的时候，由于数据类型不唯一，导致SQL无法确定数据类型（看来SQL也有犯糊涂的时候）。SQL的应对之道就是统计该数据列的前８行数据中出现最多的类型，并以此类型做为默认类型。而在我的Excel文件中，“内部电话”列的前８行中的确要数纯数字格式的电话号码最多，所以SQL就把这列认为是float型的（为什么不是int型？不解）。至于此列其它格式的数据，SQL的办法是——直接扔了（汗一个。。）
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（空）值。如果该列中两种类型数据的数量相等，提供程序将优先选择数字型数据，放弃文本型数据。
例如： 因此，如果列中包含不同类型的值，唯一的解决方法是将该列中的数字值存储为文本，然后在需要时使用 Visual BasicVAL函数或同等功能的函数将其还原为数字。
作为解决只读数据问题的一种替代方法，可在连接字符串的“扩展属性”部分中使用“IMEX=1”这一设置来启用导入模式。这可强制执行ImportMixedTypes=Text注册表设置。但在此模式下，执行更新操作时可能会出现意外的结果。
原文地址：257819: 如何在 Visual Basic 或 VBA 中使用 ADO 来处理 Excel 数据
看到了没有？你想在前８行里多放几行文本的企图也是徒劳的。数字格式的数据一样会被扔掉，尽管数字可以毫无问题的转成文本。 DSN设置那里根本就没给我们提供加“IMEX=1”的地方，这个字符串是给ADO用的，如果你要编程读取Excel中的数据就用得着它了。不过MS说用这样的连接字符串更新时可能会有问题，这点要稍加注意。我们这里只是数据导入，根本不用考虑这一项。
而在Excel中将有问题的单元格单元格格式设为文本这一办法，事实证明，不起作用。
倒是在每个数字前加单引号可以正常导入，可问题是行数太多，不可能一行行手动加单引号。
用VBA或公式加吧，又无法判断每个单元格是数字类型还是文本类型，导致该列所有单元格都被加了引号。
而且这种方式导入SQL数据库后，还得用查询分析器写SQL语句把引号去了。
最后，最简单的一个办法——把Excel文件另存为“文本文件（制表符分隔）”，再用SQL来导入，一切OK了
为什么？因为txt文件里的内容只有文本属性，不像Excel中还有数字、货币、日期等一帮捣乱的类型。
