解析用SSMA移植Acceses到SQL几点问题

日期在数据库中是很常见的，所以这个疏忽将会影响大多数数据库转换。但要解决并不困难，如下： 数据挖掘实验室

SELECT EmployeeNo, FirstName, LastName, 
DateOfBirth FROM dbo.EMPLOYEES WHERE (DateOfBirth > 
CONVERT(DATETIME, "1970-01-01")) 数据挖掘实验室 

从例子中返回正确的数据集。 数据挖掘实验室

（我们可以讨论一下是否是这样，例如：CONVERT(DATETIME, "1970-01-01 00:00:00", 102)可能更恰当，但是不管怎么说，我们可以转换数据处理），如果我们可以手动地做，SSMA就应该可以为我们做这件事。 数据挖掘研究院

还有更糟糕的问题：Access默认是在文本周围使用双引号，例如：

SELECT EMPLOYEES.EmployeeNo, 
EMPLOYEES.FirstName FROM EMPLOYEES WHERE 
((EMPLOYEES.FirstName="Norma")); 
数据挖掘研究院
 

SQL Server不是这样，它使用单引号，如下：WHERE EMPLOYEES.FirstName="Norma";然而，SSMA保留了上面这样的双引号代码，没做任何改变。而且在架构产生期间并没有引发错误提示，错误提示只发生在把架构加载到SQL Server数据库的过程中。那时，SSMA抛出一个错误提示说存在一个非法列名Norma，这样视图就不能加载到SQL Server中了。以上显示出SSMA并没有做足够的语法检查。 数据挖掘研究院

再强调一下，Access默认使用双引号，而SSMA却不能处理如此简单平常的Access语法。这就像一个法语到英语的翻译者可以处理语言中的大多数词，却为单词“Bonjour”感到束手无策一样。

数据挖掘研究院

再一个例子，Access允许为字段添加规则约束，例如一个名为“Title”的字段可以接受的值可能只有Mr., Mrs., Miss., Ms等。但SQL Server不能准确地支持同样的类型约束。非常明显SSMA转换这种约束规则为一个表约束。Brilliant，做的不错，只是在代码中丢失了字段名：

数据挖掘研究院

ALTER TABLE [dbo].[NAMES] ADD CONSTRAINT [SSMA_CC$NAMES$Title$validation_rule] CHECK (In ("Mr.","Mrs.","Miss","Ms","Dr.","Prof."))这不仅不能在架构转载到SQL Server时运行，同时更不能产生一个错误消息。最后一行的正确语法应该是:CHECK (Title In ("Mr.","Mrs.","Miss","Ms","Dr.","Prof.")) 数据挖掘研究院

那么，我们是否应该从机器上删除SSMA呢？当然不，因为它确实完全自动地做了大量的工作，也提供了一个合理的环境，在那里可以看到问题区域并做出整理。指出它的缺陷，只是期望SSMA能更好。 数据挖掘研究院