ALTER DATABASE (Transact-SQL) 互換性レベルALTER DATABASE (Transact-SQL) Compatibility Level

適用対象: ○SQL Server (2008 以降) ○Azure SQL Database XAzure SQL Data Warehouse XParallel Data Warehouse APPLIES TO: yesSQL Server (starting with 2008) yesAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

データベースの特定の動作に、指定したバージョンの SQL ServerSQL Server との互換性を設定します。Sets certain database behaviors to be compatible with the specified version of SQL ServerSQL Server. ALTER DATABASE の他のオプションについては、「ALTER DATABASE」をご覧ください。For other ALTER DATABASE options, see ALTER DATABASE.

構文表記規則の詳細については、「Transact-SQL 構文表記規則」を参照してください。For more information about the syntax conventions, see Transact-SQL Syntax Conventions.

構文Syntax

ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = { 150 | 140 | 130 | 120 | 110 | 100 | 90 }

引数Arguments

database_name 変更するデータベースの名前です。database_name Is the name of the database to be modified.

COMPATIBILITY_LEVEL { 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 } データベースの互換性の対象となる SQL ServerSQL Server のバージョンです。COMPATIBILITY_LEVEL { 150 | 140 | 130 | 120 | 110 | 100 | 90 | 80 } Is the version of SQL ServerSQL Server with which the database is to be made compatible. 次の互換性レベルの値を構成することができます (上で示したすべての互換性レベルをすべてのバージョンがサポートしているわけではありません)。The following compatibility level values can be configured (not all versions supports all of the above listed compatibility level):

ProductProduct データベース エンジンのバージョンDatabase Engine Version 互換性レベルの指定Compatibility Level Designation サポートされている互換性レベル値Supported Compatibility Level Values
SQL Server 2019 プレビューSQL Server 2019 preview 1515 150150 150, 140, 130, 120, 110, 100150, 140, 130, 120, 110, 100
SQL Server 2017 (14.x)SQL Server 2017 (14.x) 1414 140140 140, 130, 120, 110, 100140, 130, 120, 110, 100
Azure SQL データベースAzure SQL Database 単一データベース/エラスティック プールsingle database/elastic pool 1212 130130 150, 140, 130, 120, 110, 100150, 140, 130, 120, 110, 100
Azure SQL データベースAzure SQL Database マネージド インスタンスmanaged instance 1212 130130 150, 140, 130, 120, 110, 100150, 140, 130, 120, 110, 100
SQL Server 2016 (13.x)SQL Server 2016 (13.x) 1313 130130 130, 120, 110, 100130, 120, 110, 100
SQL Server 2014 (12.x)SQL Server 2014 (12.x) 1212 120120 120, 110, 100120, 110, 100
SQL Server 2012 (11.x)SQL Server 2012 (11.x) 1111 110110 110, 100, 90110, 100, 90
SQL Server 2008 R2SQL Server 2008 R2 10.510.5 100100 100, 90, 80100, 90, 80
SQL Server 2008:SQL Server 2008 1010 100100 100, 90, 80100, 90, 80
SQL Server 2005 (9.x)SQL Server 2005 (9.x) 99 9090 90, 8090, 80
SQL Server 2000SQL Server 2000 88 8080 8080

注意

2018 年 1 月の時点で、Azure SQL データベースAzure SQL Database で新しく作成されたデータベースの既定の互換性レベルは 140 です。As of January 2018, in Azure SQL データベースAzure SQL Database, the default compatibility level is 140 for newly created databases. 既存のデータベースに対してデータベースの互換性レベルは更新されません。We do not update database compatibility level for existing databases. これは、お客様の独自の裁量にまかされます。This is up to customers to do at their own discretion. このため、お客様が最新の改善点を活用するために、最新の互換性レベルに移行することを強くお勧めします。With that said, we highly recommend customers plan on moving to the latest compatibility level in order to leverage the latest improvements.

お使いのデータベース全体でデータベース互換性レベル 140 を活用するとき、SQL Server 2012 (11.x)SQL Server 2012 (11.x)カーディナリティ推定モデル、データベース互換性レベル 110 へのマッピングを選択するのであれば、ALTER DATABASE SCOPED CONFIGURATION に関するページを参照してください。特にそのキーワード LEGACY_CARDINALITY_ESTIMATION = ON をご覧ください。If you want to leverage database compatibility level 140 for your database overall, but you have reason to prefer the cardinality estimation model of SQL Server 2012 (11.x)SQL Server 2012 (11.x), mapping to database compatibility level 110, see ALTER DATABASE SCOPED CONFIGURATION, and in particular its keyword LEGACY_CARDINALITY_ESTIMATION = ON.

Azure SQL データベースAzure SQL Database における 2 つの互換性レベル間での、最も重要なクエリのパフォーマンスの違いを評価する方法の詳細については、「Improved Query Performance with Compatibility Level 130 in Azure SQL Database」 (Azure SQL Database での互換性レベル 130 によるクエリ パフォーマンスの改善) を参照してください。For details about how to assess the performance differences of your most important queries, between two compatibility levels on Azure SQL データベースAzure SQL Database, see Improved Query Performance with Compatibility Level 130 in Azure SQL Database. この記事では互換性レベル 130 と SQL ServerSQL Server を取り上げていますが、SQL ServerSQL ServerAzure SQL データベースAzure SQL Database で 140 に移行する場合も同じ手法が適用されます。Note that this article refers to compatibility level 130 and SQL ServerSQL Server, but the same methodology applies for moves to 140 for SQL ServerSQL Server and Azure SQL データベースAzure SQL Database .

次のクエリを実行して、接続先である データベース エンジンDatabase Engine のバージョンを特定します。Execute the following query to determine the version of the データベース エンジンDatabase Engine that you are connected to.

SELECT SERVERPROPERTY('ProductVersion');

注意

Azure SQL データベースAzure SQL Database では、互換性レベルに依存する機能がすべてサポートされているわけではありません。Not all features that vary by compatibility level are supported on Azure SQL データベースAzure SQL Database.

現在の互換性レベルを特定するには、sys.databasescompatibility_level 列に対してクエリを実行します。To determine the current compatibility level, query the compatibility_level column of sys.databases.

SELECT name, compatibility_level FROM sys.databases;

RemarksRemarks

SQL ServerSQL Server のすべてのインストールで、既定の互換性レベルは データベース エンジンDatabase Engine のバージョンに設定されます。For all installations of SQL ServerSQL Server, the default compatibility level is set to the version of the データベース エンジンDatabase Engine. データベースはこのレベルに設定されますが、model データベースの互換性レベルがこれより低い場合は例外です。Databases are set to this level unless the model database has a lower compatibility level. 以前のバージョンの SQL ServerSQL Server からデータベースをアップグレードした場合、そのデータベースの互換性レベルが SQL ServerSQL Server の該当するインスタンスに対して許可される最低レベル以上であれば、既存の互換性レベルが維持されます。When a database is upgraded from any earlier version of SQL ServerSQL Server, the database retains its existing compatibility level, if it is at least minimum allowed for that instance of SQL ServerSQL Server. 許可されるレベルより低い互換性レベルのデータベースをアップグレードするには、許可される最も下の互換性レベルにデータベースを自動的に設定します。Upgrading a database with a compatibility level lower than the allowed level, automatically sets the database to the lowest compatibility level allowed. これはシステム データベースとユーザー データベースの両方に適用されます。This applies to both system and user databases.

SQL Server 2017 (14.x)SQL Server 2017 (14.x) では、データベースを装着したか復元したとき、また、インプレース アップグレード後、以下の動作が予想されます。The below behaviors are expected for SQL Server 2017 (14.x)SQL Server 2017 (14.x) when a database is attached or restored, and after an in-place upgrade:

  • アップグレード前のユーザー データベースの互換性レベルが 100 以上の場合は、アップグレード後も互換性レベルは変わりません。If the compatibility level of a user database was 100 or higher before the upgrade, it remains the same after upgrade.
  • アップグレード前のユーザー データベースの互換性レベルが 90 の場合、アップグレードされたデータベースの互換性レベルは 100 に設定されます。これは、SQL Server 2017 (14.x)SQL Server 2017 (14.x) でサポートされている下限の互換性レベルです。If the compatibility level of a user database was 90 before upgrade, in the upgraded database, the compatibility level is set to 100, which is the lowest supported compatibility level in SQL Server 2017 (14.x)SQL Server 2017 (14.x).
  • tempdb、model、msdb、および Resource データベースの互換性レベルは、アップグレード後に現在の互換性レベルに設定されます。The compatibility levels of the tempdb, model, msdb and Resource databases are set to the current compatibility level after upgrade.
  • master システム データベースは、アップグレード前の互換性レベルを保持します。The master system database retains the compatibility level it had before upgrade.

ALTER DATABASE を使用し、データベースの互換性レベルを変更します。Use ALTER DATABASE to change the compatibility level of the database. データベースの新しい互換性レベル設定は USE <database> コマンドが発行されたときか、新しいログインがそのデータベースで既定のデータベース コンテキストとして処理されたときに有効になります。The new compatibility level setting for a database takes effect when a USE <database> command is issued, or a new login is processed with that database as the default database context. データベースの現在の互換性レベルを確認するには、sys.databases カタログ ビューの compatibility_level 列をクエリします。To view the current compatibility level of a database, query the compatibility_level column in the sys.databases catalog view.

注意

以前のバージョンの SQL ServerSQL Server で作成され、SQL Server 2016 (13.x)SQL Server 2016 (13.x) RTM または Service Pack 1 にアップグレードされるディストリビューション データベースは、互換性レベルが 90 であり、その他のデータベースではサポートされません。A distribution database that was created in an earlier version of SQL ServerSQL Server and is upgraded to SQL Server 2016 (13.x)SQL Server 2016 (13.x) RTM or Service Pack 1 has a compatibility level of 90, which is not supported for other databases. これはレプリケーションの機能には影響がありません。This does not have an impact on the functionality of replication. 新しいバージョンのサービス パックと SQL ServerSQL Server にアップグレードすると、分散データベースの互換性レベルが増加し、マスター データベースの互換性レベルと一致します。Upgrading to later service packs and versions of SQL ServerSQL Server will result in the compatibility level of the distribution database to be increased to match that of the master database.

