sql-server - 如何使应用程序与 SQL Server 2005 完全兼容？

Question

我们有一个使用 MSSQL 的应用程序，当我们移到 2005 年时，基本上我们建议我们的客户应用向后兼容包，仅此而已，但有人问我要在 2005 年做到 100% 兼容。我在想 1 . 兼容级别：SQL Server 2005 (90) 2. 删除任何DMO引用，并替换为SMO 3. 使用ADO连接

我不确定这是否是正确的答案。

Answer 1

其实你说的是两种不同的东西。

一种是将数据库更新到 SQL 2005 级别，以便能够使用只有那里可用的功能。通过设置兼容性级别可以轻松完成。但是，在这种情况下，SQL 2000 客户端可能会遇到问题。

其次是升级您的应用程序以仅使用 SQL 2005 相关库。这也很简单，基本上就是你写的步骤。在这种情况下，您的应用程序也可以使用 SQL 2000 数据库（除非您使用某些 SQL 2005 特定功能），因为这些库是向后兼容的。

结束语：无论哪种方式都与 SQL 2005兼容，唯一的区别是您可以使用或不使用 SQL 2005 的特定功能。

为什么不改成 SQL 2008 呢？这是一个关于这个主题的线程。

Answer 2

要查看您是否真的兼容，唯一的方法是在没有向后兼容包的 SQL 2005 服务器上运行您的应用程序。如果您有一个详尽的测试套件，它将有很大帮助，但您需要确保您的所有后端代码都能正常运行。

我曾在一个使用 SQL 2000 和 SQL 2005 的应用程序上工作过，该应用程序中唯一需要版本切换的部分是一些毛茸茸的反射代码，需要使用 SQL Server 的系统表在运行时动态发现表。我们的解决方案是使用动态 SQL，但您需要为您的应用程序和用户做出正确的选择。

如果您的应用程序可以在“开箱即用”的 SQL 2005 配置上正确运行，而无需应用任何向后兼容性修复程序，那么您的应用程序就是 100% SQL 2005 兼容的。

Answer 3

如果您有任何 DTS 包，则需要将它们转换为 SSIS 包才能完全兼容。

如果您真的想确保完全兼容，请在文档中查看哪些功能正在被弃用，如果您正在使用其中任何一个，请立即修复它们。

您还可以查看您拥有的任何可以使用 2000 年没有的枢轴功能的代码。旧代码可以工作，但枢轴代码将是更好的选择，并且可能更有效。其他新功能也是如此，请检查您如何解决它们并进行修复。要考虑的一个重要问题是，您是否可以使用新数据类型 varchar (max) 摆脱文本文件。然后在代码中查找要转换为 varchar 的位置以进行比较。