便携性的32位和64位版本的SQL Server之间的SQL Server应用程序?应用程序、版本、便携性、Server

由网友(青春无限坑i)分享简介:我有一个是当前针对32位SQL Server 2005标准版数据库上运行的应用程序。至于原因,我不会进入这里,我需要将数据库迁移至64位SQL Server 2005标准版运行在64位的Windows Server 2003 R2数据中心。 I have an application that is currentl...

我有一个是当前针对32位SQL Server 2005标准版数据库上运行的应用程序。至于原因,我不会进入这里,我需要将数据库迁移至64位SQL Server 2005标准版运行在64位的Windows Server 2003 R2数据中心。

I have an application that is currently running against a 32-bit SQL Server 2005 Standard Edition database. For reasons I won't go into here, I need to move the database to a 64-bit SQL Server 2005 Standard edition running on 64-Bit Windows Server 2003 R2 Datacenter.

是否有任何迁移问题我应该在应用code,存储过程或SQL配置察觉?也就是说,在功能上相当于两个平台?

Are there any migration issues I should be aware of in the Application code, stored procedures, or SQL configuration? That is, is the functionality equivalent on both platforms?

如果有功能上的差别,你能不能张贴一个链接到一个文档与迁移规划建议?

If there are functional differences, could you post a link to a document with migration planning tips?

推荐答案

在一般情况下,这是小菜一碟。我们做了确切的事情所有的时间,没有任何问题。纯T-SQL code功能是相同的(64位只是执行得更好; - )。

In general, it's a piece of cake. We do that exact thing all of the time, with no problems. Functionality of pure t-sql code is identical (64 bit just performs better ;-).

有一个例外,这是我所遇到的扩展存储过程。因为这些都是用C写的,他们将不得不重新编译为64位二进制文​​件。即便如此,没有源$ C ​​$ C的变化应符合规定。

The one exception to this that I have encountered is extended stored procedures. Since these are written in C they would have to be recompiled as 64 bit binaries. Even then, no source code changes should be required.

如果您不使用扩展存储的特效,你应该没有问题。

If you aren't using extended stored procs you should have no problems.

阅读全文

相关推荐

最新文章