ALTER DATABASE 호환성 수준(Transact-SQL)

특정 데이터베이스 동작이 지정된 버전의 SQL Server와 호환되도록 설정합니다. 다른 ALTER DATABASE 옵션을 보려면 ALTER DATABASE(Transact-SQL)를 참조하십시오.

항목 링크 아이콘 Transact-SQL 구문 표기 규칙

구문

ALTER DATABASE database_name 
SET COMPATIBILITY_LEVEL = { 90 | 100 | 110 }

인수

  • database_name
    수정할 데이터베이스의 이름입니다.

  • COMPATIBILITY_LEVEL { 90 | 100 | 110 }
    데이터베이스가 호환되도록 설정할 SQL Server의 버전입니다. 값은 다음 중 하나여야 합니다.

    90 = SQL Server 2005

    100 = SQL Server 2008 및 SQL Server 2008 R2

    110 = SQL Server 2012

주의

모든 SQL Server 2012 설치에서 기본 호환성 수준은 110입니다. SQL Server 2012에서 만든 데이터베이스는 model 데이터베이스의 호환성 수준이 이보다 낮지 않은 한 이 수준으로 설정됩니다. 이전 버전의 SQL Server 데이터베이스를 SQL Server 2012로 업그레이드할 때 데이터베이스의 호환성 수준이 90 이상이면 기존 수준이 유지됩니다. 호환성 수준이 90 미만인 데이터베이스를 업그레이드하면 데이터베이스 호환성 수준이 90으로 설정됩니다. 이는 시스템 및 사용자 데이터베이스 모두에 적용됩니다. 데이터베이스의 호환성 수준을 변경하려면 ALTER DATABASE를 사용합니다. 데이터베이스의 현재 호환성 수준을 보려면 sys.databases 카탈로그 뷰에서 compatibility_level 열을 쿼리합니다.

이전 버전과의 호환을 위해 호환성 수준 사용

호환성 수준은 전체 서버가 아닌 지정된 데이터베이스의 동작에만 적용됩니다. 호환성 수준은 부분적으로만 SQL Server 이전 버전과의 호환성을 제공합니다. 중간 마이그레이션 도구로 호환성 수준을 사용하여 관련 호환성 수준 설정에서 제어하는 동작의 버전 차이를 해결할 수 있습니다. 기존 SQL Server 응용 프로그램이 SQL Server 2012의 동작 차이에 의해 영향을 받으면 응용 프로그램이 제대로 실행되도록 변환하십시오. 그런 다음 ALTER DATABASE를 사용하여 호환성 수준을 100으로 변경하십시오. 데이터베이스의 새로운 호환성 설정은 다음에 데이터베이스가 현재 데이터베이스로 사용될 때 적용됩니다. 이때 데이터베이스가 로그온 시에 기본 데이터베이스로 사용되는지 또는 USE 문에서 지정한 경우에 기본 데이터베이스로 사용되는지는 상관없습니다.

최선의 구현 방법

사용자가 데이터베이스에 연결되어 있는 동안 호환성 수준을 변경하면 활성 쿼리에 대해 잘못된 결과 집합이 생성될 수 있습니다. 예를 들어 쿼리 계획을 컴파일하는 동안 호환성 수준이 변경되면 컴파일된 계획이 이전 호환성 수준과 새 호환성 수준을 모두 사용할 수 있으므로 잘못된 계획이 생성되고 결과가 정확하지 않을 수 있습니다. 또한 계획을 계획 캐시에 저장하고 후속 쿼리에 다시 사용하는 경우 문제가 복잡해질 수 있습니다. 잘못된 쿼리 결과를 방지하려면 다음 절차에 따라 데이터베이스의 호환성 수준을 변경하는 것이 좋습니다.

  1. ALTER DATABASE SET SINGLE_USER를 사용하여 데이터베이스를 단일 사용자 액세스 모드로 설정합니다.

  2. 데이터베이스의 호환성 수준을 변경합니다.

  3. ALTER DATABASE SET MULTI_USER를 사용하여 데이터베이스를 다중 사용자 액세스 모드로 설정합니다.

  4. 데이터베이스의 액세스 모드를 설정하는 방법은 ALTER DATABASE(Transact-SQL)를 참조하십시오.

