Excel文件：
| 序号 | 姓名 | 内部电话 | 住址 |
| 1 | 小李 | 1234 | …… |
| 2 | 小王 | 5678 | …… |
| 3 | 小张 | 2345(国内长途） | …… |
| …… | …… | …… | …… |
如上结构的Excel文件，用SQL Server的“导入数据”功能来将其导入SQL数据库中。
结果发现在“内部电话”列中，所有带有文字的电话号，被导入后字段值全部为NULL
SQL数据表：
| 序号 | 姓名 | 内部电话 | 住址 |
| 1 | 小李 | 1234 | …… |
| 2 | 小王 | 5678 | …… |
| 3 | 小张 | NULL | …… |
| …… | …… | …… | …… |
通过在SQL中设置（在导入导出中，目的方选择新建表），发现数据库默认将“内部电话”列识别为float型，因为其新建表对应字段就是float类型的。
看来是SQL认为包含文字的那些电话号码无法转换成数字，所以是无效的数据，从而采用NULL来代替。
通过查询微软网站，发现MS大意如是说：SQL在导入Excel混合数据列的时候，由于数据类型不唯一，导致SQL无法确定数据类型（看来SQL也有犯糊涂的时候）。SQL的应对之道就是统计该数据列的前８行数据中出现最多的类型，并以此类型做为默认类型。而在我的Excel文件中，“内部电话”列的前８行中的确要数纯数字格式的电话号码最多，所以SQL就把这列认为是float型的（为什么不是int型？不解）。至于此列其它格式的数据，SQL的办法是——直接扔了（汗一个。。）
MS原文：
但是，由于 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) 个空值。 |
作为解决只读数据问题的一种替代方法，可在连接字符串的“扩展属性”部分中使用“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中还有数字、货币、日期等一帮捣乱的类型。
