這些年來，Access數據庫一直在PC平台占據主導地位，使用它建立了大量的部門數據庫。隨著這些數據庫的應用，它們中的大多數已經慢慢地具有應急使命，現在需要的是加固成為一個安全的客戶端—服務器引擎。
在微軟想要統治世界的偉大計劃中，更希望這種引擎是SQL Server。隨著這種想法，微軟針對Access提供了免費的SQL Server移植工具——SSMA。
對於開發者來說，移植工具已有很大的實惠。但期望這種工具能夠移植整個應用程序是不現實的，因為Access有一些SQL Server所沒有的簡單工具（例如窗體和報表性能）。但是我們有理由相信這種工具能做大部分工作，比如建立適當的表，轉移數據，把查詢轉換成視圖等。
SSMA的運行需要在.Net Framework2.0版本以上，J#2.0可重組包以及至少1GB RAM。
SSMA具有一個清晰的圖形用戶界面，分成四個面板。在建立一個新工程之後，首先添加一個或多個Access數據庫，然後連接到適當的SQL Server數據庫，下一步就是把架構（schema）轉換成SQL Server。
注意，這個過程並不是運行依靠SQL Server引擎的架構，而是簡單地生成了一個在SSMA中可見的，可用的SQL Server架構，同時生成一個錯誤、警告和信息標記的集合。
從這點來看，該工具的能力就顯而易見。作為一個開始，這些標記指出轉換問題，例如：不支持Access的一些函數如DateDiff，所以不能轉換（當然這些函數可以被轉換，但SSMA不能實現）。
你可以浏覽Access架構，觀察正在計劃的類型映射等等，當然如果你不喜歡這種缺省映射，也完全可以改變它，或者根據特殊的工程甚至特殊的表來做改變。
查詢是一個比較特別的情形。它們被轉換成SQL Server視圖：你可以編輯Access查詢然後產生適當的SQL Server代碼。這樣的編輯是發生在SSMA的架構中，而不是在Access數據庫本身完成。
你可以使用SSMA運行依靠數據庫的SQL Server架構，它建立了一種結構來保存數據以便你可以移植數據。理論上聽起來很好，但是實際上是怎樣的呢？雖說嘗試從任意一個數據庫引擎移植到另一個都是麻煩的，且這個工具可以免費的為你做90%的工作，但它還存在一些缺陷。
例如，雖然不是SQL標准的一部分，Access需要所有日期來包裝到hash記號中。不幸的是，SSMA看起來沒有考慮到這點，這個疏忽的結果就是所有涉及到日期的查詢結果都不能成功轉換。下面是一個錯誤信息的例子：
/* * 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.'
這些年來，Access數據庫一直在PC平台占據主導地位，使用它建立了大量的部門數據庫。隨著這些數據庫的應用，它們中的大多數已經慢慢地具有應急使命，現在需要的是加固成為一個安全的客戶端—服務器引擎。
在微軟想要統治世界的偉大計劃中，更希望這種引擎是SQL Server。隨著這種想法，微軟針對Access提供了免費的SQL Server移植工具——SSMA。
對於開發者來說，移植工具已有很大的實惠。但期望這種工具能夠移植整個應用程序是不現實的，因為Access有一些SQL Server所沒有的簡單工具（例如窗體和報表性能）。但是我們有理由相信這種工具能做大部分工作，比如建立適當的表，轉移數據，把查詢轉換成視圖等。
SSMA的運行需要在.Net Framework2.0版本以上，J#2.0可重組包以及至少1GB RAM。
SSMA具有一個清晰的圖形用戶界面，分成四個面板。在建立一個新工程之後，首先添加一個或多個Access數據庫，然後連接到適當的SQL Server數據庫，下一步就是把架構（schema）轉換成SQL Server。
注意，這個過程並不是運行依靠SQL Server引擎的架構，而是簡單地生成了一個在SSMA中可見的，可用的SQL Server架構，同時生成一個錯誤、警告和信息標記的集合。
從這點來看，該工具的能力就顯而易見。作為一個開始，這些標記指出轉換問題，例如：不支持Access的一些函數如DateDiff，所以不能轉換（當然這些函數可以被轉換，但SSMA不能實現）。
你可以浏覽Access架構，觀察正在計劃的類型映射等等，當然如果你不喜歡這種缺省映射，也完全可以改變它，或者根據特殊的工程甚至特殊的表來做改變。
查詢是一個比較特別的情形。它們被轉換成SQL Server視圖：你可以編輯Access查詢然後產生適當的SQL Server代碼。這樣的編輯是發生在SSMA的架構中，而不是在Access數據庫本身完成。
你可以使用SSMA運行依靠數據庫的SQL Server架構，它建立了一種結構來保存數據以便你可以移植數據。理論上聽起來很好，但是實際上是怎樣的呢？雖說嘗試從任意一個數據庫引擎移植到另一個都是麻煩的，且這個工具可以免費的為你做90%的工作，但它還存在一些缺陷。
例如，雖然不是SQL標准的一部分，Access需要所有日期來包裝到hash記號中。不幸的是，SSMA看起來沒有考慮到這點，這個疏忽的結果就是所有涉及到日期的查詢結果都不能成功轉換。下面是一個錯誤信息的例子：
/* * 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.'
日期在數據庫中是很常見的，所以這個疏忽將會影響大多數數據庫轉換。但要解決並不困難，如下：
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能更好。
