복제 제한 사항

Microsoft SQL Server Compact 3.5 구독자에 병합 복제를 사용할 경우 게시와 관련한 몇 가지 제한 사항이 있습니다. 이 섹션에서는 이러한 제한 사항에 대해 설명합니다.

구독자의 스키마 변경 제한 사항

구독자에서 스키마를 변경할 수 있지만 일부 변경 작업은 수행할 수 없습니다. 다음 표에서는 구독자에서 변경을 수행할 수 있는 스키마와 변경할 수 없는 스키마를 설명합니다.

동작	복제된 테이블에서 허용되는 작업
테이블 삭제	아니요
테이블 이름 바꾸기	아니요
열 추가/삭제/제거	아니요
ID 열에서 초기값 또는 증가값 변경	예
기본값 추가 또는 삭제	예
기본 키 추가 또는 삭제	아니요
외래 키 추가 또는 삭제	아니요
인덱스 추가 또는 삭제 주의 사용자 테이블의 복제 열에서는 인덱스를 추가하거나 삭제하지 않는 것이 좋습니다. 복제 열은 시스템 열로 취급되기 때문에 동기화 오류가 발생할 수 있습니다.	예
인덱스 이름 바꾸기	예

추가 요구 사항

다음 규칙은 SQL Server Compact 3.5 구독자에 적용됩니다.

• 메모리 사용

  다시 초기화가 요청된 다음 동기화하는 동안 SQL Server Compact 3.5 데이터베이스가 실제 데이터베이스 크기보다 일시적으로 두 배로 증가할 수 있지만 동기화가 완료된 다음에는 자동 축소 정책에 따라 다시 축소됩니다.

• 구독 필터 유효성 검사

  게시자는 데이터를 동기화하기 전에 필터 유효성 검사를 통해 구독자의 필터 값을 확인할 수 있습니다. 구독자 쪽의 필터 값이 변경된 경우 게시자는 구독자에서 다시 초기화하도록 요구합니다. SQL Server 2008 R2와 데이터를 동기화할 때는 SQL Server Compact 3.5에서 필터 유효성 검사를 사용할 수 있습니다.

  참고

  HostName 속성은 구독의 동적 필터 값을 지정합니다. 새 HostName 속성을 지정하여 구독의 동적 필터 값을 변경하려면 동기화하기 전에 Reinitialize 메서드를 호출해야 합니다.

• 대/소문자 구분

  SQL Server Compact은 SQL Server Compact 3.5 서비스 팩 1 릴리스부터 데이터베이스 수준에서 대/소문자를 구분하는 데이터 정렬을 설정하는 작업을 지원합니다. 그러나 데이터 정렬이 대/소문자를 구분하더라도 테이블 이름, 언어 키워드, 함수 및 뷰와 같은 개체 이름은 SQL Server Compact 데이터베이스에서 대/소문자를 구분하도록 처리되지 않습니다.

  즉, SQL Server Compact 데이터베이스에서는 개체가 SQL Server 데이터베이스와 다른 방식으로 처리됩니다. 예를 들어 MYTABLE과 mytable의 두 테이블은 대/소문자를 구분하는 SQL Server 데이터베이스에서 서로 다른 개체로 처리됩니다. SQL Server Compact 데이터베이스에서는 동일한 테이블 이름으로 처리되어 이름 충돌이 발생합니다. 반면 두 개의 값 MYVALUE와 myvalue는 대/소문자를 구분하는 SQL Server 데이터베이스에서 위반을 발생시키지 않는 것과 마찬가지로 SQL Server Compact에서 서로 다른 값으로 처리되므로 더 이상 기본 키 위반을 발생시키지 않습니다.

• 테이블의 열 개수

  SQL Server Compact 3.5에서는 추적 기능에 시스템 열 7개를 할당합니다. 그러나 이러한 시스템 테이블은 열 개수 제한에 계산되지 않습니다.