互換性レベルと SQL Server アップグレードCompatibility Levels and SQL Server Upgrades

データベース互換レベルは、SQL Server データベース エンジンSQL Server Database Engine のアップグレードを可能にし、それと同時に、アップグレード前と同じデータベース互換性レベルを維持することでデータベースに接続するアプリケーションの機能的な状態を維持するという点で、データベースの現代化支援に不可欠なツールです。Database compatibility level is a valuable tool to assist in database modernization, by allowing the SQL Server データベース エンジンSQL Server Database Engine to be upgraded, while keeping connecting applications functional status by maintaining the same pre-upgrade database compatibility level. 上位のデータベース互換性レベルでのみ利用できる拡張をアプリケーションが活用する必要がない限り、SQL Server データベース エンジンSQL Server Database Engine をアップグレードし、同時に前のデータベース互換性レベルを維持することは有効なアプローチです。As long as the application does not need to leverage enhancements that are only available in a higher database compatibility level, it is a valid approach to upgrade the SQL Server データベース エンジンSQL Server Database Engine and maintain the previous database compatibility level. 下位互換性で互換性レベルを使用する方法については、この記事の後半に出てくる「旧バージョンとの互換性を維持するための互換性レベルの使用」を参照してください。For more information on using compatibility level for backward compatibility, see the Using Compatibility Level for Backward Compatibility later in this article.

新しい開発作業の場合、あるいは新しい機能とクエリ オプティマイザー スペースで行われたパフォーマンス改善を既存のアプリケーションで使用する必要があるとき、データベース互換性レベルを SQL ServerSQL Server で利用できる最新のレベルにアップグレードすることを計画し、その互換性レベルでアプリケーションが動作することを確認します。For new development work, or when an existing application requires use of new features, as well as performance improvements done in the query optimizer space, plan to upgrade the database compatibility level to the latest available in SQL ServerSQL Server, and certify your application to work with that compatibility level. データベース互換性レベルのアップグレードについては、この記事の後半に出てくる「データベース互換性レベルのアップグレードのベスト プラクティス」を参照してください。For more details on upgrading the database compatibility level, see the Best Practices for upgrading Database Compatibility Level later in the article.

ヒント

あるアプリケーションが特定の SQL ServerSQL Server バージョンでテストされ、確認された場合、そのアプリケーションはその SQL ServerSQL Server バージョンのネイティブ データベース互換性レベルで暗黙的にテストされ、確認されたことになります。If an application was tested and certified on a given SQL ServerSQL Server version, then it was implicitly tested and certified on that SQL ServerSQL Server version native database compatibility level.

そのため、データベース互換性レベルは、テストされた SQL ServerSQL Server バージョンに該当するデータベース互換性レベルを使用するとき、既存のアプリケーションの互換性を簡単に証明する方法となります。So, database compatibility level provides an easy certification path for an existing application, when using the database compatibility level corresponding to the tested SQL ServerSQL Server version.

互換性レベルの違いについては、この記事の後半に出てくるセクションを参照してください。For more information about differences between compatibility levels, see the appropriate sections later in this article.

アップグレード前に存在したデータベース互換性レベルとそのサポート可能なステータスを維持しながら、SQL Server データベース エンジンSQL Server Database Engine を最新バージョンにアップグレードするには、Microsoft Data Migration Assistant ツール (DMA) を使用し、データベースのアプリケーション コードの攻撃可能な領域に静的な機能検証を実行することをお勧めします。To upgrade the SQL Server データベース エンジンSQL Server Database Engine to the latest version, while maintaining the database compatibility level that existed before the upgrade and its supportability status, it is recommended to perform static functional surface area validation of the application code in the database, by using the Microsoft Data Migration Assistant tool (DMA). DMA ツールの出力でエラーが見つからなければ、あるいは機能性に不足や非互換性がなければ、新しいターゲット バージョンでアプリケーションの機能が退化することはありません。The absence of errors in the DMA tool output, about missing or incompatible functionality, protects application from any functional regressions on the new target version. DMA ツールの詳細については、こちらを参照してください。For more information on the DMA tool, see here.

注意

DMA は、レベル 100 以降のデータベース互換性レベルに対応しています。DMA supports database compatibility level 100 and above. ソース バージョンとしての SQL Server 2005 (9.x)SQL Server 2005 (9.x) は除外されます。SQL Server 2005 (9.x)SQL Server 2005 (9.x) as source version is excluded.

重要

Microsoft では、最小限のテストをいくつか行い、アップグレードが成功し、さらに前のデータベース互換性レベルが維持されていることを確認することをお勧めしています。Microsoft recommends that some minimal testing is done to validate the success of an upgrade, while maintaining the previous database compatibility level. 自分のアプリケーションとシナリオでは何が「最小限のテスト」に相当するのかは、ご自身で判断してください。You should determine what minimal testing means for your own application and scenario.

注意

Microsoft は、次の場合にクエリ プラン シェイプ保護を提供します。Microsoft provides query plan shape protection when:

  • 前の SQL ServerSQL Server バージョン (ソース) が実行されていたハードウェアに相当するハードウェアで新しい SQL ServerSQL Server バージョン (ターゲット) が実行されるとき。The new SQL ServerSQL Server version (target) runs on hardware that is comparable to the hardware where the previous SQL ServerSQL Server version (source) was running.
  • ターゲット SQL ServerSQL Server とソース SQL ServerSQL Server の両方で同じサポートされているデータベース互換性レベルが使用されるとき。The same supported database compatibility level is used both at the target SQL ServerSQL Server and source SQL ServerSQL Server.

上の条件で発生する (ソース SQL ServerSQL Server と比較したときの) クエリ プラン シェイプ退化は対処されます。Any query plan shape regression (as compared to the source SQL ServerSQL Server) that occurs in the above conditions will be addressed. このような場合は、Microsoft カスタマー サポートにお問い合わせください。Please contact Microsoft Customer Support if this is the case.

旧バージョンとの互換性を維持するための互換性レベルの使用Using Compatibility Level for Backward Compatibility

データベース互換性レベル設定は、サーバー全体ではなく、指定したデータベースの動作にのみ影響します。The database compatibility level setting affects behaviors only for the specified database, not for the entire server. データベース互換性レベルでは、以前のバージョンの SQL ServerSQL Server との部分的な下位互換性だけが保たれます。Database compatibility level provides only partial backward compatibility with earlier versions of SQL ServerSQL Server.

ヒント

"データベース互換性レベル" はデータベース レベルの設定なので、新しい SQL Server データベース エンジンSQL Server Database Engine で実行しているアプリケーションが古いデータベース互換性レベルを使用している場合でも、アプリケーションを変更する必要なく、サーバー レベルの拡張機能を利用できます。Because database compatibility level is a database-level setting, an application running on a newer SQL Server データベース エンジンSQL Server Database Engine while using an older database compatibility level, can still leverage server-level enhancements without any requirement for application changes.

これには、新しいシステム動的管理ビュー拡張イベントなど、豊富な監視とトラブルシューティングに関する改善が含まれます。These include rich monitoring and troubleshooting improvements, with new System Dynamic Management Views and Extended Events. また、自動ソフト NUMA などのスケーラビリティの向上も含まれます。And also improved scalability, for example with Automatic Soft-NUMA .

互換モード 130 以降、機能に影響を与える新しいクエリ プランは、新しい互換性レベルにのみ意図的に追加されています。Starting with compatibility mode 130, any new query plan affecting features have been intentionally added only to the new compatibility level. これは、クエリ プランの変更によるパフォーマンスの低下から発生するアップグレード中に、リスクを最小限に抑えるために追加されました。This has been done in order to minimize the risk during upgrades that arise from performance degradation due to query plan changes. アプリケーションの観点からは、新しい機能のいくつかを継承し、クエリ オプティマイザー スペースで行われたパフォーマンス改善を継承するために、ある時点で最新の互換性レベルにアップグレードすることは目的であり続けますが、それをコントロールされた方法で行います。From an application perspective, the goal should still be to upgrade to the latest compatibility level at some point in time, in order to inherit some of the new features, as well as performance improvements done in the query optimizer space, but to do so in a controlled way. 関連する互換性レベル設定によって制御される動作では、安全な移行補助として下位の互換性レベルを使用し、バージョンの違いに対処してください。Use the lower compatibility level as a safer migration aid to work around version differences, in the behaviors that are controlled by the relevant compatibility level setting. データベース互換性レベルのアップグレードで推奨されるワークフローなど、詳細については、この記事の後半に出てくる「データベース互換性レベルのアップグレードのベスト プラクティス」を参照してください。For more details, including the recommended workflow for upgrading database compatibility level, see the Best Practices for upgrading Database Compatibility Level later in the article.

重要

特定の SQL ServerSQL Server バージョンで導入された機能が廃止されている場合、その機能は互換性レベルによって保護されません。Discontinued functionality introduced in a given SQL ServerSQL Server version is not protected by compatibility level. これは、SQL Server データベース エンジンSQL Server Database Engine から削除された機能に当てはまります。This refers to functionality that was removed from the SQL Server データベース エンジンSQL Server Database Engine. たとえば、FASTFIRSTROW ヒントは SQL Server 2012 (11.x)SQL Server 2012 (11.x) で廃止され、OPTION (FAST n ) ヒントに置き換えられました。For example, the FASTFIRSTROW hint was discontinued in SQL Server 2012 (11.x)SQL Server 2012 (11.x) and replaced with the OPTION (FAST n ) hint. データベースの互換性レベルを 110 に設定すると、廃止されたヒントは復元されません。Setting the database compatibility level to 110 will not restore the discontinued hint. 廃止された機能の詳細については、「SQL Server 2016 で廃止されたデータベース エンジンの機能」、「SQL Server 2014 で廃止されたデータベース エンジンの機能」、「SQL Server 2012 で廃止されたデータベース エンジンの機能」、および「SQL Server 2008 で廃止されたデータベース エンジンの機能」を参照してください。For more information on discontinued functionality, see Discontinued Database Engine Functionality in SQL Server 2016, Discontinued Database Engine Functionality in SQL Server 2014), Discontinued Database Engine Functionality in SQL Server 2012), and Discontinued Database Engine Functionality in SQL Server 2008).

