要完成搜索，我的同事必须让Informix将有用数据输出到一个文本文件中。然后，一个SQL Server DTS包将文本文件输入到SQL Server的一个当地实例中，然后在其中用通配符对TEXT栏进行处理。

不幸地是，还存在两个问题：1）连接缓慢且在输入完成前经常中断连接。2）如果决定中途取消操作，SQL Server放弃这时已经处理的所有行。他必须想出办法，每n个记录提交一次，然后再继续操作。

为了给他找到解决办法，我在DTS向导中转悠。发现解决方案已内置在DTS中。

为说明如何操作，我建立一个DTS包，将Northwind Customers数据库输出到一个文本文件中。然后，我建立一个新包把这个文本文件输入到一个称作Northwind_New的Northwind拷贝中。在DTS向导中，其结果如图A所示。

现在，我将鼠标放在管道上，右击然后选择属性，出现名为“转换数据任务属性”的对话框。这时要用到的标签为选项（Options），如图B所示。

要用的选项为“总是提交最后批”与“插入批大小”。第一个选项不需加以说明；后一个选项对插入到批中的行数进行控制。你可以对它进行调整以满足你的要求与应用情形。默认设置为0，也就是我的同事经历的情形，如果出现故障，整个批全部丢失。设置1迫使每次插入后进行提交。设置100或1000则每100或1000行提交一次。

现在我的同事的问题解决了，他正高兴地用通配符搜索TEXT栏。

今天有个朋友问我怎样将ACC数据库转换成SQL的,其实在MSSQL中有自带的功能,可以把其他的数据库中的内容导入........看下面的操作.......

打开管理工具->数据源(ODBC)




创建好数据源之后,就可以进行导入了.....

在目的数据库上右键->所有任务->导入数据

选择刚才创建的数据源

然后一直下一步即可,直到"选择源表和视图"这一步,可以选择access数据库中需要导入的表,不需要的表可以不用导入.........

这样就成功导入了access数据库

上面是根据MSSQL的数据导入向导一步一步做的,其中或许有不对的地方,或者有更好的办法实现相同的目的,希望有人能给我指出,谢谢!~~~~~~MSSQL自带的数据导入导出功能可以实现大多数数据库之间的倒数据...很方便的一看就明白

很多Access和SQL Server开发人员都经常面临着将一个Access数据库升级到SQL Server数据库的问题。由于存在现有的Access升级向导，这一转变的过程就会变得相当简单，尤其是当你建立一个与SQL Server数据相联系的ADP的时候。然而，向导并不是十全十美的，需要解决的问题还是大有存在。

首先，有些对象并不是简单的升级，所以这时你不得不人为地处理。第二，很多Access特性──比如一些查询类型，对象，以及特定的数据类型在你没有做好升级之前的准备的情况下就会导致错误的产生。现在，让我们讨论一下在数据库升级过程中可能面临的问题，我将提供能够解决问题的一些通用的指导方法，最后，你必须花一定的时间和精力将这些知识应用到开发之中。

哪些不能够升级？
在处理实际的问题之前，让我们看看不能随意升级的对象，它们包括以下：

交叉表查询
包含SQL DISTINCTROW关键字的任何查询
所有的隐藏对象
作为参数的表格数据的查询(这些表格可以升级，但它们却不能正确的运行)
Pass-Through查询
SQL数据定义语言查询(比如Create TABLE, Alter TABLE, 以及Drop语句)
这些Access对象需要特定的处理。具体的，你将建立一个可比较的SQL Server对象，除此之外，SQL Server不支持Jet安全特性，所以你必须使用Windows认证和/或SQL Server安全机制。

包括的问题点
在数据库的升级之前，如果你已经知道哪些地方将可能导致错误并知道如何处理产生的错误，数据库升级过程中导致的错误的可能性将大大地减少。我能够提供的数据库升级的最好的建议是在开发之前做好最完整的计划。现在，我将列举数据库升级过程中可能会导致产生的问题──如果你没有做好计划之前的准备。

不支持的日期
 
关于日期，在Access和SQL Server之间都存在很大的差别。Access支持很大范围的日期，从100年1月1日到9999年12月31日。相反，SQL Server支持的日期从1753年1月1日到9999年12月31日。数据库的升级向导无法升级包含SQL Server不支持的日期的表格。这就意味着在升级之前你必须人工地处理这些日期。幸运的是，这一问题只影响少数的数据库。

与表格控制相关的查询
开发人员通常会使用表格控制的查询来限制或询问一个数据来源。一个表格可以提供将数据显示在一个特定报告中的多种选择。例如，SQL Select语句包含了用户的输入：

 Select orders.RequiredDate, orders.ShippedDate, orders.Freight,
    orders.ShipName, orders.ShipAddress, orders.OrderDate
FROM orders
Where
 Orders.OrderDate Between [Forms]![DateFilter]![DateFrom] And [Forms]![DateFilter]![DateTo]));

为了限定报告中的数据，用户可以输入一个开始和结束的日期到列表(DateFrom 和DateTo)。其他的代码可以打开并显示满足用户输入的两个日期之间的记录。

因为这种查询方式被Jet处理，表格中产生的问题可以很快被解决。然而，当数据库升级时，SQL Server不会涉及到表格控制，结果通常为查询失败。为了修正这一查询方式，开发人员必须更改表格。我建议你使用输入参数属性，并将数值传递到SQL Server存储程序。

