问题标签 [compatibility-level]

我计划将 SQL Server 2000 实例升级到 SQL Server 2005 实例。

我不会更改任何数据库代码，因此不会利用任何 SQL2005 特定语法。是否有任何理由将我的兼容性设置得更高（至 9 级）？或者可以离开兼容级别 8 吗？

我们有一个 Sql Server 2005 数据库。无论出于何种原因，兼容级别（例如通过 sp_dbcmptlevel）设置为 80（即 Sql Server 2000）。

这样做的后果是什么？我的应用程序是否因此而受到性能损失？

这个查询（或者类似的查询）在我们已经部署的代码库中。

DB 是连接到数据库的数据上下文。TimeBlocks 是一个相当简单的表，StartDate 是一个 DateTime 列。

目前，数据库托管在 Sql Server 2005 安装上，但我们正在升级到 Sql Server 2008 安装。

查询当前执行没有问题。

如果我们将连接字符串更改为指向在 Sql Server 2008 上运行的同一数据库的副本（兼容性级别设置为 2005），则查询将失败并出现 SqlException：

“日期函数 dateadd 不支持数据类型 date 的 datepart 毫秒。”

这似乎是由于 Linq to SQL 在连接到 2008db 时发出的不同 sql（我认为这是因为它使用 Sql2008Provider 而不是 Sql2005Provider）。

2005 Provider 产生良好的 SQL：

成功执行查询。但是Sql2008Provider发出的sql：

包含导致异常的错误 sql。

我认为是导致此问题的 Sql 提供程序是否正确？

有没有办法通过强制 DataContext 为这个数据库使用 Sql2005Provider 来解决这个问题？

感谢您能给我们的任何帮助！

如果我在兼容级别 90 (sql 2005) 中运行 sql server 2008，它是使用资源数据库中的停止列表还是使用 ftdata\ENU.txt 文件？

另外，如果我在 2008 年制作了自己的停止列表（使用兼容性 100），我可以忽略系统停止列表并在全文查询中使用我自己的停止列表，还是会使用系统和我的自定义停止列表？

我有很多全文索引问题。Web 上处理停止列表的任何好的 sql 资源，多个表包含多个表。大型记录集？？？？

谢谢！

我可以在 ADO.NET 连接字符串中指定什么类型的系统版本（兼容级别）令牌以指示仅支持 SQL Server 2012？

我们需要在 SQL Server 2005 数据库上执行查询，以获取有关最长执行时间的一些统计信息。

我们找到了下一个查询：

它工作正常，但它要求数据库具有 90 兼容级别（SQL Server 2005）。这个数据库有80级（SQL Server 2000）。换成90的话……会不会对日常任务有危险？我的意思是，如果我们更改它，我们的应用程序会崩溃吗？

谢谢和对不起我的英语。

我需要将供应商提供的客户端服务器应用程序中的数据库迁移到 SQL Server 2008。我们运行的应用程序版本在 SQL Server 2000 SP4 和 SQL Server 2005 SP2 上受支持，但在 2008 上不支持 - 但是原因是主要是因为供应商希望我们升级到当前版本（计划在 2014 年第 1 季度/第 2 季度推出），并且不想“让”我们继续使用旧版本的应用程序。

我的问题是，如果我在兼容级别 80 的 SQL Server 2008 上恢复数据库，并且不对它进行任何更改（它是供应商数据库），会出现什么问题？我知道我无法将数据库恢复到 2005/2000 - 这没有必要。我更关心假定 2005 或更低版本的 procs 中可能被编码的内容 - 到目前为止，我已经找到了一个示例，并且修改版本语句 (@@version = "SQL Server 2008") 起到了作用。还有什么要考虑的？仅供参考 - 仅使用标准数据库对象 - 没有作业、DTS、SSRS、SSIS 等。此外，我在 2008 年完成了广泛的应用程序测试，到目前为止没有任何问题。

当我尝试在 SQL Server 2012 中将兼容性级别设置为 80 时：

我收到以下错误：

消息 15048，级别 16，状态 1
数据库兼容级别的有效值为 90、100 或 110。

有什么解决方法吗？

我有一个连接到 SQL Server 2008 数据库并执行存储过程的 C++ dll。SQL Server 正在为此数据库使用兼容级别 80。与服务器的连接是通过 ADO 使用 SQL Server OLE_DB 驱动程序完成的。客户想升级到SQL Server 2012，只支持兼容级别90及以上。

存储过程接受两个 varchar 输入值并返回 2 个 varchar 和 2 个整数输出值。DLL 中的 C++ 代码创建并初始化 7 个 VARIANT，然后使用这些变量将 7 个参数添加到 ADO 连接对象的参数集合中。VARIANT 和参数类型如下：

执行命令后，将检索输出 VARIANTS 中的值并将其返回给调用程序。

ret_barcode 参数中的存储过程返回的值是从数据库中读取的值。针对 SQL Server 2012 测试此 dll 时，未正确返回 varchar 值。ret_barcode VARIANT 中包含的实际值是文本“<strong>return_more_rows”，它是最后一个输出参数的名称！如果在存储过程的最后我将 ret_barcode 参数的值设置为字符串常量，只要字符串常量不超过 13 个字符，正确的值就会显示在 C++ dll 中。

使用 ADO.NET 的简单 C# 测试程序按预期运行。

如果我将存储过程中的 ret_barcode 变量的类型更改为 char(30)，则在 ret_barcode VARIANT 中返回正确的值。在调试时，我使用 Parameter.Refresh 方法来确定存储过程所期望的参数类型。在这两种情况下，ret_barcode 参数都是 adVarChar。这使我相信服务器打包数据并将数据传输到客户端的方式会有所不同，具体取决于其兼容性级别。

我读到的有关兼容性级别的内容似乎表明它们只是公开或限制功能。有谁知道兼容性级别 80 和 90 之间发生了什么变化导致了这个问题，或者我可以在 DLL 中做什么来支持来自 DB 的 varchar 数据？

I recently took over a SQL Server running SQL Server 2012. One of the databases is running at compatibility level 90 (SQL Server 2005). I've learned that the database originated on a 2005 server and was migrated over. The developers are claiming there's no need to keep it at 90.

Is there a way to check whether any of the code in the database relies on 2005 features or syntax?

I could back up the database and restore a new copy, then convert the copy to 2012 mode, but would that actually tell me anything? I don't want to end up in a situation where I've changed it, then find out days or weeks later that some function or procedure is broken.