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

數(shù)據(jù)源提供商

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

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

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

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

用戶自定義函數(shù)

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

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

數(shù)據(jù)轉換服務

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

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

結論

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