重要

特定の SQL ServerSQL Server バージョンで導入された重大な変更が、互換性レベルによって保護されない可能性がありますBreaking changes introduced in a given SQL ServerSQL Server version may not be protected by compatibility level. これは、SQL Server データベース エンジンSQL Server Database Engine のバージョン間の動作変更に当てはまります。This refers to behavior changes between versions of the SQL Server データベース エンジンSQL Server Database Engine. Transact-SQLTransact-SQL の動作は、通常、互換性レベルで保護されます。behavior is usually protected by compatibility level. ただし、変更または削除されたシステム オブジェクトは、互換性レベルで保護されませんHowever, changed or removed system objects are not protected by compatibility level.

互換性レベルで保護される重大な変更の例としては、datetime データ型から datetime2 データ型への暗黙的な変換が挙げられます。An example of a breaking change protected by compatibility level is an implicit conversion from datetime to datetime2 data types. データベース互換性レベル 130 では、これらの変換が行われると小数ミリ秒を考慮することで精度が上がり、結果的に異なる変換値が生成されます。Under database compatibility level 130, these show improved accuracy by accounting for the fractional milliseconds, resulting in different converted values. 以前の変換動作を復元するには、データベース互換性レベルを 120 以下に設定します。To restore previous conversion behavior, set the database compatibility level to 120 or lower.

互換性レベルで保護されない重大な変更の例としては、次のような内容が挙げられます。Examples of breaking changes not protected by compatibility level are:

  • システム オブジェクトで変更された列名。Changed column names in system objects. SQL Server 2012 (11.x)SQL Server 2012 (11.x) では、sys.dm_os_sys_info 内の列 single_pages_kb の名前が pages_kb に変更されました。In SQL Server 2012 (11.x)SQL Server 2012 (11.x) the column single_pages_kb in sys.dm_os_sys_info was renamed to pages_kb. 互換性レベルに関係なく、クエリ SELECT single_pages_kb FROM sys.dm_os_sys_info によってエラー 207 (無効な列名) が生成されます。Regardless of the compatibility level, the query SELECT single_pages_kb FROM sys.dm_os_sys_info will produce error 207 (Invalid column name).
  • 削除されたシステム オブジェクト。Removed system objects. SQL Server 2012 (11.x)SQL Server 2012 (11.x) では、sp_dboption が削除されました。In SQL Server 2012 (11.x)SQL Server 2012 (11.x) the sp_dboption was removed. 互換性レベルに関係なく、ステートメント EXEC sp_dboption 'AdventureWorks2016CTP3', 'autoshrink', 'FALSE'; はエラー 2812 (ストアド プロシージャ 'sp_dboption' が見つかりませんでした) を生成します。Regardless of the compatibility level, the statement EXEC sp_dboption 'AdventureWorks2016CTP3', 'autoshrink', 'FALSE'; will produce error 2812 (Could not find stored procedure 'sp_dboption').

重大な変更の詳細については、「SQL Server 2017 におけるデータベース エンジン機能の重大な変更」、「SQL Server 2016 におけるデータベース エンジン機能の重大な変更」、「 SQL Server 2014 におけるデータベース エンジン機能の重大な変更」、「SQL Server 2012 におけるデータベース エンジン機能の重大な変更、およびSQL Server 2008 におけるデータベース エンジン機能の重大な変更」を参照してください。For more information on breaking changes, see Breaking Changes to Database Engine Features in SQL Server 2017, Breaking Changes to Database Engine Features in SQL Server 2016, Breaking Changes to Database Engine Features in SQL Server 2014), Breaking Changes to Database Engine Features in SQL Server 2012), and Breaking Changes to Database Engine Features in SQL Server 2008).

データベース互換性レベルのアップグレードのベスト プラクティスBest Practices for upgrading Database Compatibility Level

互換性レベルをアップグレードする場合にお勧めするワークフローについては、「データベース互換性モードの変更とクエリ ストアの使用」を参照してください。For the recommended workflow for upgrading the compatibility level, see Change the Database Compatibility Mode and Use the Query Store.

互換性レベルとストアド プロシージャCompatibility Levels and Stored Procedures

ストアド プロシージャを実行すると、そのストアド プロシージャが定義されているデータベースの現在の互換性レベルが使用されます。When a stored procedure executes, it uses the current compatibility level of the database in which it is defined. データベースの互換性設定が変更された場合、そのデータベースのすべてのストアド プロシージャは、設定に合わせて自動的に再コンパイルされます。When the compatibility setting of a database is changed, all of its stored procedures are automatically recompiled accordingly.

互換性レベル 140 と互換性レベル 150 との相違点Differences Between Compatibility Level 140 and Level 150

このセクションでは、互換性レベル 150 で導入された新しい動作について説明します。This section describes new behaviors introduced with compatibility level 150.

現在、データベース互換レベル 150 は Azure SQL データベースAzure SQL DatabaseSQL Server 2019 プレビューSQL Server 2019 preview でパブリック プレビューとして提供されています。Database compatibility level 150 is currently in Public Preview for Azure SQL データベースAzure SQL Database and SQL Server 2019 プレビューSQL Server 2019 preview. このデータベース互換レベルは、データベース互換レベル 140 で導入されたものを超える、新世代のクエリ処理と関連付けられます。This database compatibility level will be associated with the next generation of query processing improvements beyond what was introduced in database compatibility level 140.

互換性レベル設定 140 以下Compatibility-level setting of 140 or lower 互換性レベル設定 150Compatibility-level setting of 150
OLTP のオーバーヘッドやベンダー サポートの欠如などの制限のため、リレーショナル データ ウェアハウスと分析ワークロードで列ストア インデックスを活用できない場合があります。Relational data warehouse and analytic workloads may not be able to leverage columnstore indexes due to OLTP-overhead, lack of vendor support or other limitations. 列ストア インデックスがないと、これらのワークロードでバッチ実行モードの利点が得られません。Without columnstore indexes, these workloads cannot benefit from batch execution mode. 列ストア インデックスがなくても、分析ワークロードでバッチ実行モードが使用できるようになりました。Batch execution mode is now available for analytic workloads without requiring columnstore indexes. 詳細については、「batch mode on rowstore (行ストアでのバッチ モード)」を参照してください。For more information, see batch mode on rowstore.
ディスクへのスピルを引き起こす不十分なメモリ許可サイズを要求する行モード クエリでは、連続実行において引き続き問題が発生する可能性があります。Row-mode queries that request insufficient memory grant sizes that result in spills to disk may continue to have issues on consecutive executions. ディスクへのスピルを引き起こす不十分なメモリ許可サイズを要求する行モード クエリでは、連続実行でのパフォーマンスが改善されている可能性があります。Row-mode queries that request insufficient memory grant sizes that result in spills to disk may have improved performance on consecutive executions. 詳細については、「row mode memory grant feedback (行モード メモリ許可フィードバック)」を参照してください。For more information, see row mode memory grant feedback.
コンカレンシーの問題を引き起こす過度なメモリ許可サイズを要求する行モード クエリでは、連続実行において引き続き問題が発生する可能性があります。Row-mode queries that request an excessive memory grant size that results in concurrency issues may continue to have issues on consecutive executions. コンカレンシーの問題を引き起こす過度なメモリ許可サイズを要求する行モード クエリでは、連続実行でのコンカレンシーが改善されている可能性があります。Row-mode queries that request an excessive memory grant size that results in concurrency issues may have improved concurrency on consecutive executions. 詳細については、「row mode memory grant feedback (行モード メモリ許可フィードバック)」を参照してください。For more information, see row mode memory grant feedback.
T-SQL スカラー UDF を参照するクエリでは、反復呼び出しが使用され、コストが不足するため、シリアル実行が強制的に実施されます。Queries referencing T-SQL scalar UDFs will use iterative invocation, lack costing and force serial execution. T-SQL スカラー UDF は同等のリレーショナル式に変換され、この式は呼び出し側クエリに "インライン化" されます。これにより、多くの場合、パフォーマンスが大幅に向上します。T-SQL scalar UDFs are transformed into equivalent relational expressions that are “inlined” into the calling query, often resulting in significant performance gains. 詳細については、「T-SQL scalar UDF inlining (T-SQL スカラー UDF のインライン化)」を参照してください。For more information, see T-SQL scalar UDF inlining.
テーブル変数では、カーディナリティの推定で固定推定値が使用されます。Table variables use a fixed guess for the cardinality estimate. 実際の行数が推定値よりはるかに大きい場合は、ダウン ストリーム操作のパフォーマンスが低下する場合があります。If the actual number of rows is much higher than the guessed value, performance of downstream operations can suffer. 新しいプランでは、固定推定値ではなく、最初のコンパイルで発生したテーブル変数の実際のカーディナリティが使用されます。New plans will use the actual cardinality of the table variable encountered on first compilation instead of a fixed guess. 詳細については、「table variable deferred compilation (テーブル変数の遅延コンパイル)」を参照してください。For more information, see table variable deferred compilation.

データベース互換レベル 150 で使用できるクエリ処理機能の詳細については、「What's new in SQL Server 2019」 (SQL Server 2019 の新機能) と「SQL データベースでのインテリジェントなクエリ処理」を参照してください。For more information on query processing features enabled in database compatibility level 150, refer to What's new in SQL Server 2019 and Intelligent query processing in SQL databases.

