从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位系统。