호환성 수준 및 저장 프로시저

저장 프로시저가 실행될 때 저장 프로시저는 정의된 데이터베이스의 현재 호환성 수준을 사용합니다. 데이터베이스의 호환성 설정이 변경되면 모든 저장 프로시저도 그에 맞게 자동으로 다시 컴파일됩니다.

호환성 수준 90과 수준 100 사이의 차이

이 섹션에서는 호환성 수준 100으로 정의된 새로운 동작에 대해 설명합니다.

호환성 수준 설정 90

호환성 수준 설정 100

영향력

세션 수준 설정과 상관없이 다중 문 테이블 반환 함수를 만든 경우 이 함수에 대해 QUOTED_IDENTIFER 설정은 항상 ON으로 설정됩니다.

다중 문 테이블 반환 함수를 만든 경우 QUOTED IDENTIFIER 세션 설정이 적용됩니다.

보통

파티션 함수를 만들거나 바꾸면 언어 설정을 US_English로 가정하고 함수의 datetime 및 smalldatetime 리터럴을 평가합니다.

현재 언어 설정은 파티션 함수에서 datetime 및 smalldatetime 리터럴을 평가하는 데 사용됩니다.

보통

FOR BROWSE 절은 INSERT 및 SELECT INTO 문에서 허용되거나 무시됩니다.

FOR BROWSE 절은 INSERT 및 SELECT INTO 문에서 허용되지 않습니다.

보통

전체 텍스트 조건자는 OUTPUT 절에서 허용됩니다.

전체 텍스트 조건자는 OUTPUT 절에서 허용되지 않습니다.

낮음

CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST 및 DROP FULLTEXT STOPLIST는 지원되지 않습니다. 시스템 중지 목록은 자동으로 새로운 전체 텍스트 인덱스와 연결됩니다.

CREATE FULLTEXT STOPLIST, ALTER FULLTEXT STOPLIST 및 DROP FULLTEXT STOPLIST는 지원됩니다.

낮음

MERGE는 예약 키워드가 아닙니다.

MERGE는 완전 예약 키워드입니다. MERGE 문은 호환성 수준 100 및 90 모두에서 지원됩니다.

낮음

INSERT 문에서 <dml_table_source> 인수를 사용하면 구문 오류가 발생합니다.

중첩된 INSERT, UPDATE, DELETE 또는 MERGE 문에서 OUTPUT 절의 결과를 캡처하고 그 결과를 대상 테이블이나 뷰에 삽입할 수 있습니다. 이 작업은 INSERT 문의 <dml_table_source> 인수를 사용하여 수행됩니다.

낮음

NOINDEX가 지정되지 않으면 DBCC CHECKDB 또는 DBCC CHECKTABLE은 단일 테이블이나 인덱싱된 뷰 및 해당하는 모든 비클러스터형 XML 인덱스에 대해 물리적 일관성 검사와 논리적 일관성 검사를 모두 수행합니다. 공간 인덱스는 지원되지 않습니다.

NOINDEX가 지정되지 않으면 DBCC CHECKDB 또는 DBCC CHECKTABLE은 단일 테이블 및 해당하는 모든 비클러스터형 인덱스에 대해 물리적 일관성 검사와 논리적 일관성 검사를 모두 수행합니다. 그러나 XML 인덱스, 공간 인덱스 및 인덱싱된 뷰에 대해서는 기본적으로 물리적 일관성 검사만 수행됩니다.

WITH EXTENDED_LOGICAL_CHECKS를 지정하면 인덱싱된 뷰, XML 인덱스 및 공간 인덱스에 대해 논리적 검사가 수행됩니다. 기본적으로 물리적 일관성 검사는 논리적 일관성 검사 전에 수행됩니다. NOINDEX도 지정할 경우 논리적 검사만 수행됩니다.

낮음

DML(데이터 조작 언어)로 OUTPUT 절을 사용하는 경우 문 실행 중에 런타임 오류가 발생하면 전체 트랜잭션이 종료되고 롤백됩니다.