互換性レベル 130 と互換性レベル 140 との相違点Differences Between Compatibility Level 130 and Level 140

このセクションでは、互換性レベル 140 で導入された新しい動作について説明します。This section describes new behaviors introduced with compatibility level 140.

130 以下の互換性レベルの設定Compatibility-level setting of 130 or lower 140 の互換性レベルの設定Compatibility-level setting of 140
複数ステートメントのテーブル値関数を参照するステートメントのカーディナリティの推定値は、固定された行推定値を使用します。Cardinality estimates for statements referencing multi-statement table valued functions use a fixed row guess. 複数ステートメントのテーブル値関数を参照する対象のステートメントのカーディナリティの推定値は、関数出力の実際のカーディナリティを使用します。Cardinality estimates for eligible statements referencing multi-statement table valued functions will use the actual cardinality of the function output. これは、複数ステートメントのテーブル値関数のインターリーブ実行によって有効にされます。This is enabled via interleaved execution for multi-statement table valued functions.
ディスクへのスピルを引き起こす不十分なメモリ許可サイズを要求するバッチモード クエリでは、連続実行において引き続き問題が発生する可能性があります。Batch-mode queries that request insufficient memory grant sizes that result in spills to disk may continue to have issues on consecutive executions. ディスクへのスピルを引き起こす不十分なメモリ許可サイズを要求するバッチモード クエリでは、連続実行でのパフォーマンスが改善されている可能性があります。Batch-mode queries that request insufficient memory grant sizes that result in spills to disk may have improved performance on consecutive executions. これはバッチ モード メモリ許可フィードバックを介して有効になります。バッチ モード演算子に対してスピルが発生した場合、このフィードバックによりキャッシュ プランのメモリ許可サイズが更新されます。This is enabled via batch mode memory grant feedback which will update the memory grant size of a cached plan if spills have occurred for batch mode operators.
コンカレンシーの問題を引き起こす過度なメモリ許可サイズを要求するバッチモード クエリでは、連続実行において引き続き問題が発生する可能性があります。Batch-mode queries that request an excessive memory grant size that results in concurrency issues may continue to have issues on consecutive executions. コンカレンシーの問題を引き起こす過度なメモリ許可サイズを要求するバッチモード クエリでは、連続実行でのコンカレンシーが改善されている可能性があります。Batch-mode queries that request an excessive memory grant size that results in concurrency issues may have improved concurrency on consecutive executions. これはバッチ モード メモリ許可フィードバックを介して有効になります。過度な容量が元々要求されている場合、このフィードバックによりキャッシュ プランのメモリ許可サイズが更新されます。This is enabled via batch mode memory grant feedback which will update the memory grant size of a cached plan if an excessive amount was originally requested.
結合演算子を含むバッチモード クエリは、3 つの物理結合アルゴリズム (入れ子になったループ、ハッシュ結合、マージ結合) の対象となります。Batch-mode queries that contain join operators are eligible for three physical join algorithms, including nested loop, hash join and merge join. カーディナリティの推定値が結合入力として適切でない場合は、不適切な結合アルゴリズムが選択される場合があります。If cardinality estimates are incorrect for join inputs, an inappropriate join algorithm may be selected. そのような事態になった場合は、パフォーマンスが低下し、キャッシュ プランが再コンパイルされるまで不適切な結合アルゴリズムが使用中のままとなります。If this occurs, performance will suffer and the inappropriate join algorithm will remain in-use until the cached plan is recompiled. その他に適応型結合と呼ばれる結合演算子もあります。There is an additional join operator called adaptive join. カーディナリティの推定値が外部ビルドの結合入力として適切でない場合は、不適切な結合アルゴリズムが選択されることがあります。If cardinality estimates are incorrect for the outer build join input, an inappropriate join algorithm may be selected. このような事態が発生し、ステートメントが適応型結合の対象である場合は、小さな結合入力には入れ子になったループが使用され、大きな結合入力にはハッシュ結合が使用されます。これらの使用は再コンパイルを要求することなく動的に行われます。If this occurs and the statement is eligible for an adaptive join, a nested loop will be used for smaller join inputs and a hash join will be used for larger join inputs dynamically without requiring recompilation.
列ストア インデックスを参照する単純なプランは、バッチ モード実行の対象ではありません。Trivial plans referencing Columnstore indexes are not eligible for batch mode execution. 列ストア インデックスを参照する単純なプランは、バッチ モード実行の対象であるプランを優先するために廃止されます。A trivial plan referencing Columnstore indexes will be discarded in favor of a plan that is eligible for batch mode execution.
sp_execute_external_script UDX 演算子は、行モードでのみ実行できます。The sp_execute_external_script UDX operator can only run in row mode. sp_execute_external_script UDX 演算子は、バッチ モードでの実行に適しています。The sp_execute_external_script UDX operator is eligible for batch mode execution.
複数ステートメントのテーブル値関数 (TVF) にはインターリーブ実行はありません。Multi-statement table-valued functions (TVF's) do not have interleaved execution 複数ステートメントの TVF のインターリーブ実行で、プランの品質を向上。Interleaved execution for multi-statement TVFs to improve plan quality.

SQL Server 2017 より前の SQL Server の初期のバージョンのトレース フラグ 4199 での修正プログラムは、既定で有効になりました。Fixes that were under trace flag 4199 in earlier versions of SQL Server prior to SQL Server 2017 are now enabled by default. 互換モード 140 の場合。With compatibility mode 140. トレース フラグ 4199 は、SQL Server 2017 の後にリリースされるクエリ オプティマイザーの新しい修正プログラムにも引き続き適用可能です。Trace flag 4199 will still be applicable for new query optimizer fixes that are released after SQL Server 2017. トレース フラグ 4199 については、「トレース フラグ 4199」を参照してください。For information about Trace Flag 4199, see Trace Flag 4199.

レベル 120 とレベル 130 の互換性の相違点Differences Between Compatibility Level 120 and Level 130

このセクションでは、互換性レベル 130 で導入された新しい動作について説明します。This section describes new behaviors introduced with compatibility level 130.

互換性レベル設定 120 以下Compatibility-level setting of 120 or lower 130 の互換性レベルの設定Compatibility-level setting of 130
INSERT-SELECT ステートメント内の INSERT はシングル スレッドです。The INSERT in an INSERT-SELECT statement is single-threaded. INSERT-SELECT ステートメントの INSERT はマルチ スレッドであるか、並列プランを与えることができます。The INSERT in an INSERT-SELECT statement is multi-threaded or can have a parallel plan.
メモリ最適化テーブルに対するクエリでは、シングル スレッドを実行します。Queries on a memory-optimized table execute single-threaded. メモリ最適化テーブルに対するクエリで、並列プランを利用できるようになりました。Queries on a memory-optimized table can now have parallel plans.
SQL 2014 のカーディナリティ推定機能 CardinalityEstimationModelVersion="120" が導入されました。Introduced the SQL 2014 Cardinality estimator CardinalityEstimationModelVersion="120" さらにカーディナリティの推定 (CE)、クエリから表示されるカーディナリティの推定モデルの 130 の改良点を計画します。Further cardinality estimation ( CE) Improvements with the Cardinality Estimation Model 130 which is visible from a Query plan. CardinalityEstimationModelVersion="130"CardinalityEstimationModelVersion="130"
列ストア インデックスで行モードがバッチ モードに変更:Batch mode versus Row Mode changes with Columnstore indexes:
  • 列ストア インデックスを持つテーブルでの並べ替えは行モードで行われますSorts on a table with Columnstore index are in Row mode
  • ウィンドウ関数の集計が LAGLEAD などの行のモードで動作します。Windowing function aggregates operate in row mode such as LAG or LEAD
  • 行モードで運用されている複数の個別の句を持つ列ストア テーブルに対するクエリQueries on Columnstore tables with Multiple distinct clauses operated in Row mode
  • MAXDOP 1 または行モードで実行される直列プランで実行されているクエリQueries running under MAXDOP 1 or with a serial plan executed in Row mode
列ストア インデックスで行モードがバッチ モードに変更:Batch mode versus Row Mode changes with Columnstore indexes:
  • 列ストア インデックスを持つテーブルでの並べ替えがバッチ モードになりました。Sorts on a table with a Columnstore index are now in batch mode
  • ウィンドウ集計が LAGLEAD などのバッチモードで動作します。Windowing aggregates now operate in batch mode such as LAG or LEAD
  • 複数の distinct 句で列ストア テーブルに対するクエリがバッチ モードで動作します。Queries on Columnstore tables with Multiple distinct clauses operate in Batch mode
  • MAXDOP 1 または直列プランで実行されているクエリをバッチ モードで実行します。Queries running under MAXDOP 1 or with a serial plan execute in Batch Mode
統計情報を自動的に更新できます。Statistics can be automatically updated. 統計情報を自動的に更新するロジックは、大規模なテーブルでより積極的に活用されます。The logic which automatically updates statistics is more aggressive on large tables. 実際には、これにより、クエリに関するパフォーマンス上の問題 (新たに挿入された行に対してクエリが頻繁に実行されるが、それらの値を取り込むための統計情報の更新が行われていない) に顧客が遭遇するケースが減少します。In practice, this should reduce cases where customers have seen performance issues on queries where newly inserted rows are queried frequently but where the statistics had not been updated to include those values.
SQL Server 2014 (12.x)SQL Server 2014 (12.x) では、トレース 2371 は既定ではオフになっています。Trace 2371 is OFF by default in SQL Server 2014 (12.x)SQL Server 2014 (12.x). SQL Server 2016 (13.x)SQL Server 2016 (13.x) では、トレース 2371 は既定では ON です。Trace 2371 is ON by default in SQL Server 2016 (13.x)SQL Server 2016 (13.x). トレース フラグ 2371 は、多くの行を含むテーブル内で、小さくても有用な行のサブセットをサンプリングするように自動統計更新ツールに指示します。Trace flag 2371 tells the auto statistics updater to sample a smaller yet wiser subset of rows, in a table that has a great many rows.

1 つの改良点は、最近挿入された行をより多くサンプルに含めるというものです。One improvement is to include in the sample more rows that were inserted recently.

もう 1 つの改良点は、統計の更新プロセスが実行されている間に、クエリをブロックするのでなく、クエリが実行されるようにするというものです。Another improvement is to let queries run while the update statistics process is running, rather than blocking the query.
レベル 120 の場合、統計情報はシングル スレッド プロセスによってサンプリングされます。For level 120, statistics are sampled by a single-threaded process. レベル 130 の場合、統計情報はマルチスレッド プロセスによってサンプリングされます。For level 130, statistics are sampled by a multi-threaded process.
253 の入力方向の外部キーは制限です。253 incoming foreign keys is the limit. 指定されたテーブルは、最大 10,000 個の入力方向の外部キーまたは類似の参照方法によって参照することができます。A given table can be referenced by up to 10,000 incoming foreign keys or similar references. 制限については、「 Create Foreign Key Relationships」を参照してください。For restrictions, see Create Foreign Key Relationships.
非推奨の MD2、MD4、MD5、SHA、SHA1 のハッシュ アルゴリズムは許可されます。The deprecated MD2, MD4, MD5, SHA, and SHA1 hash algorithms are permitted. SHA2_256 と SHA2_512 のハッシュ アルゴリズムのみが許可されます。Only SHA2_256 and SHA2_512 hash algorithms are permitted.
SQL Server 2016 (13.x)SQL Server 2016 (13.x) では、一部のデータ型変換と一部の (大抵は一般的ではない) 操作に改良が加えられました。includes improvements in some data types conversions and some (mostly uncommon) operations. 詳細については、「いくつかのデータ型と一般的でない操作を処理するときの SQL Server と Azure の SQL データベースの機能強化」をご覧ください。For details see SQL Server 2016 improvements in handling some data types and uncommon operations.
STRING_SPLIT 関数は使用できません。The STRING_SPLIT function is not available. STRING_SPLIT 関数は、互換性レベル 130 以上で利用できます。The STRING_SPLIT function is available under compatibility level 130 or above. データベースの互換性レベルが 130 よりも低い場合、SQL ServerSQL Server は STRING_SPLIT 関数を見つけて実行することができません。If your database compatibility level is lower than 130, SQL ServerSQL Server will not be able to find and execute STRING_SPLIT function.

SQL Server 2016 (13.x)SQL Server 2016 (13.x) より前の SQL ServerSQL Server の初期のバージョンのトレース フラグ 4199 での修正プログラムは、既定で有効になりました。Fixes that were under trace flag 4199 in earlier versions of SQL ServerSQL Server prior to SQL Server 2016 (13.x)SQL Server 2016 (13.x) are now enabled by default. 互換モードは 130 です。With compatibility mode 130. トレース フラグ 4199 は、SQL Server 2016 (13.x)SQL Server 2016 (13.x) の後にリリースされる、クエリ オプティマイザーの新しい修正プログラムに対しても引き続き適用することができます。Trace flag 4199 will still be applicable for new query optimizer fixes that are released after SQL Server 2016 (13.x)SQL Server 2016 (13.x). SQL DatabaseSQL Database で古いクエリ オプティマイザーを使用するには、互換性レベル 110 を選択する必要があります。To use the older query optimizer in SQL DatabaseSQL Database you must select compatibility level 110. トレース フラグ 4199 については、「トレース フラグ 4199」を参照してください。For information about Trace Flag 4199, see Trace Flag 4199.

レベル 120 とより低い互換性レベルとの相違点Differences Between Lower Compatibility Levels and Level 120

ここでは、互換性レベル 120 に導入された新しい動作について説明します。This section describes new behaviors introduced with compatibility level 120.

互換性レベル設定 110 以下Compatibility-level setting of 110 or lower 互換性レベル設定 120Compatibility-level setting of 120
以前のクエリ オプティマイザーが使用されます。The older query optimizer is used. SQL Server 2014 (12.x)SQL Server 2014 (12.x) では、クエリ プランを作成し最適化するコンポーネントに大幅な改良が加えられました。includes substantial improvements to the component that creates and optimizes query plans. この新しいクエリ オプティマイザー機能は、データベース互換性レベル 120 を使用している場合にのみ利用できます。This new query optimizer feature is dependent upon use of the database compatibility level 120. これらの改良点を利用するには、データベースの互換性レベル 120 を使用して新しいデータベース アプリケーションを開発する必要があります。New database applications should be developed using database compatibility level 120 to take advantage of these improvements. 以前のバージョンの SQL ServerSQL Server から移行されたアプリケーションについては、良好なパフォーマンスが維持されているか、またはパフォーマンスが向上していることを確認するために慎重にテストを実行する必要があります。Applications that are migrated from earlier versions of SQL ServerSQL Server should be carefully tested to confirm that good performance is maintained or improved. パフォーマンスが低下する場合は、データベースの互換性レベルを 110 以前に設定して、古いクエリ オプティマイザーの方法を使用することができます。If performance degrades, you can set the database compatibility level to 110 or earlier to use the older query optimizer methodology.

データベースの互換性レベル 120 に設定した場合は、最新のデータ ウェアハウスと OLTP ワークロード向けにチューニングされた新しいカーディナリティ推定機能が使用されます。Database compatibility level 120 uses a new cardinality estimator that is tuned for modern data warehousing and OLTP workloads. パフォーマンスの問題に関連してデータベースの互換性レベルを 110 に設定する前に、SQL Server 2014 (12.x)SQL Server 2014 (12.x) に関するトピック「データベース エンジンの新機能」のクエリ プラン セクションに掲載されている推奨事項を参照してください。Before setting database compatibility level to 110 because of performance issues, see the recommendations in the Query Plans section of the SQL Server 2014 (12.x)SQL Server 2014 (12.x) What's New in Database Engine topic.
互換性レベルが 120 未満の場合、日付値を文字列値に変換すると、言語設定は無視されます。In compatibility levels lower than 120, the language setting is ignored when converting a date value to a string value. この動作は date 型に固有の動作であることに注意してください。Note that this behavior is specific only to the date type. 以下の「例」の B を参照してください。See example B in the Examples section below. 日付値を文字列値に変換するときに、言語設定は無視されません。The language setting is not ignored when converting a date value to a string value.
EXCEPT 句の右側にある再帰参照によって、無限ループが作成されます。Recursive references on the right-hand side of an EXCEPT clause create an infinite loop. この動作については、以下の「例」の C を参照してください。Example C in the Examples section below demonstrates this behavior. EXCEPT 句の再帰参照によって、ANSI SQL 標準に準拠したエラーが生成されます。Recursive references in an EXCEPT clause generates an error in compliance with the ANSI SQL standard.
再帰共通テーブル式 (CTE) では重複する列名を使用できます。Recursive common table expression (CTE) allows duplicate column names. 再帰 CTE では、重複する列名を使用できません。Recursive CTE do not allow duplicate column names.
無効化されたトリガーは、トリガーが変更されると有効になります。Disabled triggers are enabled if the triggers are altered. トリガーを変更しても、トリガーの状態 (有効または無効) は変更されません。Altering a trigger does not change the state (enabled or disabled) of the trigger.
OUTPUT INTO テーブル句では、IDENTITY_INSERT SETTING = OFF が無視され、明示的な値を挿入できます。The OUTPUT INTO table clause ignores the IDENTITY_INSERT SETTING = OFF and allows explicit values to be inserted. IDENTITY_INSERT が OFF に設定されているときは、テーブルの ID 列に明示的な値を挿入できません。You cannot insert explicit values for an identity column in a table when IDENTITY_INSERT is set to OFF.
データベースの包含状態が PARTIAL に設定されている場合、MERGE ステートメントの OUTPUT 句にある $action フィールドを検証すると、照合順序のエラーが確認されることがあります。When the database containment is set to partial, validating the $action field in the OUTPUT clause of a MERGE statement can return a collation error. MERGE ステートメントの $action 句によって返される値の照合順序は、サーバー照合順序ではなく、データベース照合順序です。また、照合順序の競合エラーは返されません。The collation of the values returned by the $action clause of a MERGE statement is the database collation instead of the server collation and a collation conflict error is not returned.
SELECT INTO ステートメントでは、常にシングル スレッドの挿入操作が作成されます。A SELECT INTO statement always creates a single-threaded insert operation. SELECT INTO ステートメントでは、並列挿入操作を作成できます。A SELECT INTO statement can create a parallel insert operation. 多数の行を挿入するときは、並列操作によってパフォーマンスを向上させることができます。When inserting a large numbers of rows, the parallel operation can improve performance.

より低い互換性レベルとレベル 100 および 110 の相違点Differences Between Lower Compatibility Levels and Levels 100 and 110

このセクションでは、互換性レベル 110 で導入された新しい動作について説明します。This section describes new behaviors introduced with compatibility level 110. このセクションは、110 より大きい互換性レベルにも適用されます。This section also applies to compatibility levels above 110.

100 以下に、互換性レベル設定Compatibility-level setting of 100 or lower 互換性レベル設定 110 以上Compatibility-level setting of at least 110
共通言語ランタイム (CLR) のデータベース オブジェクトは、CLR の Version 4 で実行されます。Common language runtime (CLR) database objects are executed with version 4 of the CLR. ただし、CLR の Version 4 で導入されたいくつかの動作の変更が回避されます。However, some behavior changes introduced in version 4 of the CLR are avoided. 詳細については、CLR 統合の新機能に関するページを参照してください。For more information, see What's New in CLR Integration. CLR のデータベース オブジェクトは、CLR の Version 4 で実行されます。CLR database objects are executed with version 4 of the CLR.
XQuery 関数の string-lengthsubstring は、各サロゲートを 2 つの文字としてカウントします。The XQuery functions string-length and substring count each surrogate as two characters. XQuery 関数の string-length および substring は、各サロゲートを 1 つの文字としてカウントします。The XQuery functions string-length and substring count each surrogate as one character.
PIVOT は再帰共通テーブル式 (CTE) のクエリで許可されます。PIVOT is allowed in a recursive common table expression (CTE) query. ただし、グループごとに複数の行がある場合、クエリからは誤った結果が返されます。However, the query returns incorrect results when there are multiple rows per grouping. PIVOT は再帰共通テーブル式 (CTE) のクエリで許可されません。PIVOT is not allowed in a recursive common table expression (CTE) query. エラーが返されます。An error is returned.
RC4 アルゴリズムは、旧バージョンとの互換性のためにのみサポートされています。The RC4 algorithm is only supported for backward compatibility. データベース互換性レベルが 90 または 100 の場合、新しい素材は RC4 または RC4_128 を使用してのみ暗号化できます New material can only be encrypted using RC4 or RC4_128 when the database is in compatibility level 90 or 100. (非推奨)。SQL Server 2012 (11.x)SQL Server 2012 (11.x) では、どの互換性レベルでも、RC4 または RC4_128 を使用して暗号化された素材を暗号化解除できます。(Not recommended.) In SQL Server 2012 (11.x)SQL Server 2012 (11.x), material encrypted using RC4 or RC4_128 can be decrypted in any compatibility level. RC4 または RC4_128 を使用して新素材を暗号化することはできません。New material cannot be encrypted using RC4 or RC4_128. AES アルゴリズムのいずれかなど、新しいアルゴリズムを使用してください。Use a newer algorithm such as one of the AES algorithms instead. SQL Server 2012 (11.x)SQL Server 2012 (11.x) では、どの互換性レベルでも、RC4 または RC4_128 を使用して暗号化された素材を暗号化解除できます。In SQL Server 2012 (11.x)SQL Server 2012 (11.x), material encrypted using RC4 or RC4_128 can be decrypted in any compatibility level.
time および datetime2 データ型に対する CAST および CONVERT 操作の既定のスタイルは、いずれかの型が計算列の式で使用されている場合を除き、121 です。The default style for CAST and CONVERT operations on time and datetime2 data types is 121 except when either type is used in a computed column expression. 計算列の場合、既定のスタイルは 0 です。For computed columns, the default style is 0. この動作は、計算列が作成されるとき、自動パラメーター化を含むクエリで使用されるとき、または制約の定義で使用されるときに、計算列に影響を与えます。This behavior impacts computed columns when they are created, used in queries involving auto-parameterization, or used in constraint definitions.

以下の「例」の D では、スタイル 0 とスタイル 121 の違いを示します。Example D in the Examples section below shows the difference between styles 0 and 121. 上記の動作については示しません。It does not demonstrate the behavior described above. 日付および時刻のスタイルの詳細については、CAST および CONVERT に関するページを参照してください。For more information about date and time styles, see CAST and CONVERT.
互換性レベル 110 では、time および datetime2 データ型に対する CAST および CONVERT 操作の既定のスタイルは常に 121 です。Under compatibility level 110, the default style for CAST and CONVERT operations on time and datetime2 data types is always 121. クエリが古い動作に依存する場合は、110 より小さい互換性レベルを使用するか、または影響を受けるクエリで 0 スタイルを明示的に指定してください。If your query relies on the old behavior, use a compatibility level less than 110, or explicitly specify the 0 style in the affected query.

データベースを互換性レベル 110 にアップグレードしても、ディスクに格納されているユーザー データは変更されません。Upgrading the database to compatibility level 110 will not change user data that has been stored to disk. このようなデータは手動で適切に修正する必要があります。You must manually correct this data as appropriate. たとえば、SELECT INTO を使用して、前に説明した計算列の式を含むソースからテーブルを作成した場合は、計算列の定義自体ではなく、(スタイル 0 を使用する) データが格納されます。For example, if you used SELECT INTO to create a table from a source that contained a computed column expression described above, the data (using style 0) would be stored rather than the computed column definition itself. このようなデータは、手動で更新してスタイル 121 に一致させる必要があります。You would need to manually update this data to match style 121.
パーティション ビューで参照されるリモート テーブルの smalldatetime 型の列は、datetime としてマップされます。Any columns in remote tables of type smalldatetime that are referenced in a partitioned view are mapped as datetime. ローカル テーブルの対応する列 (選択リストの同じ順番にある列) は、datetime 型であることが必要です。Corresponding columns in local tables (in the same ordinal position in the select list) must be of type datetime. パーティション ビューで参照されるリモート テーブルの smalldatetime 型の列は、smalldatetime としてマップされます。Any columns in remote tables of type smalldatetime that are referenced in a partitioned view are mapped as smalldatetime. ローカル テーブルの対応する列 (選択リストの同じ順番にある列) は、smalldatetime 型であることが必要です。Corresponding columns in local tables (in the same ordinal position in the select list) must be of type smalldatetime.

110 にアップグレードした後は、データ型の不一致により、分散パーティション ビューは失敗します。After upgrading to 110, the distributed partitioned view will fail because of the data type mismatch. この問題を解決するには、リモート テーブルでのデータ型を datetime に変更するか、またはローカル データベースの互換性レベルを 100 以下に設定します。You can resolve this by changing the data type on the remote table to datetime or setting the compatibility level of the local database to 100 or lower.
SOUNDEX 関数では次のルールが実装されます。SOUNDEX function implements the following rules:

1) SOUNDEX コードの同じ数値が割り当てられている 2 つの子音の間に大文字の H または大文字の W がある場合、この H または W は無視されます。1) Upper-case H or upper-case W are ignored when separating two consonants that have the same number in the SOUNDEX code.

