很多Access和SQLServer开发人员都经常面临着将一个Access 数据库 升级 到SQLServer 数据库 的问题。由于存在 现有 的Access 升级 向导,这一转变的过程就会变得相当简单,尤其是当你建立一个与SQLServer数据相联系的ADP的时候。然而,向导并不是十全十美的,
很多Access和SQLServer开发人员都经常面临着将一个Access数据库升级到SQLServer数据库的问题。由于存在现有的Access升级向导,这一转变的过程就会变得相当简单,尤其是当你建立一个与SQLServer数据相联系的ADP的时候。然而,向导并不是十全十美的,需要解决的问题还是大有存在。
首先,有些对象并不是简单的升级,所以这时你不得不人为地处理。第二,很多Access特性──比如一些查询类型,对象,以及特定的数据类型在你没有做好升级之前的准备的情况下就会导致错误的产生。现在,让我们讨论一下在数据库升级过程中可能面临的问题,我将提供能够解决问题的一些通用的指导方法,最后,你必须花一定的时间和精力将这些知识应用到开发之中。
哪些不能够升级?
在处理实际的问题之前,让我们看看不能随意升级的对象,它们包括以下:
交叉表查询
包含SQLDISTINCTROW关键字的任何查询
所有的隐藏对象
作为参数的表格数据的查询(这些表格可以升级,但它们却不能正确的运行)
Pass-Through查询
SQL数据定义语言查询(比如CREATETABLE,ALTERTABLE,以及DROP语句)
这些Access对象需要特定的处理。具体的,你将建立一个可比较的SQLServer对象,除此之外,SQLServer不支持Jet安全特性,所以你必须使用Windows认证和/或SQLServer安全机制。
包括的问题点
在数据库的升级之前,如果你已经知道哪些地方将可能导致错误并知道如何处理产生的错误,数据库升级过程中导致的错误的可能性将大大地减少。我能够提供的数据库升级的最好的建议是在开发之前做好最完整的计划。现在,我将列举数据库升级过程中可能会导致产生的问题──如果你没有做好计划之前的准备。
不支持的日期
关于日期,在Access和SQLServer之间都存在很大的差别。Access支持很大范围的日期,从100年1月1日到9999年12月31日。相反,SQLServer支持的日期从1753年1月1日到9999年12月31日。数据库的升级向导无法升级包含SQLServer不支持的日期的表格。这就意味着在升级之前你必须人工地处理这些日期。幸运的是,这一问题只影响少数的数据库。
与表格控制相关的查询
开发人员通常会使用表格控制的查询来限制或询问一个数据来源。一个表格可以提供将数据显示在一个特定报告中的多种选择。例如,SQLSELECT语句包含了用户的输入:
SELECTOrders.RequiredDate,Orders.ShippedDate,Orders.Freight,
Orders.ShipName,Orders.ShipAddress,Orders.OrderDate
FROMOrders
WHERE
Orders.OrderDateBetween[Forms]![DateFilter]![DateFrom]And[Forms]![DateFilter]![DateTo]));
为了限定报告中的数据,用户可以输入一个开始和结束的日期到列表(DateFrom和DateTo)。其他的代码可以打开并显示满足用户输入的两个日期之间的记录。
因为这种查询方式被Jet处理,表格中产生的问题可以很快被解决。然而,当数据库升级时,SQLServer不会涉及到表格控制,结果通常为查询失败。为了修正这一查询方式,开发人员必须更改表格。我建议你使用输入参数属性,并将数值传递到SQLServer存储程序。
交叉表查询
SQLServer不支持JetTRANSFORM语句──这一语句可以使一个交叉表查询成为可能。例如,数据库升级向导支持以下查询方式:
TRANSFORMSum(CCur([OrderDetails].UnitPrice*[Quantity]*(1-[Discount])/100)*100)
ASProductAmount
SELECTProducts.ProductName,Orders.CustomerID,Year([OrderDate])ASOrderYear
FROMProductsINNERJOIN(OrdersINNERJOIN[OrderDetails]
ONOrders.OrderID=[OrderDetails].OrderID)ONProducts.ProductID=
[OrderDetails].ProductID
WHEREOrders.OrderDateBetween#1/1/1997#And#12/31/1997#