标签: compatibility-level

有人可以让我更好地了解兼容模式功能吗？它的行为与我预期的不同。

据我所知，兼容模式是关于不同版本的 SQL Server 之间某些语言结构的可用性和支持。

它不会影响数据库引擎版本的内部工作。它将尝试阻止使用早期版本中尚不可用的功能和构造。

我刚刚在 SQL Server 2008 R2 中创建了一个兼容级别为 80 的新数据库。创建了一个只有一个 int 列的表，并用几行填充它。

然后用一个row_number()函数执行一个 select 语句。

我的想法是，由于 row_number 函数是在 2005 年才引入的，这会在兼容 80 模式下引发错误。

但令我惊讶的是，这工作得很好。然后，当然，只有在您“保存某些内容”时才会评估兼容规则。所以我为我的 row_number 语句创建了一个存储过程。

存储过程的创建进行得很顺利，我可以完美地执行它并获得结果。

有人可以帮助我更好地了解兼容模式的工作吗？我的理解显然有问题。

首先要做的事情是：我将 MS SQL Server 2008 与兼容级别为 80 的数据库一起使用，并使用 .Net 的System.Data.SqlClient.SqlConnection.

出于性能原因，我创建了一个索引视图。因此，视图中引用的表的更新需要使用ARITHABORT ON. 但是，探查器显示 SqlClient 正在连接ARITHABORT OFF，因此对这些表的更新失败。

是否有使 SqlClient 使用的中央配置设置ARITHABORT ON？我能找到的最好方法是在每次打开连接时手动执行该操作，但是更新现有代码库以执行此操作将是一项相当大的任务，因此我很想找到更好的方法。

我有一个Mydatabase在 SQL Server 2008 R2 中创建的数据库。我已经升级到 SQL Server 2012。

我试图执行以下查询来计算百分位数

select Distinct [KEY],PERCENTILE_CONT(0.25)  within group(order by EachPrice)
OVER(Partition By [KEY]) As Q1,PERCENTILE_CONT(0.50)  within group(order by EachPrice)
OVER(Partition By [KEY]) As Q2,
PERCENTILE_CONT(0.75)  within group(order by EachPrice)
OVER(Partition By [KEY]) As Q3,
PERCENTILE_CONT(1)  within group(order by EachPrice)
OVER(Partition By [KEY]) As Q4
from Mydatabase

但我收到一个错误说明

消息 10762，级别 15，状态 1，第 1 行
当前兼容模式下不允许使用 PERCENTILE_CONT 函数。仅允许在 110 模式或更高模式下使用。

1. 我可以将兼容模式更改为 110 吗？
2. 将兼容模式从 100 更改为 110 有什么影响？

请指教

我了解到，出于向后兼容性的原因，只要您从旧版本恢复到新版本，就可以在 SQL Server 中恢复数据库。

有谁知道您是否可以从不同版本的 SQL Server 的 *.bak 文件还原数据库？我们正在通过 FTP 移动一个非常大的数据库，这需要几天时间，所以我们宁愿只做一次。如果在我们通过 FTP 传输数据库时没有人响应，我们显然会尝试一下，通过测试看看它是否有效，然后回答我们自己的问题。

以下是获取 SQL Server 版本详细信息的查询。该productversion格式为{major revision}.{minor revision}.{release revision}.{build number}。在我的情况下，源和目标{release revision}的值为。所以看起来没问题。然而，情况不同。55005512edition

询问：

SELECT 
  SERVERPROPERTY('productversion'), 
  SERVERPROPERTY('productlevel'), 
  SERVERPROPERTY('edition')

源数据库：

10.0.5500.0
SP3
Developer Edition (64-bit)

目标数据库：

10.0.5512.0
SP3
Enterprise Edition (64-bit)

我目前正在做一个需要在不同SQL环境中运行的项目。我的大多数开发人员都有 SQL Server 2017。该应用程序在 SQL Azure 中运行，客户端最近开始运行一些使用 SQL Server 2016 的环境。该项目正在使用 SSDT 生成 Dacpac 文件，这对于开发来说工作正常，但是我们最近运行了开发人员使用 2017 年引入的系统函数的案例。引用此函数的存储过程脚本在我们的开发和 Azure 环境中运行良好，但在 2016 年环境中失败。

是否有一种简单的方法可以针对某个任意 SQL Server 版本验证脚本，而无需我们为希望支持的每个 SQL Server 版本创建多个测试环境？该方法不需要 100% 万无一失，但应该能捕捉到绝大多数潜在的兼容性问题。

有没有人为 pgAdmin 版本和 PostgreSQL 版本整理过版本兼容性矩阵？

https://www.pgadmin.org/download/windows.php

https://www.postgresql.org/download/windows/

在 SQL-Server 2005 上将 cmptlevel 设置为 80 会禁止使用 PIVOT 和 APPLY，但不会影响分析函数的使用。这背后有什么道理吗？

来自此MSDN 文章的事务复制的订阅者“在两个版本要求内”是否适用于 SQL Server 实例、数据库兼容性级别或两者？

例如，复制是否适用于这种环境设置？

• 发布者和订阅者 SQL 实例：SQL Server 2014 企业版 64 位 (12.0)
• 分销商数据库兼容级别：110
• 发布者数据库兼容级别：110
• 订阅服务器 SQL 实例：SQL Server 2017 企业版 64 位 (14.0)
• 订户数据库兼容级别：140

如何知道哪个版本的mysql客户端与哪个版本的服务器兼容？

从客户端和/或服务器的角度来看，是否存在向后或向前兼容性表？

对于给定版本的服务器，如何知道哪些客户端兼容，反之亦然？

创建表脚本

create table temp 
(
    id int identity(1,1),
    a decimal(6,2),
    b decimal(6,2),
    c decimal(6,2),
    d decimal(6,2),
    e decimal(6,2),
    f decimal(6,2),
    g decimal(6,2),
    h decimal(6,2),
    i decimal(6,2),
    j decimal(6,2),
    k decimal(6,2),
    l decimal(6,2),
    m decimal(6,2),
    n decimal(6,2),
    o decimal(6,2),
    p decimal(6,2),
    q decimal(6,2),
    r decimal(6,2),
    s decimal(6,2),
    t decimal(6,2),
    u decimal(6,2)
)

插入脚本

insert into temp
    (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u)
values
    (1,5,6,7,8,2,6,3,4,5,2,1,6,5,7,8,2,7,6,2,8)

insert into temp
    (a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u)
values
    (1,5,6,7,8,2,2,3,2,4,2,1,4,5,9,8,2,7,6,2,8)

预期结果

Median
======
first row  - 5.00
second row - 4.00 

非工作解决方案

我尝试了以下查询，该查询在 SQL Server 2014 …