2) character_expression の最初の 2 文字に SOUNDEX コードの同じ数値が割り当てられている場合は、両方の文字が含まれます。2) If the first 2 characters of character_expression have the same number in the SOUNDEX code, both characters are included. 最初の 2 文字の場合を除き、並んでいる一連の子音に SOUNDEX コードの同じ数値が割り当てられている場合、最初の文字以外はすべて除外されます。Else, if a set of side-by-side consonants have same number in the SOUNDEX code, all of them are excluded except the first.
SOUNDEX 関数では次のルールが実装されます。SOUNDEX function implements the following rules:

1) SOUNDEX コードの同じ数値が割り当てられている 2 つの子音の間に大文字の H または大文字の W がある場合、右側の子音は無視されます。1) If upper-case H or upper-case W separate two consonants that have the same number in the SOUNDEX code, the consonant to the right is ignored

2) 並んでいる一連の子音に SOUNDEX コードの同じ数値が割り当てられている場合、最初の文字以外はすべて除外されます。2) If a set of side-by-side consonants have same number in the SOUNDEX code, all of them are excluded except the first.



その他のルールにより、SOUNDEX 関数で計算された値が、110 未満の互換性レベルで計算された値と異なる結果になる場合があります。The additional rules may cause the values computed by the SOUNDEX function to be different than the values computed under earlier compatibility levels. 互換性レベル 110 へのアップグレード後に、SOUNDEX 関数を使用するインデックス、ヒープ、または CHECK 制約の再構築が必要になる場合があります。After upgrading to compatibility level 110, you may need to rebuild the indexes, heaps, or CHECK constraints that use the SOUNDEX function. 詳細については、SOUNDEX に関するページを参照してください。For more information, see SOUNDEX.

