從32位到64位的SQL Server移植安裝并非是不重要的操作。在你從一個平臺移植到另一個平臺的時候，你必須考慮很多因素。本文的一些關注點特別是與32和64位平臺問題有關系的。我將會涉及如下三個最重要的問題：數據源提供商，編譯用戶自定義的函數和組件，以及數據轉換服務(DTS)包。

數據源提供商

Windows上的數據庫產品通常提供了OLE DB 或者 ODBC源提供商——這是一種中間件，注冊在允許任何支持OLE DB的應用程序與數據源進行對話的系統上。我們中的大多數人都很熟悉這種機制，SQL Server的32位版本和64位版本上也都提供了它自己的數據提供商。

當你使用64位版本的SQL Server和64位ODBC驅動的時候，要記住幾件事情。首先，32位的程序無法看到64位的ODBC驅動——它們只可以看到其它64位的應用程序，包括32位的ODBC驅動。例如，Jet數據庫引擎無法使用64位的驅動;它只能運行在32位的空間并且與32位的ODBC連接器進行對話。

然而，你應該能夠使用32位驅動與64位的數據庫應用程序進行對話，出于同樣的原因，你也能夠遠程連接一個數據服務器上，不論它運行的平臺是什么。如果真正的到數據服務器的連接是通過類似TCP/IP或者有名管道等機制實現的，那么它們就不是依賴于特定的體系結構。因此，它們可以在32位和64位的環境中工作。(注意，如果你想要這么做的話，這里可能會有一些問題，通過分布式的查詢鏈接一個32位的SQL Server實例到64位的實例上)

如果你使用的是64位的Windows，并且想要編輯32位的ODBC驅動的配置，你可以通過啟動%SystemRoot%SysWOW64odbcad32.exe程序來完成，它可以啟動32位的ODBC控制面板。默認的ODBC接口，從控制面拌中調用的，是只有64位的。

用戶自定義函數

有一點，在SQL Server中，只有按照T-SQL的位數使用SQL Server的通用語言運行時(CLR)來編寫，才有可能創建用戶自定義的函數，或者說UDF。一個用戶自定義函數可以用Visual Basic, Visual C++，或者Visual C#來編寫，然后再部署為.DLL，其性能比你用T-SQL來完成要好得多。

然而，如果你要編寫一個在數據庫的32位實現中使用的用戶自定義函數，那么它就需要在64位的平臺上進行重新編譯才能正常工作了。如果你用Visual Basic 6(計劃在2008年3月份不再支持)創建了用戶自定義函數，你需要把它導入當前的平臺上。在那里，它可以重新編譯，因為VB6沒有64位的版本。對于其它在32位平臺上編寫的與SQL Server一起工作的.DLL組件也一樣——它們需要作為64位的代碼重新編譯。

數據轉換服務

我在其它文章中談到了DTS在64位版本的SQL Server中不再可用的事實;它已經被SQL Server Integration Services (SSIS)所取代了。但是這并不意味著你再也不能使用DTS包了——只是你不能在64位目標系統中直接運行它們了。它們可以存儲在64為系統中，不只是運行在那里。

一種解決的方法就是建立一個32位的可以運行DTS包的系統，然后將數據導出到64位系統中。你甚至還可以在SQL Server所在機器(或者運行在另外一臺計算機上)上的一個虛擬機上運行一個比較老版本的帶有DTS 的SQL Server。

結論

從32位移植到64位上的障礙不再是不可逾越的——你只需要集中注意力，然后小心一點。只要你可以訪問32位的系統，或者可以在一臺虛擬機上模擬一個，你就應該有能力建立一座橋梁來溝通現有的32位系統。