這些年來，Access數(shù)據(jù)庫一直在PC平臺占據(jù)主導地位，使用它建立了大量的部門數(shù)據(jù)庫。隨著這些數(shù)據(jù)庫的應(yīng)用，它們中的大多數(shù)已經(jīng)慢慢地具有應(yīng)急使命，現(xiàn)在需要的是加固成為一個安全的客戶端—服務(wù)器引擎。
在微軟想要統(tǒng)治世界的偉大計劃中，更希望這種引擎是SQL Server。隨著這種想法，微軟針對Access提供了免費的SQL Server移植工具——SSMA。
對于開發(fā)者來說，移植工具已有很大的實惠。但期望這種工具能夠移植整個應(yīng)用程序是不現(xiàn)實的，因為Access有一些SQL Server所沒有的簡單工具（例如窗體和報表性能）。但是我們有理由相信這種工具能做大部分工作，比如建立適當?shù)谋?，轉(zhuǎn)移數(shù)據(jù)，把查詢轉(zhuǎn)換成視圖等。
SSMA的運行需要在.NET Framework2.0版本以上，J#2.0可重組包以及至少1GB RAM。
SSMA具有一個清晰的圖形用戶界面，分成四個面板。在建立一個新工程之后，首先添加一個或多個Access數(shù)據(jù)庫，然后連接到適當?shù)腟QL Server數(shù)據(jù)庫，下一步就是把架構(gòu)（schema）轉(zhuǎn)換成SQL Server。
注意，這個過程并不是運行依靠SQL Server引擎的架構(gòu)，而是簡單地生成了一個在SSMA中可見的，可用的SQL Server架構(gòu)，同時生成一個錯誤、警告和信息標記的集合。
從這點來看，該工具的能力就顯而易見。作為一個開始，這些標記指出轉(zhuǎn)換問題，例如：不支持Access的一些函數(shù)如DateDiff，所以不能轉(zhuǎn)換（當然這些函數(shù)可以被轉(zhuǎn)換，但SSMA不能實現(xiàn)）。
你可以瀏覽Access架構(gòu)，觀察正在計劃的類型映射等等，當然如果你不喜歡這種缺省映射，也完全可以改變它，或者根據(jù)特殊的工程甚至特殊的表來做改變。
查詢是一個比較特別的情形。它們被轉(zhuǎn)換成SQL Server視圖：你可以編輯Access查詢?nèi)缓螽a(chǎn)生適當?shù)腟QL Server代碼。這樣的編輯是發(fā)生在SSMA的架構(gòu)中，而不是在Access數(shù)據(jù)庫本身完成。
你可以使用SSMA運行依靠數(shù)據(jù)庫的SQL Server架構(gòu)，它建立了一種結(jié)構(gòu)來保存數(shù)據(jù)以便你可以移植數(shù)據(jù)。理論上聽起來很好，但是實際上是怎樣的呢？雖說嘗試從任意一個數(shù)據(jù)庫引擎移植到另一個都是麻煩的，且這個工具可以免費的為你做90%的工作，但它還存在一些缺陷。
例如，雖然不是SQL標準的一部分，Access需要所有日期來包裝到hash記號中。不幸的是，SSMA看起來沒有考慮到這點，這個疏忽的結(jié)果就是所有涉及到日期的查詢結(jié)果都不能成功轉(zhuǎn)換。下面是一個錯誤信息的例子：
/* * SSMA error messages: * A2SS0058: Following SQL statement is not supported and cannot be converted: * * SELECT DISTINCTROW EMPLOYEES.EmployeeNo, EMPLOYEES.FirstName, EMPLOYEES.LastName, EMPLOYEES.DateOfBirth, EMPLOYEES.DateEmployed * FROM EMPLOYEES * WHERE ((EMPLOYEES.DateOfBirth)>#1/1/1970#); * */PRINT ’ERROR: SSMA failed to convert the previous statement.’
日期在數(shù)據(jù)庫中是很常見的，所以這個疏忽將會影響大多數(shù)數(shù)據(jù)庫轉(zhuǎn)換。但要解決并不困難，如下：
SELECT EmployeeNo, FirstName, LastName, DateOfBirth FROM dbo.EMPLOYEES WHERE (DateOfBirth > CONVERT(DATETIME, ’1970-01-01’))
從例子中返回正確的數(shù)據(jù)集。
（我們可以討論一下是否是這樣，例如：CONVERT(DATETIME, ’1970-01-01 00:00:00’, 102)可能更恰當，但是不管怎么說，我們可以轉(zhuǎn)換數(shù)據(jù)處理），如果我們可以手動地做，SSMA就應(yīng)該可以為我們做這件事。
還有更糟糕的問題：Access默認是在文本周圍使用雙引號，例如：
SELECT EMPLOYEES.EmployeeNo, EMPLOYEES.FirstName FROM EMPLOYEES WHERE ((EMPLOYEES.FirstName="Norma"));
SQL Server不是這樣，它使用單引號，如下：WHERE EMPLOYEES.FirstName=’Norma’;然而，SSMA保留了上面這樣的雙引號代碼，沒做任何改變。而且在架構(gòu)產(chǎn)生期間并沒有引發(fā)錯誤提示，錯誤提示只發(fā)生在把架構(gòu)加載到SQL Server數(shù)據(jù)庫的過程中。那時，SSMA拋出一個錯誤提示說存在一個非法列名Norma，這樣視圖就不能加載到SQL Server中了。以上顯示出SSMA并沒有做足夠的語法檢查。
再強調(diào)一下，Access默認使用雙引號，而SSMA卻不能處理如此簡單平常的Access語法。這就像一個法語到英語的翻譯者可以處理語言中的大多數(shù)詞，卻為單詞“Bonjour”感到束手無策一樣。
再一個例子，Access允許為字段添加規(guī)則約束，例如一個名為“Title”的字段可以接受的值可能只有Mr., Mrs., Miss., Ms等。但SQL Server不能準確地支持同樣的類型約束。非常明顯SSMA轉(zhuǎn)換這種約束規(guī)則為一個表約束。Brilliant，做的不錯，只是在代碼中丟失了字段名：
ALTER TABLE [dbo].[NAMES] ADD CONSTRAINT [SSMA_CC$NAMES$Title$validation_rule] CHECK (In (’Mr.’,’Mrs.’,’Miss’,’Ms’,’Dr.’,’Prof.’))這不僅不能在架構(gòu)轉(zhuǎn)載到SQL Server時運行，同時更不能產(chǎn)生一個錯誤消息。最后一行的正確語法應(yīng)該是:CHECK (Title In (’Mr.’,’Mrs.’,’Miss’,’Ms’,’Dr.’,’Prof.’))
那么，我們是否應(yīng)該從機器上刪除SSMA呢？當然不，因為它確實完全自動地做了大量的工作，也提供了一個合理的環(huán)境，在那里可以看到問題區(qū)域并做出整理。指出它的缺陷，只是期望SSMA能更好。
在微軟想要統(tǒng)治世界的偉大計劃中，更希望這種引擎是SQL Server。隨著這種想法，微軟針對Access提供了免費的SQL Server移植工具——SSMA。
對于開發(fā)者來說，移植工具已有很大的實惠。但期望這種工具能夠移植整個應(yīng)用程序是不現(xiàn)實的，因為Access有一些SQL Server所沒有的簡單工具（例如窗體和報表性能）。但是我們有理由相信這種工具能做大部分工作，比如建立適當?shù)谋?，轉(zhuǎn)移數(shù)據(jù)，把查詢轉(zhuǎn)換成視圖等。
SSMA的運行需要在.NET Framework2.0版本以上，J#2.0可重組包以及至少1GB RAM。
SSMA具有一個清晰的圖形用戶界面，分成四個面板。在建立一個新工程之后，首先添加一個或多個Access數(shù)據(jù)庫，然后連接到適當?shù)腟QL Server數(shù)據(jù)庫，下一步就是把架構(gòu)（schema）轉(zhuǎn)換成SQL Server。
注意，這個過程并不是運行依靠SQL Server引擎的架構(gòu)，而是簡單地生成了一個在SSMA中可見的，可用的SQL Server架構(gòu)，同時生成一個錯誤、警告和信息標記的集合。
從這點來看，該工具的能力就顯而易見。作為一個開始，這些標記指出轉(zhuǎn)換問題，例如：不支持Access的一些函數(shù)如DateDiff，所以不能轉(zhuǎn)換（當然這些函數(shù)可以被轉(zhuǎn)換，但SSMA不能實現(xiàn)）。
你可以瀏覽Access架構(gòu)，觀察正在計劃的類型映射等等，當然如果你不喜歡這種缺省映射，也完全可以改變它，或者根據(jù)特殊的工程甚至特殊的表來做改變。
查詢是一個比較特別的情形。它們被轉(zhuǎn)換成SQL Server視圖：你可以編輯Access查詢?nèi)缓螽a(chǎn)生適當?shù)腟QL Server代碼。這樣的編輯是發(fā)生在SSMA的架構(gòu)中，而不是在Access數(shù)據(jù)庫本身完成。
你可以使用SSMA運行依靠數(shù)據(jù)庫的SQL Server架構(gòu)，它建立了一種結(jié)構(gòu)來保存數(shù)據(jù)以便你可以移植數(shù)據(jù)。理論上聽起來很好，但是實際上是怎樣的呢？雖說嘗試從任意一個數(shù)據(jù)庫引擎移植到另一個都是麻煩的，且這個工具可以免費的為你做90%的工作，但它還存在一些缺陷。
例如，雖然不是SQL標準的一部分，Access需要所有日期來包裝到hash記號中。不幸的是，SSMA看起來沒有考慮到這點，這個疏忽的結(jié)果就是所有涉及到日期的查詢結(jié)果都不能成功轉(zhuǎn)換。下面是一個錯誤信息的例子：
/* * SSMA error messages: * A2SS0058: Following SQL statement is not supported and cannot be converted: * * SELECT DISTINCTROW EMPLOYEES.EmployeeNo, EMPLOYEES.FirstName, EMPLOYEES.LastName, EMPLOYEES.DateOfBirth, EMPLOYEES.DateEmployed * FROM EMPLOYEES * WHERE ((EMPLOYEES.DateOfBirth)>#1/1/1970#); * */PRINT ’ERROR: SSMA failed to convert the previous statement.’
日期在數(shù)據(jù)庫中是很常見的，所以這個疏忽將會影響大多數(shù)數(shù)據(jù)庫轉(zhuǎn)換。但要解決并不困難，如下：
SELECT EmployeeNo, FirstName, LastName, DateOfBirth FROM dbo.EMPLOYEES WHERE (DateOfBirth > CONVERT(DATETIME, ’1970-01-01’))
從例子中返回正確的數(shù)據(jù)集。
（我們可以討論一下是否是這樣，例如：CONVERT(DATETIME, ’1970-01-01 00:00:00’, 102)可能更恰當，但是不管怎么說，我們可以轉(zhuǎn)換數(shù)據(jù)處理），如果我們可以手動地做，SSMA就應(yīng)該可以為我們做這件事。
還有更糟糕的問題：Access默認是在文本周圍使用雙引號，例如：
SELECT EMPLOYEES.EmployeeNo, EMPLOYEES.FirstName FROM EMPLOYEES WHERE ((EMPLOYEES.FirstName="Norma"));
SQL Server不是這樣，它使用單引號，如下：WHERE EMPLOYEES.FirstName=’Norma’;然而，SSMA保留了上面這樣的雙引號代碼，沒做任何改變。而且在架構(gòu)產(chǎn)生期間并沒有引發(fā)錯誤提示，錯誤提示只發(fā)生在把架構(gòu)加載到SQL Server數(shù)據(jù)庫的過程中。那時，SSMA拋出一個錯誤提示說存在一個非法列名Norma，這樣視圖就不能加載到SQL Server中了。以上顯示出SSMA并沒有做足夠的語法檢查。
再強調(diào)一下，Access默認使用雙引號，而SSMA卻不能處理如此簡單平常的Access語法。這就像一個法語到英語的翻譯者可以處理語言中的大多數(shù)詞，卻為單詞“Bonjour”感到束手無策一樣。
再一個例子，Access允許為字段添加規(guī)則約束，例如一個名為“Title”的字段可以接受的值可能只有Mr., Mrs., Miss., Ms等。但SQL Server不能準確地支持同樣的類型約束。非常明顯SSMA轉(zhuǎn)換這種約束規(guī)則為一個表約束。Brilliant，做的不錯，只是在代碼中丟失了字段名：
ALTER TABLE [dbo].[NAMES] ADD CONSTRAINT [SSMA_CC$NAMES$Title$validation_rule] CHECK (In (’Mr.’,’Mrs.’,’Miss’,’Ms’,’Dr.’,’Prof.’))這不僅不能在架構(gòu)轉(zhuǎn)載到SQL Server時運行，同時更不能產(chǎn)生一個錯誤消息。最后一行的正確語法應(yīng)該是:CHECK (Title In (’Mr.’,’Mrs.’,’Miss’,’Ms’,’Dr.’,’Prof.’))
那么，我們是否應(yīng)該從機器上刪除SSMA呢？當然不，因為它確實完全自動地做了大量的工作，也提供了一個合理的環(huán)境，在那里可以看到問題區(qū)域并做出整理。指出它的缺陷，只是期望SSMA能更好。