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

核心提示： SQL Server不是这样，它使用单引号，解析用SSMA移植Acceses到SQL几点问题(3)，如下：WHERE EMPLOYEES.FirstName='Norma';然而，SSMA保留了上面这样的双引号代码，在那里可以看到问题区域并做出整理，指出它的缺陷，没做任何改

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能更好。