• NOT FOR REPLICATION 제약 조건

  SQL Server Compact 3.5에서는 NOT FOR REPLICATION 옵션을 지원하지 않습니다. 이 옵션을 사용하여 제약 조건을 만들지 마십시오. 데이터베이스의 제약 조건에 NOT FOR REPLICATION 옵션이 있을 경우 해당 제약 조건을 제거하고 다시 만들어야 합니다. NOT FOR REPLICATION 옵션을 지정하면 SQL Server Compact 3.5 구독자에 제약 조건이 만들어지지만 NOT FOR REPLICATION 구문은 포함되지 않습니다.

• 연결 제한 시간

  사용자 구성 가능한 제한 시간 내에 연결이 복원되기만 하면 SQL Server Compact 3.5 구독은 성공적으로 전송된 마지막 데이터 블록에서 다시 시작하여 통신 실패로부터 복구됩니다. 이렇게 하면 기본 전송이 안정적이지 않거나 일시적으로 사용할 수 없는 경우에도 동기화가 가능합니다.

• 스냅숏

  SQL Server Compact 3.5에서는 기본 및 대체 스냅숏 위치 옵션을 모두 지원합니다. 대체 스냅숏 위치를 지정하려면 sp_addmergepublication 저장 프로시저를 사용하거나 SQL ServerManagement Studio에서 기존 게시의 속성을 변경하여 이 옵션을 설정할 수 있습니다.

  • sp_addmergepublication 저장 프로시저를 사용하려면

    @snapshot\_in\_defaultfolder 옵션을 FALSE로 설정하고 @alt\_snapshot\_folder= 스냅숏의 대체 폴더 위치를 설정합니다.

  • 기존 게시의 게시 속성을 변경하려면

    게시에 대한 속성 대화 상자의 스냅숏 섹션에서 기본 폴더에 파일 보관 확인란의 선택을 취소하고 다음 폴더에 파일 보관 확인란을 선택한 다음 새 위치를 지정합니다.

  참고

  SQL Server Compact 3.5에서는 압축 스냅숏 옵션을 지원하지 않습니다.

스냅숏에 대한 자세한 내용은 스냅숏 폴더 구성을 참조하십시오.

SQL Server Compact 3.5 구독자에 전파되지 않는 정보

다음 항목은 SQL Server 게시에 포함할 수 있지만 SQL Server Compact 3.5 구독자로 전파되지 않습니다.

• CHECK 제약 조건

• 확장 속성

• 저장 프로시저

• 뷰

• 사용자 정의 함수

• 트리거

SQL Server Compact 3.5 복제를 통해 이러한 항목을 전파할 수 없으므로 SQL Server Compact 3.5 기반 응용 프로그램에서 이에 상응하는 논리를 구현해야 합니다. 그러면 SQL Server Compact 3.5 데이터베이스가 SQL Server 데이터베이스와 일관성 있는 상태로 유지됩니다. 예를 들어 SQL Server 데이터베이스에 CHECK 제약 조건이 있을 경우 SQL Server Compact 3.5 기반 응용 프로그램은 응용 프로그램 코드에서 해당 CHECK 제약 조건을 구현해야 합니다.

로컬 SQL Server Compact 3.5 데이터베이스에서 인덱스 생성

로컬 SQL Server Compact 3.5 데이터베이스가 게시에 대한 구독자인 경우에도 이 데이터베이스에서 고유 인덱스를 만들 수 있습니다. 이 기능은 유용하지만 열에 UNIQUE 제약 조건이 없는 게시자가 고유하지 않은 데이터를 구독자에게 보낼 경우 문제가 발생할 수 있습니다. 테이블 T에 열 C1 및 C2가 있고 기본 키가 C1에 있는 경우를 예로 들어 보겠습니다.

SQL Server Compact 3.5 데이터베이스에서 최초 동기화가 이루어집니다. 이 동기화 후에는 고유 인덱스가 구독 데이터베이스의 C2에 추가됩니다. 게시 데이터베이스는 변경되지 않습니다.

다음에 동기화를 수행할 때 SQL Server에서 다음 행을 삽입합니다.

이 경우 게시자가 고유하지 않은 C2 값을 삽입하려고 시도했기 때문에 동기화에 실패합니다. UNIQUE 제약 조건을 구독 데이터베이스에서 제거할 때까지 동기화는 계속 실패합니다.