DML(데이터 조작 언어)로 OUTPUT 절을 사용하는 경우 문 실행 중에 런타임 오류가 발생하면 SET XACT_ABORT 설정에 따라 동작이 결정됩니다. SET XACT_ABORT가 OFF로 설정된 경우 OUTPUT 절을 사용하는 DML 문에서 문 중단 오류가 발생하면 해당 문은 종료되지만 일괄 처리의 실행이 계속되고 트랜잭션이 롤백되지 않습니다. SET XACT_ABORT가 ON으로 설정된 경우 OUTPUT 절을 사용하는 DML 문에서 런타임 오류가 발생하면 항상 일괄 처리가 종료되고 트랜잭션이 롤백됩니다.

낮음

CUBE 및 ROLLUP은 예약 키워드가 아닙니다.

CUBE 및 ROLLUP은 GROUP BY 절에서 예약 키워드입니다.

낮음

XML anyType 형식의 요소에는 엄격한 유효성 검사가 적용됩니다.

anyType 형식의 요소에는 엄격하지 않은 유효성 검사가 적용됩니다. 자세한 내용은 와일드카드 구성 요소 및 콘텐츠 유효성 검사를 참조하십시오.

낮음

특수 특성 xsi:nilxsi:type은 데이터 조작 언어 문으로 쿼리하거나 수정할 수 없습니다.

즉, /e/@*에서 xsi:nil 및 xsi:type 특성을 무시하고 /e/@xsi:nil이 실패합니다. 그러나 xsi:nil = "false"인 경우에도 SELECT xmlCol과의 일관성을 위해 /e에서 xsi:nil 및 xsi:type 특성을 반환합니다.

특수 특성 xsi:nilxsi:type은 일반 특성으로 저장되므로 쿼리 및 수정이 가능합니다.