互換性レベル 90 とレベル 100 の相違点Differences Between Compatibility Level 90 and Level 100

このセクションでは、互換性レベル 100 で導入された新しい動作について説明します。This section describes new behaviors introduced with compatibility level 100.

90 の互換性レベルの設定Compatibility-level setting of 90 互換性レベルの設定は 100Compatibility-level setting of 100 影響度Possibility of impact
複数ステートメントのテーブル値関数が作成されるとき、QUOTED_IDENTIFER 設定はセッション レベルの設定に関係なく常に ON に設定されます。The QUOTED_IDENTIFER setting is always set to ON for multistatement table-valued functions when they are created regardless of the session level setting. 複数ステートメントのテーブル値関数が作成されるとき、QUOTED IDENTIFIER のセッション設定が受け入れられます。The QUOTED IDENTIFIER session setting is honored when multistatement table-valued functions are created. MediumMedium
パーティション関数を作成または変更するとき、関数の datetime リテラルおよび smalldatetime リテラルは、言語設定が US_English であることを前提に評価されます。When you create or alter a partition function, datetime and smalldatetime literals in the function are evaluated assuming US_English as the language setting. パーティション関数の datetime リテラルおよび smalldatetime リテラルを評価する際、現在の言語設定が使用されます。The current language setting is used to evaluate datetime and smalldatetime literals in the partition function. MediumMedium
INSERT および SELECT INTO ステートメントで FOR BROWSE 句は許可されます (ただし無視されます)。The FOR BROWSE clause is allowed (and ignored) in INSERT and SELECT INTO statements. INSERT および SELECT INTO ステートメントで FOR BROWSE 句は許可されません。The FOR BROWSE clause is not allowed in INSERT and SELECT INTO statements. MediumMedium
OUTPUT 句でフルテキスト述語を使用できます。Full-text predicates are allowed in the OUTPUT clause. OUTPUT 句でフルテキスト述語を使用できません。Full-text predicates are not allowed in the OUTPUT clause. LowLow
CREATE FULLTEXT STOPLISTALTER FULLTEXT STOPLIST、およびDROP FULLTEXT STOPLIST はサポートされていません。CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST, and DROP FULLTEXT STOPLIST are not supported. システム ストップリストは、自動的に新しいフルテキスト インデックスに関連付けられます。The system stoplist is automatically associated with new full-text indexes. CREATE FULLTEXT STOPLISTALTER FULLTEXT STOPLIST、およびDROP FULLTEXT STOPLIST はサポートされています。CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST, and DROP FULLTEXT STOPLIST are supported. LowLow
MERGE は予約されたキーワードとして適用されません。MERGE is not enforced as a reserved keyword. MERGE は完全に予約されたキーワードです。MERGE is a fully reserved keyword. MERGE ステートメントは、100 と 90 の両方の互換性レベルでサポートされます。The MERGE statement is supported under both 100 and 90 compatibility levels. LowLow
INSERT ステートメントの <dml_table_source> 引数を使用すると、構文エラーが発生します。Using the <dml_table_source> argument of the INSERT statement raises a syntax error. 入れ子になった INSERT、UPDATE、DELETE、または MERGE ステートメント内の OUTPUT 句の結果をキャプチャして、対象のテーブルまたはビューに挿入することができます。You can capture the results of an OUTPUT clause in a nested INSERT, UPDATE, DELETE, or MERGE statement, and insert those results into a target table or view. そのためには、INSERT ステートメントの <dml_table_source> 引数を使用します。This is done using the <dml_table_source> argument of the INSERT statement. LowLow
NOINDEX が指定されていない場合、DBCC CHECKDB または DBCC CHECKTABLE は、1 つのテーブルまたはインデックス付きビューとそのすべての非クラスター化インデックスおよび XML インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。Unless NOINDEX is specified, DBCC CHECKDB or DBCC CHECKTABLE performs both physical and logical consistency checks on a single table or indexed view and on all its nonclustered and XML indexes. 空間インデックスはサポートされません。Spatial indexes are not supported. NOINDEX が指定されていない場合、DBCC CHECKDB または DBCC CHECKTABLE は、1 つのテーブルとそのすべての非クラスター化インデックスについて、物理的な一貫性と論理的な一貫性の両方をチェックします。Unless NOINDEX is specified, DBCC CHECKDB or DBCC CHECKTABLE performs both physical and logical consistency checks on a single table and on all its nonclustered indexes. ただし、XML インデックス、空間インデックス、およびインデックス付きビューでは、既定で物理的な一貫性のみがチェックされます。However, on XML indexes, spatial indexes, and indexed views, only physical consistency checks are performed by default.