交叉表查询
SQL Server不支持Jet TRANSFORM语句──这一语句可以使一个交叉表查询成为可能。例如，数据库升级向导支持以下查询方式：

TRANSFORM Sum(CCur([Order Details].UnitPrice*[Quantity]*(1-[Discount])/100)*100)
    AS ProductAmount
Select Products.ProductName, orders.CustomerID, Year([OrderDate]) AS orderYear
FROM Products INNER JOIN (Orders INNER JOIN [Order Details]
ON orders.OrderID = [Order Details].OrderID) ON Products.ProductID =
    [Order Details].ProductID
Where orders.OrderDate Between #1/1/1997# And #12/31/1997#
GROUP BY Products.ProductName, orders.CustomerID, Year([OrderDate])
PIVOT "Qtr " & DatePart("q",[OrderDate],1,0) In ("Qtr 1","Qtr 2","Qtr 3","Qtr 4")

还好，你无需在SQL Server中使用Transact-SQL (T-SQL) CASE关键词重新编写一个Access的交叉表查询。下面的Select语句描述了使用T-SQL方式重新建立一个交叉表查询的语法：

Select Customers.CustomerID, Customers.CustomerName
    SUM (Case When orders.Orderdate BETWEEN '01-Jan-1990' AND '31-Dec-1996'
    Then [UnitPrice]*[Quantity] Else 0 End) as 1997)
FROM Customers INNER JOIN orders
ON CustomerID=Orders.CustomerID

隐藏对象
所有的隐藏对象在数据库升级过程中都被忽略。对此，你最好的处理方法是使用程序对象的GetHiddenAttribute属性检查对象。例如，以下代码使用这一方法决定对象是否被隐藏。
Dim IsHidden As Boolean
If Application.GetHiddenAttribute(objtype, objname) Then  
  IsHidden = True
End If

如果特定的对象被隐藏，IsHidden布尔变量将被为True。

包含索引的表格
 
数据库升级向导不支持没有索引或其他限制的表格。升级向导可以升级一个无索引的表格，但其转换之后只能成为一个只读的表格。幸运的是，解决这一问题很简单：添加一个索引到每一个没有索引的表格。一旦你已经完成升级数据库，请记住将添加的索引删除。

数据库升级操作步骤
一旦你已经做好一切准备，并确定操作可以开始。数据库升级向导可以为你提供三种选择：

输出Access表格到SQL Server并链接到Access数据库
使用Pass-Through查询与SQL Server的后台服务器的表格相互通讯
将整个Access数据库移动到一个Access数据库工程(其只与SQL Server联系)
为了启动数据库升级向导，先从工具菜单栏中选择数据库功能，然后从子菜单中选择升级向导。向导的第一个面板提供两种选择：你可以建立一个新的SQL Server 数据库来存放Access表格，如图A所示，或者你可以在一个现成的SQL Server数据库中添加表格。选择一个现成的SQL Server数据库将需要输入一个数据服务名称(DSN)。

图 A

要不再管理多个数据库和发布并不是件困难的事。假设你用SQL Server为你的一个数据库站点开发一个应用程序。它进展得很快，并且你意识到你可以对同一个应用程序只做少量的修改就可以用于另一个站点。这将按用户的要求很快就会完成，所以你决定复制代码和数据库并相应的做些修改。然后，其他的站点也要求应用程序，每一个都有自己的需要和要求。

来重复生产应用程序的最快方法是做一个应用和数据库的复本，并对他们做必要的改动。过一段时间，一个对应用的新的需求可能使你选择用SQL Server复制在你的站点和其他站点(可能到门户机器上)之间拷贝数据。对于每一个站点，你将创建不同的发布和订阅。

然后你的公司决定要合并站点，并且你要在同一台服务器(中央服务器)上部署多个数据库和多个发布。这些数据库和发布非常类似但是并不一样。

很有可能你将开始发现它是很烦人且很复杂的——管理这个复制设计。太多的发布，太多的订阅，并且很可能在多个发布中有相同的订阅存在。听起来很类似?

你将对复制设计做同样的决定吗?你可以在SQL Server复制设计过程中按这些步骤来简化复制管理和控制。

复制设计目标

你要做一个成功的复制设计的目标应该将会减少管理力度和减少失败点。你可以通过维护较少的发布和订阅达到这个目标。但是，这会意味着改变数据库结构，这可能并不可行。

数据库设计

最好的方法是合并复制表来减少源数据库(只有一个源数据库更好)。这允许你减少发布的数量。当你合并时，通常有必要对数据表增加站点或数据库代码以便统一数据源。

复制设计

如果修改应用程序以便使用更少的数据库这个工作太复杂的话，一个更好的方法可能是复制表到一个临时的具有共同结构的中央数据库中。通过这个方法，订阅可以从中央数据库中利用较少的发布获得数据，就像下面图片中所显示的：

现在的架构：

只有很少的数据库具有相似的架构，而这些数据库由很少的几个应用程序修改。每个数据库具有它自己的发布，并被复制到多个订阅中：

推荐的架构：

数据库被复制到一个具有共同结构的中央数据库中，改动被复制到使用较少发布的订阅中：

复制合并了数据之后，你就可以发布特定站点所属的数据片段。这允许你创建一个发布并根据这个站点或数据库代码增加一个Where条件。

复制总结

当复制模型由于应用的发展而变得太复杂的时候，简化复制模型是个很好的主意。否则，管理这大量的发布和订阅很可能会变成一件令人头疼的事。