예를 들어 쿼리 SELECT x.query('a/b/@*')를 실행하면 xsi:nilxsi:type을 포함하는 모든 특성이 반환됩니다. 쿼리에서 이러한 유형을 제외하려면 @*를 @*[namespace-uri(.) != "insert xsi namespace uri"로 바꿉니다. (local-name(.) = "type" 또는 local-name(.) ="nil".로는 바꾸지 마십시오.

Low

XML 상수 문자열 값을 SQL Server datetime 형식으로 변환하는 사용자 정의 함수를 결정적 함수로 표시합니다.

XML 상수 문자열 값을 SQL Server datetime 형식으로 변환하는 사용자 정의 함수를 비결정적 함수로 표시합니다.

낮음

XML union 및 list 형식 중 일부는 지원되지 않습니다.

다음 기능을 포함하여 union 및 list 형식은 모두 지원됩니다.

  • 목록의 합집합

  • 합집합의 합집합

  • 원자성 유형의 목록

  • 합집합의 목록

낮음

인라인 테이블 반환 함수 또는 뷰에 xQuery 메서드가 포함된 경우 이 메서드에 필요한 SET 옵션의 유효성을 검사하지 않습니다.

인라인 테이블 반환 함수 또는 뷰에 xQuery 메서드가 포함된 경우 이 메서드에 필요한 SET 옵션의 유효성을 검사합니다. 메서드의 SET 옵션을 잘못 설정하면 오류가 발생합니다.

낮음

줄 끝 문자(캐리지 리턴 및 줄 바꿈)를 포함하는 XML 특성 값은 XML 표준에 따라 정규화되지 않습니다. 즉, 하나의 줄 바꿈 문자 대신 두 문자 모두 반환됩니다.

줄 끝 문자(캐리지 리턴 및 줄 바꿈)를 포함하는 XML 특성 값은 XML 표준에 따라 정규화됩니다. 즉, 문서 엔터티를 포함하여 구문 분석된 외부 엔터티의 모든 줄 바꿈은 2자 시퀀스 #xD #xA 및 뒤에 #xA가 오지 않는 #xD 모두를 하나의 #xA 문자로 변환하여 입력에서 정규화됩니다.

특성을 사용하여 줄 끝 문자를 포함하는 문자열 값을 변환하는 응용 프로그램은 이러한 제출된 문자를 다시 수신하지 않습니다. 정규화 프로세스를 방지하려면 XML 숫자 문자 엔터티를 사용하여 모든 줄 끝 문자를 인코딩합니다.

낮음

열 속성 ROWGUIDCOL 및 IDENTITY는 제약 조건으로 잘못 이름이 지정될 수 있습니다. 예를 들어 CREATE TABLE T (C1 int CONSTRAINT MyConstraint IDENTITY) 문은 실행되긴 하지만 제약 조건 이름이 보존되지 않으며 이를 통해 사용자에게 액세스할 수 없습니다.

열 속성 ROWGUIDCOL 및 IDENTITY는 제약 조건으로 이름을 지정할 수 없습니다. 오류 156이 반환됩니다.

낮음

UPDATE T1 SET @v = column_name = <expression>과 같은 양방향 할당을 사용하여 열을 업데이트하면 문 실행 중에 WHERE 및 ON 절과 같은 다른 절에서 문의 시작 값 대신 변수의 현재 값을 사용할 수 있으므로 예상치 못한 결과가 발생할 수 있습니다. 그 결과 각 행에서 조건자의 의미가 예기치 않게 변경될 수 있습니다.

이 동작은 호환성 수준이 90으로 설정된 경우에만 발생합니다.

양방향 할당을 사용하여 열을 업데이트하면 문 실행 중에 열의 문 시작 값만 액세스되므로 예상대로 결과가 나타납니다.

낮음

최상위 UNION 연산자가 포함된 문에 변수를 할당할 수 있지만 예상치 않은 결과가 반환됩니다. 예를 들어 다음 문에서 지역 변수 @v에는 두 테이블의 합집합의 열 BusinessEntityID 값이 할당됩니다. 원래 SELECT 문에서 둘 이상의 값을 반환하면 반환된 값 중 마지막 값이 변수에 할당됩니다. 이 경우 변수에 마지막 값이 올바르게 할당되지만 SELECT UNION 문의 결과 집합도 함께 반환됩니다.

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

최상위 UNION 연산자가 포함된 문에는 변수를 할당할 수 없습니다. 오류 10734이 반환됩니다.

오류를 해결하려면 다음 예와 같이 쿼리를 다시 작성합니다.

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

낮음

ODBC 함수 {fn CONVERT()}는 언어의 기본 날짜 형식을 사용합니다. 일부 언어에서 기본 형식은 YDM입니다. 이 경우 CONVERT()가 YMD 형식을 사용하는 {fn CURDATE()}와 같은 다른 함수와 결합되면 변환 오류가 발생합니다.

ODBC 함수 {fn CONVERT()}는 ODBC 데이터 형식 SQL_TIMESTAMP, SQL_DATE, SQL_TIME, SQLDATE, SQL_TYPE_TIME 및 SQL_TYPE_TIMESTAMP로 변환할 때 스타일 121(언어와 상관없는 YMD 형식)을 사용합니다.

낮음

ODBC 함수 {fn CURDATE()}는 날짜 형식(예: 'YYYY-MM-DD')만 반환합니다.

ODBC 함수 {fn CURDATE()}는 날짜 및 시간 형식(예: 'YYYY-MM-DD hh:mm:ss) 모두를 반환합니다.

낮음

DATEPART와 같은 datetime 내장 함수에서 문자열 입력 값은 유효한 datetime 리터럴이 아니어도 됩니다. 예를 들어SELECT DATEPART(year, '2007/05-30')도 성공적으로 컴파일됩니다.

DATEPART와 같은 datetime 내장 함수에서 문자열 입력 값은 유효한 datetime 리터럴이어야 합니다. 유효하지 않은 datetime 리터럴을 사용하면 오류 241이 반환됩니다.

낮음

낮은 호환성 수준과 수준 110 사이의 차이

이 섹션에서는 호환성 수준 110으로 정의된 새로운 동작에 대해 설명합니다.

호환성 수준 설정 100 이하

호환성 수준 설정 110

CLR(공용 언어 런타임) 데이터베이스 개체는 CLR 버전 4를 사용하여 실행됩니다. 그러나 CLR 버전 4에 도입된 일부 동작 변경은 발생하지 않습니다. 자세한 내용은 CLR 통합의 새로운 기능을 참조하십시오.

CLR 데이터베이스 개체는 CLR 버전 4를 사용하여 실행됩니다.

XQuery 함수 string-length 및 substring에서 각 서로게이트를 두 개의 문자로 계산합니다.

XQuery 함수 string-length 및 substring에서 각 서로게이트를 하나의 문자로 계산합니다.

PIVOT이 재귀 공통 테이블 식(CTE) 쿼리에서 허용됩니다. 그러나 그룹화당 여러 행이 있는 경우에는 쿼리에서 잘못된 결과가 반환됩니다.

PIVOT이 재귀 공통 테이블 식(CTE) 쿼리에서 허용되지 않습니다. 오류가 반환됩니다.

RC4 알고리즘은 이전 버전과의 호환성을 위해서만 지원됩니다. 데이터베이스의 호환성 수준이 90 또는 100인 경우 새 자료는 RC4 또는 RC4_128로만 암호화할 수 있습니다. 이 옵션은 사용하지 않는 것이 좋습니다. SQL Server 2012에서 RC4 또는 RC4_128을 사용하여 암호화된 자료는 모든 호환성 수준에서 해독할 수 있습니다.

RC4 또는 RC4_128를 사용하여 새 자료를 암호화할 수 없습니다. 대신 AES 알고리즘 중 하나와 같은 새 알고리즘을 사용하십시오. SQL Server 2012에서 RC4 또는 RC4_128을 사용하여 암호화된 자료는 모든 호환성 수준에서 해독할 수 있습니다.

time 및 datetime2 데이터 형식 중 하나가 계산 열 식에서 사용되는 경우를 제외하고 이러한 데이터 형식에 대한 CAST 및 CONVERT 연산의 기본 스타일이 121입니다. 계산 열의 경우 기본 스타일은 0입니다. 이 동작은 자동 매개 변수화와 관련된 쿼리에서 이러한 연산이 만들어지고 사용될 때 또는 제약 조건 정의에 사용될 때 계산 열에 영향을 줍니다.

다음 예에서는 스타일 0과 스타일 121의 차이점을 보여 줍니다. 위에서 설명한 동작은 보여 주지 않습니다. 날짜 및 시간 스타일에 대한 자세한 내용은 CAST 및 CONVERT(Transact-SQL)를 참조하십시오.

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

호환성 수준 110에서 time 및 datetime2 데이터 형식의 CAST 및 CONVERT 연산에 대한 기본 스타일은 항상 121입니다. 쿼리에 이전 동작이 적용되는 경우 110보다 낮은 호환성 수준을 사용하거나, 해당 쿼리에서 스타일 0을 명시적으로 지정해야 합니다.

데이터베이스를 호환성 수준 110으로 업그레이드할 경우 디스크에 저장된 사용자 데이터는 변경되지 않습니다. 수동으로 이 데이터를 적절하게 수정해야 합니다. 예를 들어 SELECT INTO를 사용하여 위에서 설명한 계산 열 식이 포함된 원본에서 테이블을 만든 경우 계산 열 정의 자체가 아니라 스타일 0을 사용하는 데이터가 저장됩니다. 스타일 121과 일치하도록 이 데이터를 수동으로 업데이트해야 합니다.

분할 뷰에서 참조되는 smalldatetime 형식의 원격 테이블 열은 datetime로 매핑됩니다. 로컬 테이블의 해당 열(SELECT 목록의 동일한 서수 위치에 있는 열)은 datetime 형식이어야 합니다.

분할 뷰에서 참조되는 smalldatetime 형식의 원격 테이블 열은 smalldatetime로 매핑됩니다. 로컬 테이블의 해당 열(SELECT 목록의 동일한 서수 위치에 있는 열)은 smalldatetime 형식이어야 합니다.

110으로 업그레이드한 후에는 데이터 형식이 일치하지 않으므로 분산형 분할 뷰가 실패합니다. 원격 테이블의 데이터 형식을 datetime으로 변경하거나 로컬 데이터베이스의 호환성 수준을 100 이하로 설정하여 이 문제를 해결할 수 있습니다.

SOUNDEX 함수는 다음 규칙을 구현합니다.

  1. SOUNDEX 코드에 동일한 숫자가 있는 두 개의 자음을 구분하는 경우 대문자 H 또는 대문자 W가 무시됩니다.

  2. SOUNDEX 코드에서 character_expression의 처음 2자에 같은 숫자가 있으면 두 문자 모두 포함됩니다. 위의 경우에 해당되지 않고 SOUNDEX 코드에서 나란히 있는 자음에 같은 값이 있으면 첫 번째 문자를 제외한 모든 문자가 제외됩니다.

SOUNDEX 함수는 다음 규칙을 구현합니다.

  1. 대문자 H 또는 대문자 W가 동일한 SOUNDEX 코드 숫자를 갖는 두 개의 자음을 구분하는 경우 오른쪽의 자음은 무시됩니다.

  2. 나란히 있는 자음에 SOUNDEX 코드의 같은 값이 있으면 첫 번째 문자를 제외한 모든 문자가 제외됩니다.

추가 규칙으로 인해 SOUNDEX 함수에서 계산된 값이 이전 호환성 수준에서 계산된 값과 다를 수 있습니다. 호환성 수준 110으로 업그레이드한 후 SOUNDEX 함수를 사용하는 인덱스, 힙 또는 CHECK 제약 조건을 다시 작성해야 할 수 있습니다. 자세한 내용은 SOUNDEX(Transact-SQL)를 참조하십시오.

예약 키워드

호환성 설정은 데이터베이스 엔진에 예약되는 키워드도 결정합니다. 다음 표에서는 각 호환성 수준에 의해 정의된 예약 키워드를 보여 줍니다.

호환성 수준 설정

예약 키워드

110

WITHIN GROUP, TRY_CONVERT, SEMANTICKEYPHRASETABLE, SEMANTICSIMILARITYDETAILSTABLE, SEMANTICSIMILARITYTABLE

100

CUBE, MERGE, ROLLUP

90

EXTERNAL, PIVOT, UNPIVOT, REVERT, TABLESAMPLE

지정된 호환성 수준의 예약 키워드에는 해당 수준 또는 그 아래 수준에서 정의된 모든 키워드가 포함됩니다. 따라서 수준이 110인 응용 프로그램의 경우에는 위 표에 나열된 모든 키워드가 예약되어 있습니다. 더 낮은 호환성 수준에서 수준이 100인 키워드는 유효한 개체 이름으로 유지되지만 해당 키워드에 대한 수준이 110인 언어 기능은 사용할 수 없습니다.

정의된 키워드는 예약된 상태로 유지됩니다. 예를 들어 호환성 수준 90에서 정의된 예약 키워드 PIVOT은 수준 100과 110에서도 예약되어 있습니다.

응용 프로그램이 호환성 수준에 대한 키워드로 예약되어 있는 식별자를 사용할 경우 제대로 실행되지 않습니다. 이러한 문제를 해결하려면 식별자를 대괄호([ ])나 따옴표(" ")로 묶으십시오. 예를 들어 식별자 EXTERNAL을 사용하는 응용 프로그램을 호환성 수준 90으로 업그레이드하려면 식별자를 **[EXTERNAL]**이나 **"EXTERNAL"**로 변경할 수 있습니다.

자세한 내용은 예약된 키워드(Transact-SQL)를 참조하십시오.

사용 권한

데이터베이스에 대한 ALTER 권한이 필요합니다.

1.호환성 수준 변경

다음 예에서는 AdventureWorks2012 데이터베이스의 호환성 수준을 110, SQL Server 2012로 변경합니다.

ALTER DATABASE AdventureWorks2012
SET COMPATIBILITY_LEVEL = 110;
GO

참고 항목

참조

ALTER DATABASE(Transact-SQL)

예약된 키워드(Transact-SQL)

CREATE DATABASE(Transact-SQL)

DATABASEPROPERTYEX(Transact-SQL)

sys.databases(Transact-SQL)

sys.database_files(Transact-SQL)