WITH EXTENDED_LOGICAL_CHECKS が指定されている場合、インデックス付きビュー、XML インデックス、および空間インデックス (存在する場合) に対して論理チェックが実行されます。If WITH EXTENDED_LOGICAL_CHECKS is specified, logical checks are performed on indexed views, XML indexes, and spatial indexes, where present. 既定では、論理的な一貫性のチェック前に物理的な一貫性がチェックされます。By default, physical consistency checks are performed before the logical consistency checks. NOINDEX も指定されている場合は、論理チェックのみが実行されます。If NOINDEX is also specified, only the logical checks are performed.
LowLow
データ操作言語 (DML) ステートメントで OUTPUT 句を使用した場合、ステートメントの実行時に実行時エラーが発生すると、トランザクション全体が終了し、ロールバックされます。When an OUTPUT clause is used with a data manipulation language (DML) statement and a run-time error occurs during statement execution, the entire transaction is terminated and rolled back. データ操作言語 (DML) ステートメントで OUTPUT 句を使用した場合、ステートメントの実行時に実行時エラーが発生したときの動作は、SET XACT_ABORT 設定によって異なります。When an OUTPUT clause is used with a data manipulation language (DML) statement and a run-time error occurs during statement execution, the behavior depends on the SET XACT_ABORT setting. SET XACT_ABORT が OFF の場合は、OUTPUT 句を使用している DML ステートメントでステートメント中断エラーが発生すると、ステートメントは終了しますが、バッチの実行は続行され、トランザクションはロールバックされません。If SET XACT_ABORT is OFF, a statement abort error generated by the DML statement using the OUTPUT clause will terminate the statement, but the execution of the batch continues and the transaction is not rolled back. SET XACT_ABORT が ON の場合は、OUTPUT 句を使用している DML ステートメントで実行時エラーが発生すると、バッチが終了し、トランザクションはロールバックされます。If SET XACT_ABORT is ON, all run-time errors generated by the DML statement using the OUTPUT clause will terminate the batch, and the transaction is rolled back. LowLow
CUBE および ROLLUP は予約されたキーワードとして適用されません。CUBE and ROLLUP are not enforced as reserved keywords. CUBE および ROLLUP は、GROUP BY 句内では予約されたキーワードです。CUBE and ROLLUP are reserved keywords within the GROUP BY clause. LowLow
XML の anyType 型の要素には厳密な検証が適用されます。Strict validation is applied to elements of the XML anyType type. anyType 型の要素には緩やかな検証が適用されます。Lax validation is applied to elements of the anyType type. 詳細については、「ワイルドカード コンポーネントと内容検証」を参照してください。For more information, see Wildcard Components and Content Validation. LowLow
特殊な属性 xsi:nil および xsi:type は、データ操作言語ステートメントでクエリまたは変更できません。The special attributes xsi:nil and xsi:type cannot be queried or modified by data manipulation language statements.

つまり、/e/@xsi:nil は失敗し、/e/@* では xsi:nil 属性と xsi:type 属性が無視されます。This means that /e/@xsi:nil fails while /e/@* ignores the xsi:nil and xsi:type attributes. ただし、/e の場合でも、SELECT xmlCol では xsi:nil = "false" との一貫性のために xsi:nil 属性と xsi:type 属性が返されます。However, /e returns the xsi:nil and xsi:type attributes for consistency with SELECT xmlCol, even if xsi:nil = "false".
特殊な属性 xsi:nil および xsi:type は、標準属性として格納されるので、クエリも変更も可能です。The special attributes xsi:nil and xsi:type are stored as regular attributes and can be queried and modified.

たとえば、クエリ SELECT x.query('a/b/@*') を実行すると、xsi:nil および xsi:type を含むすべての属性が返されます。For example, executing the query SELECT x.query('a/b/@*') returns all attributes including xsi:nil and xsi:type. クエリでこれらの型を除外するには、@*@*[namespace-uri(.) != "insert xsi namespace uri" に置き換え、(local-name(.) = "type"local-name(.) ="nil". を避けてください。To exclude these types in the query, replace @* with @*[namespace-uri(.) != "insert xsi namespace uri" and not (local-name(.) = "type" or local-name(.) ="nil".
LowLow
XML 定数文字列値を SQL ServerSQL Server datetime 型に変換するユーザー定義関数は、"決定的" とマークされます。A user-defined function that converts an XML constant string value to a SQL ServerSQL Server datetime type is marked as deterministic. XML 定数文字列値を SQL ServerSQL Server datetime 型に変換するユーザー定義関数は、"非決定的" とマークされます。A user-defined function that converts an XML constant string value to a SQL ServerSQL Server datetime type is marked as non-deterministic. LowLow
XML の union 型と list 型は、完全にはサポートされていません。The XML union and list types are not fully supported. union 型と list 型は、完全にサポートされています (次の機能を含む)。The union and list types are fully supported including the following functionality:

リストの和集合Union of list

和集合の和集合Union of union

アトミック型のリストList of atomic types

和集合のリストList of union
LowLow
xQuery メソッドに必要な SET オプションは、メソッドがビューまたはインライン テーブル値関数に含まれる場合に検証されません。The SET options required for an xQuery method are not validated when the method is contained in a view or inline table-valued function. xQuery メソッドに必要な SET オプションは、メソッドがビューまたはインライン テーブル値関数に含まれる場合に検証されます。The SET options required for an xQuery method are validated when the method is contained in a view or inline table-valued function. メソッドの SET オプションが正しく設定されていない場合は、エラーが発生します。An error is raised if the SET options of the method are set incorrectly. LowLow
行末文字 (復帰と改行) を含む XML 属性値は、XML 標準に従って正規化されません。XML attribute values that contain end-of-line characters (carriage return and line feed) are not normalized according to the XML standard. つまり、1 つの改行文字ではなく両方の文字が返されます。That is, both characters are returned instead of a single line-feed character. 行末文字 (復帰と改行) を含む XML 属性値は、XML 標準に従って正規化されます。XML attribute values that contain end-of-line characters (carriage return and line feed) are normalized according to the XML standard. つまり、外部解析エンティティ (ドキュメント エンティティを含む) のすべての改行が、入力時に正規化されます。このとき、2 文字のシーケンス #xD #xA と、後ろに #xA がない #xD の両方について、1 つの #xA 文字に変換されます。That is, all line breaks in external parsed entities (including the document entity) are normalized on input by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character.

行末文字を含む文字列値を転送するための属性を使用しているアプリケーションは、このような文字が送信されても受け取りません。Applications that use attributes to transport string values that contain end-of-line characters will not receive these characters back as they are submitted. 正規化処理を回避するには、XML 数字エンティティを使用してすべての行末文字をエンコードしてください。To avoid the normalization process, use the XML numeric character entities to encode all end-of-line characters.
LowLow
列プロパティ ROWGUIDCOL および IDENTITY は、制約として不適切に指定される可能性があります。The column properties ROWGUIDCOL and IDENTITY can be incorrectly named as a constraint. たとえば、ステートメント CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) は実行されますが、制約名は保持されず、ユーザーはその制約にアクセスできません。For example the statement CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) executes, but the constraint name is not preserved and is not accessible to the user. 列プロパティ ROWGUIDCOL および IDENTITY は、制約として指定できません。The column properties ROWGUIDCOL and IDENTITY cannot be named as a constraint. エラー 156 が返されます。Error 156 is returned. LowLow
UPDATE T1 SET @v = column_name = <expression> などの双方向の代入を使用して列を更新すると、予期しない結果が生じる可能性があります。これは、ステートメントの実行時に、WHERE 句や ON 句などの他の句でステートメントの開始値ではなく変数の有効期限の値を使用できるためです。Updating columns by using a two-way assignment such as UPDATE T1 SET @v = column_name = <expression> can produce unexpected results because the live value of the variable can be used in other clauses such as the WHERE and ON clause during statement execution instead of the statement starting value. これにより、述語の意味が行ごとに予期せず変化することがあります。This can cause the meanings of the predicates to change unpredictably on a per-row basis.

この動作は、互換性レベルが 90 に設定されている場合にのみ適用されます。This behavior is applicable only when the compatibility level is set to 90.
双方向の代入を使用して列を更新すると、予想どおりの結果が生じます。これは、ステートメントの実行時に、列のステートメントの開始値のみが利用されるためです。Updating columns by using a two-way assignment produces expected results because only the statement starting value of the column is accessed during statement execution. LowLow
以下の「例」の E を参照してください。See example E in the Examples section below. 以下の「例」の F を参照してください。See example F in the Examples section below. LowLow
ODBC 関数 {fn CONVERT()} では、言語の既定の日付形式が使用されます。The ODBC function {fn CONVERT()} uses the default date format of the language. 言語によっては、既定の形式が YDM の場合があります。この場合、CONVERT() を {fn CURDATE()} などの YMD 形式が想定されている他の関数と組み合わせて使用すると、変換エラーが発生する可能性があります。For some languages, the default format is YDM, which can result in conversion errors when CONVERT() is combined with other functions, such as {fn CURDATE()}, that expect a YMD format. ODBC 関数 {fn CONVERT()} では、ODBC データ型 SQL_TIMESTAMP、SQL_DATE、SQL_TIME、SQLDATE、SQL_TYPE_TIME、および SQL_TYPE_TIMESTAMP への変換時にスタイル 121 (言語に依存しない YMD 形式) が使用されます。The ODBC function {fn CONVERT()} uses style 121 (a language-independent YMD format) when converting to the ODBC data types SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME, and SQL_TYPE_TIMESTAMP. LowLow
DATEPART などの datetime 組み込み関数では、文字列入力値が有効な datetime リテラルである必要はありません。Datetime intrinsics such as DATEPART do not require string input values to be valid datetime literals. たとえば、SELECT DATEPART (year, '2007/05-30') は正常にコンパイルされます。For example, SELECT DATEPART (year, '2007/05-30') compiles successfully. DATEPART などの datetime 組み込み関数では、文字列入力値が有効な datetime リテラルである必要があります。Datetime intrinsics such as DATEPART require string input values to be valid datetime literals. 無効な datetime リテラルを使用すると、エラー 241 が返されます。Error 241 is returned when an invalid datetime literal is used. LowLow

予約済みキーワードReserved Keywords

互換性設定では、データベース エンジンDatabase Engineで予約されているキーワードも判別されます。The compatibility setting also determines the keywords that are reserved by the データベース エンジンDatabase Engine. 次の表に、各互換性レベルで使用される予約済みキーワードを示します。The following table shows the reserved keywords that are introduced by each of the compatibility levels.

互換性レベル設定Compatibility-level setting 予約済みキーワードReserved keywords
130130 未定。To be determined.
120120 [なし] :None.
110110 WITHIN GROUP、TRY_CONVERT、SEMANTICKEYPHRASETABLE、SEMANTICSIMILARITYDETAILSTABLE、SEMANTICSIMILARITYTABLEWITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE
100100 CUBE、MERGE、ROLLUPCUBE, MERGE, ROLLUP
9090 EXTERNAL、PIVOT、UNPIVOT、REVERT、TABLESAMPLEEXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

各互換性レベルの予約済みキーワードには、そのレベル以下で導入されるキーワードもすべて含まれています。At a given compatibility level, the reserved keywords include all of the keywords introduced at or below that level. したがって、たとえばレベル 110 のアプリケーションの場合、上の表に一覧表示されているすべてのキーワードが予約されています。Thus, for instance, for applications at level 110, all of the keywords listed in the preceding table are reserved. それより下位の互換性レベルでは、レベル 100 のキーワードは有効なオブジェクト名ですが、そのキーワードに対応するレベル 110 の言語機能は使用できません。At the lower compatibility levels, level-100 keywords remain valid object names, but the level-110 language features corresponding to those keywords are unavailable.

キーワードはいったん導入されると、キーワードの予約が維持されます。Once introduced, a keyword remains reserved. たとえば、互換性レベル 90 で導入された予約済みキーワード PIVOT は、レベル 100、110、および 120 でも予約済みとして扱われます。For example, the reserved keyword PIVOT, which was introduced in compatibility level 90, is also reserved in levels 100, 110, and 120.

互換性レベル設定でキーワードとして予約した識別子をアプリケーションで使用しようとすると、アプリケーションは失敗します。If an application uses an identifier that is reserved as a keyword for its compatibility level, the application will fail. この問題を回避するには、識別子をかっこ ( [] ) または引用符 ( "" ) で囲みます。たとえば、識別子 EXTERNAL を使用しているアプリケーションを互換性レベル 90 にアップグレードするには、識別子を [EXTERNAL] または "EXTERNAL" のように変更します。To work around this, enclose the identifier between either brackets ([]) or quotation marks (""); for example, to upgrade an application that uses the identifier EXTERNAL to compatibility level 90, you could change the identifier to either [EXTERNAL] or "EXTERNAL".

詳細については、「予約済みキーワード」を参照してください。For more information, see Reserved Keywords.

アクセス許可Permissions

データベースに対する ALTER 権限が必要です。Requires ALTER permission on the database.

使用例Examples

A.A. 互換性レベルを変更するChanging the compatibility level

次の例では、AdventureWorks2012AdventureWorks2012 データベースの互換性レベルを 110,SQL Server 2012 (11.x)SQL Server 2012 (11.x) に変更します。The following example changes the compatibility level of the AdventureWorks2012AdventureWorks2012 database to 110,SQL Server 2012 (11.x)SQL Server 2012 (11.x).

ALTER DATABASE AdventureWorks2012
SET COMPATIBILITY_LEVEL = 110;
GO

次の例では、現在のデータベースの互換性レベルを返します。The following example returns the compatibility level of the current database.

SELECT name, compatibility_level
FROM sys.databases
WHERE name = db_name();

B.B. 互換性レベルが 120 の場合を除き、SET LANGUAGE ステートメントを無視するIgnoring the SET LANGUAGE statement except under compatibility level 120

次のクエリでは、互換性レベルが 120 の場合を除き、SET LANGUAGE ステートメントは無視されます。The following query ignores the SET LANGUAGE statement except under compatibility level 120.

SET DATEFORMAT dmy;
DECLARE @t2 date = '12/5/2011' ;
SET LANGUAGE dutch;
SELECT CONVERT(varchar(11), @t2, 106);

-- Results when the compatibility level is less than 120.
12 May 2011

-- Results when the compatibility level is set to 120).
12 mei 2011

C.C. 互換性レベルが 110 以下に設定されている場合、EXCEPT 句の右側にある再帰参照によって、無限ループが作成されます。For compatibility-level setting of 110 or lower, recursive references on the right-hand side of an EXCEPT clause create an infinite loop

WITH
cte AS (SELECT * FROM (VALUES (1),(2),(3)) v (a)),
r
AS (SELECT a FROM Table1
UNION ALL
(SELECT a FROM Table1 EXCEPT SELECT a FROM r) )
SELECT a
FROM r;

D.D. スタイル 0 とスタイル 121 の相違点The difference between styles 0 and 121

日付および時刻のスタイルの詳細については、CAST および CONVERT に関するページを参照してください。For more information about date and time styles, see CAST and CONVERT.

CREATE TABLE t1 (c1 time(7), c2 datetime2);

INSERT t1 (c1,c2) VALUES (GETDATE(), GETDATE());

SELECT CONVERT(nvarchar(16),c1,0) AS TimeStyle0
       ,CONVERT(nvarchar(16),c1,121)AS TimeStyle121
       ,CONVERT(nvarchar(32),c2,0) AS Datetime2Style0
       ,CONVERT(nvarchar(32),c2,121)AS Datetime2Style121
FROM t1;

-- Returns values such as the following.
TimeStyle0       TimeStyle121
Datetime2Style0      Datetime2Style121
---------------- ----------------
-------------------- --------------------------
3:15PM           15:15:35.8100000
Jun  7 2011  3:15PM  2011-06-07 15:15:35.8130000

E.E. 変数代入 - 最上位レベルの UNION 演算子Variable assignment - top-level UNION operator

変数代入は、最上位レベルの UNION 演算子を含むステートメントで許可されていますが、予期しない結果が返されます。Variable assignment is allowed in a statement containing a top-level UNION operator, but returns unexpected results. たとえば、次のステートメントでは、2 つのテーブルの和集合からの列 BusinessEntityID の値がローカル変数 @v に割り当てられます。For example, in the following statements, local variable @v is assigned the value of the column BusinessEntityID from the union of two tables. 定義上、SELECT ステートメントが複数の値を返した場合は、最後に返された値が変数に割り当てられます。By definition, when the SELECT statement returns more than one value, the variable is assigned the last value that is returned. この場合は、最後の値が変数に正しく割り当てられますが、SELECT UNION ステートメントの結果セットも返されます。In this case, the variable is correctly assigned the last value, however, the result set of the SELECT UNION statement is also returned.

ALTER DATABASE AdventureWorks2012
SET compatibility_level = 110;
GO
USE AdventureWorks2012;
GO
DECLARE @v int;
SELECT @v = BusinessEntityID FROM HumanResources.Employee
UNION ALL
SELECT @v = BusinessEntityID FROM HumanResources.EmployeeAddress;
SELECT @v;

変数代入は、最上位レベルの UNION 演算子を含むステートメントでは許可されていません。Variable assignment is not allowed in a statement containing a top-level UNION operator. エラー 10734 が返されます。Error 10734 is returned. エラーを解決するには、次の例で示すようにクエリを書き直してください。To resolve the error, rewrite the query as shown in the following example.

DECLARE @v int;
SELECT @v = BusinessEntityID FROM
    (SELECT BusinessEntityID FROM HumanResources.Employee
     UNION ALL
     SELECT BusinessEntityID FROM HumanResources.EmployeeAddress) AS Test;
SELECT @v;

ALTER DATABASE」もご覧ください。See Also ALTER DATABASE