Silverlight를 설치하려면 여기를 클릭합니다.*
Korea 대한민국변경|Microsoft 전체 사이트
MSDN
|개발자 센터
MSDN Home   MSDN Home
MSDN 홈 > MSDN Magazine > 2001년 기사 > SQL Server CE: 새로운 버전은 여러분이 포켓용 장치에 데이터를 저장하고 업데이트할 수 있도록 합니다.
SQL Server CE: 새로운 버전은 여러분이 포켓용 장치에 데이터를 저장하고 업데이트할 수 있도록 합니다.

Paul Yao와 David Durant

이 기사는 여러분이 SQL, Visul Basic 및 ADO를 확실히 알고 있다는 것으로 간주합니다.

요약 포켓용 장치 사용자들은 편리한 때 혹은 back-end 데이터 서버가 바쁘지 않을 때 주 데이터 저장과 동기화 하는 것이 가능하도록 되어야 합니다. SQL Server 2000 Windows CE Edition은 여러분이 다양한 장치들에서 보여지고 실행될 수 있는 이동용 데이터 저장을 구축하는 것을 가능하게 합니다. SQL Server CE는 완전한 SQL Server 패키지의 하위집합을 지원하고 독립형 서버 혹은 SWL Server 및 IIS와 함께 사용될 수 있습니다. 데이터 조작, 동기화 및 연결성 문제를 포함한 SQL Server CE의 아키텍처가 이 기사에서 다뤄집니다. 여러분의 데이터를 공공화하고, 적절한 복제 형태를 선택하고 그리고 에러들을 다루는 것들 또한 다뤄집니다.


컴퓨터 하드웨어의 지난 50년은 명백한 흐름들을 보여주었습니다. 그 중 하나는 장치들이 엄청나게 소형화 되고 있다는 것입니다. 반세기 이전의 대형 컴퓨터들은 엄청난 공간을 차지하고 있었습니다. 1960년대 냉장고 크기의 소형 컴퓨터가 등장했고 1980년대 중간 크기의 개 정도의 컴퓨터가 확산되었습니다. 오늘날, 여러분의 주머니 크기의 휴대용 전화기의 사용과 Personal Digital Assistants(PDA) 사용의 확산은 놀랍게 축소되는 기계의 지속적인 발전에 대한 획기적인 사건입니다.

이러한 변화들 속에서 어떤 것들은 지속적으로 유지됩니다. 컴퓨터는 데이터가 텍스트 문서인지, 스프레드시트인지 혹은 데이터베이스 형태인지에 대한 데이터 관리를 일차적으로 합니다. 여러분이 필요로 하는 소프트웨어와 새로운 하드웨어의 생성을 조절하는 것은 그 특유의 기능을 사용하는 새로운 소프트웨어에 의해서 수반됩니다. Microsoft는 Windows CE에 의해 작동되는 휴대용 장치의 데이터 조절 능력을 강화하기 위해 SQL Server™ 2000 Windows® CE Edition (SQL Server CE)을 만들었습니다. SQL Server CE를 실행시킬 수 있는 Windows CE에 의해 작동되는 장치의 목록을 보기 위해서는 그림 1을 보십시오.

어떻게 이 제품이 사용될 지에 대한 이해를 위해 우리는 제품의 기능과 이점들에 중점을 둔 사용 시나리오들을 프레이밍 하는 것으로 시작할 것입니다. Windows CE를 새롭게 접하는 독자들을 위해 우리는 Windows CE 데이터 보관의 기초를 설명할 것입니다. 그리고 나서 우리는 여러분들이 SQL Server Windows CE Edition을 위한 개발에 필요한 도구들의 빨리 보기를 제공하고, 원격 데이터 베이스 제품의 데이터 복제 그리고 원격 장치와 중앙 데이터 저장 간의 연결성 지원 이 두 가지 주 특징들을 설명할 것입니다.

이 제품에 관련된 우리의 가장 큰 도전은 Remote Data Access(RDA)와 병합 복제 이 두 가지의 연결 옵션을 설정하는 것이었습니다. 기업 클라이언트에게 SQL Server을 교육한 우리의 경험으로 미루어 볼 때 우리는 종종 해당 데이터베이스 프로그래머들이 웹 기반 응용 프로그램을 만들거나 보안을 설정하는 것 등에 약간의 경험이 있거나 경험이 없는 경우를 보았습니다. 이것을 위하여 우리는 이 기사의 뒷부분을 우리가 직면했던 문제점을 설명하고 해결하는데 치중했습니다. 이것과 함께 여러분의 데이터베이스 코딩 작업을 시작하는 것을 돕기 위해 몇몇 코드들이 제공됩니다.

중요: 나머지 분들을 위해서 우리는 SQL Server 2000 Windows CE Edition을 지정하기 위해 "SQL Server CE"을 사용할 것입니다. 다른 특별한 주의가 없다면, SQL Server에 대한 모든 참조 사항들은 Windows NT®와 Windows 2000에서 작동하는 SQL Server 버전들(SQL Server 6.5, SQL Server 7.0 및 SQL Server 2000)와 연관되어 있습니다.

맨 위로


사용 시나리오

세 가지 요소들이 각각의 시나리오의 주요 부분들을 만듭니다: Windows CE가 설치된 장치, 저장될 일부 데이터 및 일반적으로 휴대용 기기 사용자 - 반드시 휴대용이어야 되는 것은 아님. 다른 두 가지의 요소들도 중요합니다: SQL Server 데이터베이스에 의해 유지되는 중앙 데이터 보관과 Windows CE가 설치된 장치와 SQL Server 데이터베이스 간의 데이터 이동을 위한 전송 메커니즘.

데이터 전송을 위한 유선과 무선 등의 옵션들은 많습니다. Windows CE가 설치된 장치는 모뎀, 유선 네트워크 및 장치 도킹 크래들과 같은 구식 장치들을 사용하여 외부에 열결될 수 있습니다. 널리 분포되지는 않았지만 보다 많은 데이터를 보다 빠르게 전송하는 방법들인 휴대폰, 무선 LAN 및 Blue Tooth와 같은 다른 데이터 전송들도 있습니다.

맨 위로


시나리오 1: 이동 판매원

휴대용 장치 사용자의 가장 좋은 예는 이동 판매원 입니다. 판매 중에 널리 사용되는 말은 "어떤 것이 판매되기 전까지는 아무런 일도 성취되지 않는다는 것 입니다." 만일 이것이 사실이라면, 우리는 판매 데이터를 그것이 가능해졌을 때 바로 회수할 수 있도록 하기 위해 무엇이든지 해야 할 것입니다. 게다가, 우리는 사업에 매우 중요한 것들을 위한 그들의 노력에 도움을 주기 위해 주문 상태, 리즈 그리고 다른 중요한 판매 데이터 등과 같은 데이터를 이동 판매원에게 보내고자 합니다.

대부분의 판매원들이 그들의 휴대폰에 의존하고 있기 때문에, 그들이 Windows CE가 설치된 장치를 갖추게 되면, 자연스럽게 데이터 전송을 위해 전화를 연결할 수 있습니다. 물론 Windows CE가 설치된 장치는 그 자신의 독립적인 휴대용 연결이 장착될 수 있습니다. 이와 동시에 Windows CE가 설치된 장치는 본 기기로부터 순서 정보를 업로드하고 새로운 데이터들을 다운로드 하고 있는 그 휴대용 연결을 통해 사무실이나 집에 통화할 수도 있습니다.

컴퓨터에 휴대폰을 제공하는 생각은 처음에 이상하게 들릴 수도 있지만, 이것은 데스크톱 컴퓨터의 모뎀을 위한 지정 전화선을 갖는 것과 별 차이가 없습니다. 이 기사를 쓰고 있는 동안에도 몇몇 기업들은 휴대폰이 내장된 포켓용 PC기반 장치들을 출시할 것을 계획하고 있습니다. 이러한 장치들이 출시를 시작하면, 보다 많은 데이터베이스 연결들이 휴대용 연결들에 연관될 것입니다.

맨 위로


시나리오 2: 제품 배달 트럭

물론 위와 같이 시급한 보고를 필요로 하지않는 경우도 있습니다. 때때로, 중앙 데이터 보관으로의 일일 연결이 적합한 경우도 있습니다. 배달, 품목 및 새로운 주문 정보를 수집해야 하는 배달 트럭 (예를 들면, 빵, 쿠키 혹은 감자 칩 등을 배달하는 트럭)을 생각해 보십시오. 만일 기업에서 일일 업데이트를 필요로 한다면, 제품 배달자는 매일 하루를 시작할 때 사무실에 Windows CE가 설치된 장치를 가져올 수 있습니다. 이 때 그 전날 배달의 데이터는 다운로드되고 그 날의 배달이 디바이스에 저장될 수 있습니다.

이 시나리오는 중앙 데이터 보관소와의 연결 횟수와 이 연결을 구축하기 위해 사용되는 기술을 제외하고는 첫 번째 시나리오와 유사합니다. 만일 장치가 사무실로 가져와 졌다면, 도킹 스테이션이나 무선 연결을 통해 SQL Server에 연결될 수 있습니다. 어떠한 경우에도 그 장치는 TCP/IP를 통해 연결을 만듭니다. 사실, SQL Server CE를 위한 크로토콜은 HTP입니다.(직렬이나 USB 도킹 크래들의 기존 포켓용 PC가 RCP/IP에 액세스하기 위해서 여러분은 SQL Server CE 버전 1.1이나 최신 버전을 사용해야 한다는 것을 명심하십시오.

HTTP 사용의 이점은 이것이 전세계의 거의 모든 지역에서 액세스할 수 있다는 점입니다. 게다가, 최소한의 노력으로 대부분의 방화벽들과 호환되는 방법으로 액세스가 제공됩니다. 이것은 새로운 Microsoft® .NET 아키텍처가 "프로그램 할 수 있는 웹"이라고 불리는 차세대 인터넷을 구축하기 위해 취한 접근과 동일한 방법입니다.
컴파일러는 이전 줄을 볼 때 그림?2의 코드와 유사한 완벽한 클래스 정의를 정확하게 정의합니다.

맨 위로


시나리오 3: 무선 보관소

어떠한 장치들은 집 외부에서는 연결되지 않지만 여전히 제한된 지역에서 휴대용일 필요가 있습니다. 이것은 Intermec와 Symbol Technologies와 같은 기업의 바코드 판독원의 경우에 해당됩니다. 바코드 판독원은 일반적으로 재고, 주문 추적 및 다른 데이터베이스 관련 필요들을 위해 저장소에 배치되어 있습니다. 종종 바코드 판독원들은 무선 RF 네트워크를 사용합니다. 이것은 데이터를 중앙 데이터 저장소와 각각의 장치 사이에 판독한 대로 데이터를 주고 받을 수 있도록 합니다.

이 시나리오에서 Windows CE가 설치된 장치를 배포하는 데에는 몇 가지 방법이 있습니다. 하나는 바코드 판독자를 중앙 서버들이 모든 프로세스를 실행하게 하면서 단순 터미널로 제공하는 것입니다. 어쨌든 이 방법에는 문제점들이 있습니다. 장치가 범위를 벗어나거나 혹은 네트워크 라디오 신호가 물리적인 장애물에 의해 차단되어 자주 네트워크가 사용 불가능할 수 있습니다. 이 방법에 대한 두 번째 문제는 중앙 서버가 모든 장치들이 몰려드는 가장 바쁜 시간에 마비될 수도 있다는 것입니다.

SQL Server CE는 각각의 바코드 식별자가 저장소를 돌아다니며 독립적으로 실행할 수 있기 때문에 이러한 환경에 가장 이상적인 솔루션입니다. 모든 필요한 데이터는 SQL 데이터베이스로 장치 자체에 보관될 수 있습니다. 주기적으로 장치가 범위 내에 있고 서버가 사용 가능할 때, Windows CE가 설치된 장치의 데이터베이스는 중앙 데이터 저장소와 동기화될 수 있습니다. 이러한 구성은 최대 유용성을 모든 관련 데이터베이스의 지속적인 업데이트와 함께 제공합니다.

맨 위로


시나리오 4: 판매 지점 터미날

SQL Server CE는 심지어 Windows CE가 설치된 장치가 휴대용이 아닌 경우에도 사용될 수 있습니다. 영구적인 네트워크 연결을 사용하는 판매원의 고정 집단에 의해 액세스되는 영구적인 데이터베이스를 생각해 보십시오. 한 가지 방법은 장치들과 네트워크 연결들이 정위치에 있는 소매 판매 지점(POS) 터미널을 설명하는 것입니다. 이러한 장치들은 Windows CE를 실행하는 많은 장치들처럼 배터리를 사용하는 것 대신에 전원을 위해 벽면 소켓에 플러그를 꽂을 수 있습니다. 아마도 이 터미널들은 큰 백화점이나 커피숍 체인점에 배포될 것입니다.

소매 터미널들은 모든 작업들에 대해 중앙 서버들에 의존합니다. 하지만 중앙 서버가 과부하 되어 네트워크를 사용할 수 없게 되는 문제점에 직면할 수 있습니다. 그리고 상점을 닫는 것과 동일한 가동 정지 시간을 갖고 있습니다. 최대한의 안정성을 보유하기 위하여 이것은 각각의 POS 터미널이 그 자체만으로 충분하게 되도록 합니다.

이러한 환경에서 SQL Server CE를 배포하는 것은 자체적으로 충분해질 수 있도록 합니다. 제품 가격 데이터베이스의 스내샷은 각각의 장치에 보관될 수 있습니다. 소매 점원은 네트워크나 중앙 서버가 사용 가능한지를 확인할 수 있습니다. 주기적으로 판매가 중앙 서버에 업로드될 수 있습니다. 가격 데이터베이스가 업데이트되는 것처럼 새로운 정보는 판매 터미널 상의 데이터 저장소의 로컬 카피에 다운로드될 수 있습니다.

맨 위로


시나리오 5: 개인 데이터베이스

우리가 지금까지 논의한 모든 시나리오들은 중앙 서버로의 연결을 포함하고 있습니다. 이것은 확실히 SQL Server CE가 개발 되었을 때의 일차적인 시나리오였습니다. 하지만 어떠한 중앙 데이터 저장소 없이 Windows CE 기반 데이터베이스를 보유하는 것을 가능하게 합니다. 예를 들면, 여행 중에 만나게 된 식당을 기록하는 여행 중인 판매원을 생각해 보십시오. 그는 훌륭한 와인의 유용성, 식물성 메뉴 모음 혹은 각각의 식당의 1인분의 양을 기록할 수 있습니다. 이러한 정보들의 모음은 미래의 판매를 위해 소중하게 사용될 수 있거나 심지어 판매원에게 여행 작가로의 제2의 직업을 제공할 수도 있습니다

핵심 요소는 판매원이 중앙 데이터베이스로 주문 기록을 보내는 동안, 식당 데이터베이스는 어느 곳에도 업로드되지 않는다는 것입니다. 이는 판매자의 개인적인 사용을 위한 것입니다. 여기서도 SQL Server CE가 사용될 수 있습니다. 비록 서버 버전의 모든 기능을 제공하지는 않지만 SQL Server CE는 데이터베이스를 만들고 업데이트 하기 위한 핵심적 SQL 명령어를 지원합니다. 이는 독립 데이터베이스로써 기본 사양 이상의 성능입니다.

맨 위로


Windows CE의 데이터 저장

만약 여러분이 Windows CE를 처음 접한다면 Windows CE가 데이터 저장에 대해 얼마나 지원을 해주는지에 대한 의문이 있을 것입니다. Windows CE는 광범위한 플랫폼을 위해 만들어졌고 이에 따라 광범위한 저장 장치를 지원합니다. 예를 들어 Windows CE로 작동되는 장치는 데스크톱 PC가 사용하는 모든 장치(적당한 장치 드라이버가 제공되었을 경우의 하드 드라이브, 테이프 드라이브, DVD 판독기/작성기 등)를 사용할 수 있도록 구성될 수 있습니다. 다만, Windows CE로 작동되는 이동 장치의 실체 저장 장치는 이 이론적 목록의 내용과 많이 다릅니다.

HP Jarnada 548과 같은 포켓용 PC를 생각해 보십시오. 포장을 풀었을 때 이 PC는 운영 시스템 이미지를 저장할 수 있는 16MB의 ROM을 장착하고 있고, 내 데이터를 위해서 32MB의 RAM을 장착하고 있습니다. 이는 총 48MB의 메모리입니다. 일반적인 Windows CE로 작동되는 이동 장치는 배터리 전원을 절약하고 장치의 무게를 최대한 줄이기 위해서 하드 드라이브를 가지고 있지 않습니다.

하드 드라이브에 저장을 하지 않기 때문에 Windows CE는 개체 저장소라는 저장소를 지원합니다. 이 RAM 저장소는 파일 시스템, 레지스트리, Windows CE 데이터베이스의 3가지 부분으로 이루어져 있습니다. 파일 시스템은 데스크톱 WIndows와 같은 긴 경로를 지원하기 때문에 파일의 경로는 최대 260자까지 지정될 수 있습니다. 계층화된 레지스트리는 비록 상대적으로 작긴 하지만 데스크톱 컴퓨터의 Windows 레지스트리와 매우 비슷합니다. 데이터베이스 지원은 flat-file manager라고 할 수 있습니다. 내장된 데이터베이스 지원은 조금 낡았다고 할 수 있으며, 1,000개 이상의 기록으로 작업할 경우에는 액세스가 매우 느려집니다. 이 데이터베이스 지원은 꽉 찬 데이터 저장소보다는 개인 전화번호 목록과 같은 작은 데이터베이스를 저장하기 위해 만들어졌습니다. SQL Server CE 데이터베이스는 Windows CE 장치의 파일 시스템 내부의 파일로 되어 있고 내장된 Windows CE 데이터베이스 지원을 사용하지 않습니다.

저장된 개체가 RAM 기반이기 때문에, 당신의 장치가 가지고 있는 RAM은 프로그램 메모리와 개체 저장이라는 두 가지의 기본적 용도로 사용되게 됩니다. 시스템 설정은 이 두 가지 용도로 사용 가능한 RAM을 지정합니다. 이는 프로그램이나 제어판을 통해 설정될 수 있습니다. 개체 저장소의 메모리는 최소 압축 메커니즘에서 조금 더 확장됩니다. 이 메모리는 빠르지만 약합니다. 개체 저장소의 모든 데이터에 21%의 압축률 밖에 제공하지 않습니다.

Windows CE 데이터베이스에 대해 한가지 주의하실 점은 이 데이터베이스가 개체 저장소에 탑재되거나 탑재되지 않은 두 가지 상태로 저장될 수 있다는 점입니다. 개체 저장 압축 (비록 성능이 낮아지지만) 에서 최대한 이익을 얻으시려면 Windows CE 데이터베이스는 탑재된 데이터베이스로 저장되어야 합니다.

그렇다면 일반적인 Pocket PC는 얼만큼의 실제 데이터베이스 저장 공간을 가지고 있을까요? 사용 가능한 32MB의 RAM을 일정한 부분으로 나누면 프로그램 메모리용으로 16MB 가 남고 데이터 저장용으로 16MB가 남게 됩니다. 압축까지 고려하면 16MB를 다시 얻을 수 있기 때문에 총 데이터 저장 능력은 32MB가 됩니다.

RAM이 수백 메가바이트로 측정되고 하드 드라이브 저장소가 기가바이트로 측정되는 요즘에는 Windows CE의 메모리는 조금 작게 느껴질 수도 있습니다. 하지만 설치 가능한 파일 시스템을 통해 사용 가능한 저장소에 추가할 수 있습니다. (이러한 장치가 저장 장치일 뿐이고 사용 가능한 프로그램 메모리를 확장 시키지는 않는다는 점을 명심하십시오.) 저의 Pocket PC에는 디지털 카메라에서 찾아볼 수 있는 Compact Flash (CF) 슬롯이 있습니다. 불과 몇 백 달러에 저는 사용 가능한 저장 공간을 수백 메가바이트로 확장할 수 있습니다 (이 글을 쓰고 있는 현재, 저희가 알고 있는 최대 CF 저장 카드는 256MB의 공간을 가지고 있습니다).

CF 슬롯에 끼울 수 있는 하드 드라이브도 있습니다. IBM은 340MB의 CF 회전 미디어 카드를 가지고 있고 1GB의 회전 미디어 CF 카드를 가지고 있습니다. 이것은 회전 미디어가 Windows CE로 작동되는 이동 장치에서 전체적으로 제거되었기 때문에 반어적입니다. 회전 자기 미디어는 CF 메모리 카드인 것처럼 가장하여 슬그머니 부활할 수 있었습니다.

반면에, 이러한 드라이브는 CF 카드보다 더 많은 전력을 소모합니다. 이는 이 장치가 회전하기 때문입니다. 동시에, 사용자가 배터리 수명, 저장 능력, 비용 (하드 드라이브의 메가바이트당 비용은 CF 메모리 카드보다 조금 낮습니다) 에 대한 개인적인 선택을 할 수 있다는 이점이 있습니다. 메모리 카드와 회전 미디어 카드 모두 FAT 기반이기 때문에 FAT과 CE 파일 시스템으로 변환할 때 성능이 낮아질 수 있습니다.

SQL Server CE 데이터베이스는 Windows CE가 찾을 수 있는 곳에서 파일로 존재합니다. 이것은 당연히 이 데이터베이스가 개체 저장소에 Windows CE 데이터베이스가 아닌 일반 파일로 존재한다는 것을 의미합니다. 이러한 데이터베이스는 다양한 형식의 설치 가능한 파일 시스템 혹은 장치들(하드 드라이브, CF 플래시 메모리 카드나 정상적인 드라이버가 설치되었다고 가정하였을 때 쓰기 가능한 CD나 DVD 드라이브 등)에 상주할 수 있습니다.

각 SQL Server CE 데이터베이스는 장치에 단일 파일로 저장되어 있습니다. 보안의 목적으로 128-bit의 암호화를 데이터베이스와 사용하여 패스워드를 연결시키고 물리적 파일을 암호화할 수 있습니다. 이 후에 당신의 응용 프로그램은 데이터베이스에 연결 할 때 패스워드의 지정을 필요로 할 것입니다. 권장되는 파일 확장명은 .sdf입니다. 파일명이 데이터베이스의 이름이라는 점에 주의하십시오. 그러므로, mvdb가 아닌 mvdf.sdf로 연결하게 됩니다.

맨 위로


SQL Server CE의 아키텍처

여러분이 SQL Server CE를 가동할 때, SQL Server는 클라이언트로 고려됩니다. (사실, SQL Server CE는 실제 서버인 SQL Server와는 달리 처리 중인 상태로 가동되고 처리 서버 없이 가동되는 통합된 OLE DB로 보호되는 DLL입니다.) 이 디자인 철학은 SQL Server 팀에 의한 몇 가지의 놀라운 구현 결정들을 만들어 냈습니다. 첫 번째는 SQL Server CE를 가동하는 두 장치들이 서로 일대 일 기반으로 상호 작용할 수 없다는 것입니다. (Windows NT와 Windows 2000에 설치된 SQL Server에서 작업해본 개발자들은 SQL Server에서는 일대 일 상호 작용이 훌륭하게 지원된다는 것을 알고 있습니다.) 이 두 가지 사이의 또 하나의 차이점은 SQL Server는 다수 사용자 데이터베이스를 지원하지만 SQL Server CE가 단일 사용자 DBMS라는 것입니다.

SQL Server CE를 위해 만들어진 대부분의 응용 프로그램들은 두 가지의 사항들을 고려해야 할 것입니다: 연결이 끊어진 상태에서 데이터를 조작하는 것과 기계가 연결되었을 때 데이터를 SQL Server로 전송하는 것. 첫 번째는 SQL Server 데이터에 액세스하는 응용 프로그램을 만든 사람들에게는 매우 간단하고 잘 알려진 방법입니다. 두 번째, SQL Server와 SQL Server CE 사이의 데이터 이동은 단지 관련 데이터베이스 엔진 뿐만 아니라 Microsoft Internet Information Services(IIS)에 연관되어 있다는 것입니다. 데이터베이스 프로그래머들과 관리자들은 얼마나 데이터 조작이 친숙한지에 대하여 기뻐하게 될 것입니다. Windows CE 설치 장치의 데이터 조작과 데이터 이동은 나중에 보다 자세하게 다뤄질 것이지만, 간단한 소개가 여기에서는 적절합니다.

맨 위로


SQL Server CE 시작하기

SQL Server CE를 사용하는 응용 프로그램을 개발하기 위해서 여러분은 SQL Server CE를 다운로드 할 수 있는 라이센스가 함께 제공되는 SQL Server 2000 Developer Edition을 구매해야 합니다. 일단 여러분의 응용 프로그램이 배포될 준비가 되었으면, 여러분은 SQL Server 2000 Standard Edition이나 SQL Server 2000 Enterprise Edition이 필요할 것입니다.

SQL Server CE는 eMbedded Visual Basic®와 eMbedded Visual C++® 모두로 만들어지고 RND와 병합 복제 모두로 표현되는 몇 가지의 견본 응용 프로그램들과 함께 제공됩니다. 이것들은 훌륭한 견본들이고 여러분 자신의 응용 프로그램을 위한 시작점입니다.

모든 견본들과 마찬가지로 이것들도 몇 가지의 문제점들을 가지고 있습니다. 첫 번째는 일부 코드들이 C: 드라이브에 설지 되어야 하도록 고정되어 있습니다. 만일 여러분이 다른 드라이브에 설치를 할 경우 여러분은 그것에 따라서 코드를 수정하여야만 합니다. 또한 여러분의 특정 환경에 의해서 견본 응용 프로그램들에 의해 만들어진 그 연결 문자열이 정상적으로 작동하지 않을 수도 있습니다.

우리는 그 배합이 가장 많이 읽을 수 있는 코드를 생성하기 때문에 eMbedded Visual Basic과 ADOCE 3.1을 사용하여 이 기사의 견본들을 만들었습니다. 우리가 완전한 응용 프로그램을 제공하기 보다는 응용 프로그램 개발의 특정 요소들에 중점을 두었기 때문에, 우리의 견본 코드는 이미 제공된 견본들 보다 더 간단합니다.(보다 적은 에러 발생)

맨 위로


데이터 복제 요약

SQL Server CE 데이터베이스의 데이터를 복제하는 것은 단지 COM 개체 (ADOCE) 혹은 API (OLEDBCE)중 하나의 프로그래밍 구성 요소를 필요로 하기 때문에 간단합니다. 이들 구성 요소들은 그들의 데스크톱 사본들과 잘 어울립니다. 만일 여러분이 ADO 혹은 OLE DB를 사용하는 이미 만들어진 응용 프로그램들을 가지고 있다면, 여러분은 SQL Server CE를 액세스하는데 이미 앞서 있는 것입니다. SQL Server CE를 위한 프로그래밍은 SQL Server CE와의 SQL 언어 사용성이 SQL Server 2000과 SQL 이용성의 감소된 하위 세트이기 때문에 단순화되었습니다.(그리고 SQL Server 2000은 SQL Server 6.5 혹은 7.0에 제공되지 않은 SQL 문법을 포함하고 있습니다.)

맨 위로


연결성 살펴 보기

두 개의 다른 메카니즘들이 SQL Server CE와 SQL Server 사이에서 데이터를 옮기고 스키마하기 위해 제공되었습니다: RDA와 통합 복제. 이 두 가지들은 IIS와 연결되어 사용됩니다. SQL Server CE 기반 응용 프로그램의 가장 복잡한 부분은 일반적으로 SQL Server CE와 SQL Server 간의 데이터 전송입니다. 특히 만일 여러분이 여러분의 개발에서나 이미 개발된 IIS 기반 응용 프로그램들에서 복제를 사용해 본적이 없다면 더욱 그러합니다.

RDA와 통합 복제 모두의 디자인 이점들 중 하나는 이것들이 데이터만 옮기는 것이 아니라 스키마도 옮긴다는 것입니다. 이 전송은 전체 데이터베이스와 같이 광범위하거나 한 개의 테이블과 같이 세부적일 수도 있습니다. SQL Server 상에서의 이 스키마의 조절은 SQL Server에 존재하고, 대부분의 경우에 모든 SQL Server CE 기반 응용 프로그램들의 결론 데이터 정의 설명을 위한 필요를 제거할 것입니다.

RDA의 일차적인 이점은 장치에 적은 자취만을 남기고 감소된 기능들과 트래킹으로 보다 빠르다는 것입니다. RDA의 주요 불이익은 이것이 충돌 조절을 위한 적은 지원만을 제공한다는 것입니다. 통합 복제는 기존의 데이터베이스에 새로운 데이터가 동기화할 때의 충돌을 위한 규정들을 포함하여 데이터베이스 업데이트 규정들을 설립할 수 있도록 합니다. RDA는 모든 SQL Server 버전들을 지원하지만 통합 복제는 SQL Server 2000이어야만 가능합니다. 그림 2는 SQL Server의 다른 버전들을 위해 제공되는 데이터 복제 지원을 보여줍니다. 여러분이 사용하는 어떠한 데이터 이동 메커니즘이라도 기본 네트워크 프로토콜은 언제나 동일합니다: HTTP. ISAPI 확장 DLL을 사용하는 것은 SQL Server CE를 SQL Server에 연결하기 위한 유일한 방법입니다.

왜 SQL Server CE 팀이 이 IIS 기반 전선관을 선택했는지에 대한 좋은 이유들이 있습니다. 사용자 기본의 매우 중요한 세그먼트는 이동 사용자들로 구성될 것입니다. 그래서 연결성 옵션을 가능한 최대로 광범위하게 하는 것이 중요합니다. HTTP 연결성 주위에 SQL Server CE를 구축함으로 인터넷 연결을 통해 액세스를 취할 수 있는 누구나가 그들의 SQL Server 홈 월드에 연결할 수 있습니다. 광범위한 사용성과 함께, IIS 연결은 또한 사용자의 데이터가 기업 방화벽을 통과할 수 있도록 인증과 권한을 제공합니다.

데이터가 SQL Server CE와 SQL Server 간에 전송될 때, 여러분이 무료로 얻을 수 있는 훌륭한 기능들 중 하나가 압축입니다. 데이터는 Windows CE가 설치된 장치와 그 데이터가 보내지는 HTTP 사이트 사이에서 자동으로 압축됩니다. Northwind 데이터베이스를 사용하는 하나의 벤치마크에서의 압축율은 대략 8:1이었습니다. 압축은 언제나 가능하지만, 암호화 작업은 그렇지 않습니다. 여러분은 SQL Server CE와 서버를 가동시키는 IIS 사이에서 전송되는 데이터의 암호화는 IIS의 표준 암호화 성능 때문에 가능합니다. 이 모두가 IIS 기반이므로 암호화는 두 데이터베이스 엔진들에 모두 명확합니다.

도킹 크래들의 기존 포켓용 PC가 연결되는 컴퓨터에 시리얼(혹은 보다 나은 USB) 연결을 갖고 있다는 것을 지적하는 것은 중요한 일입니다. 만일 여러분이 HTTP 요청을 프록시 하기 위한 데스크톱 연결을 원한다면, 여러분은 Microsoft ActiveSync® 3.1이 직접 이것을 지원하지 않는다는 것을 알고 있어야 합니다. SQL Server CE 1.1은 데스크톱의 HTTP 요청을 IIS Server로 프록시하는 소프트웨어를 제공함으로 이 문제를 해결합니다.

맨 위로


연결성을 위한 도전

SQL Server CE를 사용하는 것에 대한 가장 어려운 점은 연결이 작동되도록 하는 것입니다. 왜 이러한지 그리고 여러분 자신의 응용 프로그램 개발 노력을 단순하게 하기 위해 여러분은 여러분이 이것과 직접 통신할 수 있는 OLE DB 드라이버가 없기 때문에 직접 SQL Server에 연결하는 Windows CE 기반 응용 프로그램을 만들 수 없다는 사실을 알 필요가 있습니다. 여러분의 응용 프로그램은 SQL Server CE가 데이터를 SQL Server에 전송할 수 있도록 해야 합니다.

SQL Server CE는 SQL Server로의 직접적인 연결을 열지는 않습니다. 그것 보다는 여러부느이 선택 URL에 위치한 ISAPI DDL 파일과 sscesa10.dll 파일에 엑세스하기 위해 HTTP를 사용하여 연결합니다. SQL Server에 연결을 만들고 데이터를 SQL Server에서 SQL Server로 전송하는 것이 DLL입니다. 데이터를 SQL Server CE에서 SQL Server로 옮길 때, 여러분은 중간 장치인 IIS에 의존해야만 합니다. 이것은 두 가지의 연결이 만들어 지고 있다는 것을 의미합니다; 하나는 Windows CE로부터 sscesa10.dll로 다른 하나는 sscesa10.dll에서 SQL Server로(그림3 을 보십시오).

IIS에 친숙한 사람들은 장치에서 IIS로의 연결이 Anonymous, Basic Authentication, 혹은 Integrated Windows Authentication 모드에서 만들어질 수 있다는 것을 알 것입니다; IIS에서 SQL Server로의 연결은 Windows Authentication 혹은 SQL Server Authentication 모드에서 만들어질 수 있습니다. 연결성과 보안성에 대한 이 모든 결과들은 여러분의 SQL Server CE 기반 응용 프로그램, 네트워크, 운영 시스템, IIS, NTFS, SQL Server 그리고 한개의 데이터 전송 방법일 경우에 공유 디렉토리를 연결합니다.

여러분은 여러분이 응용 프로그램을 코드 하기 전에 어디에 DDL들을 위치할지, 어디에 SQL Server를 지정할지 그리고 어떤 OS 사용자가 DDL과 SQL Server의 권리들을 실행할지 등과 같은 다수의 표준 웹 개발 문제점들에 직면하게 될 것입니다.

앞에서 언급한 바와 같이, IIS는 세 가지의 보안 컨텍스트들을 노출시킵니다. SQL Server CE는 두 가지(기본과 통합)만 사용할 수 있습니다. 인터넷 시나리오에서 IIS와 SQL Server 모두를 위한 통합 보안을 사용할 때, 두 서버들은 동일한 기기에서 작동해야만 합니다. 이것에 대한 이유는 NTLM이 기기들을 사이의 프록싱 보안 증명을 지원하지 않기 때문입니다. Kerberos는 Windows 2000에서 이것을 지원하지만, Windows CE는 현재 Kerberos를 지원하지 않습니다. 다른 웹 기반 응용 프로그램들과 마찬가지로 만일 Basic Authentication이 선택되었다면, Secure Sockets Layer (SSL)은 사용자 이름과 암호를 장치와 IIS를 작동하는 박스에 의해 판독되는 것을 방지하기 위해 사용되어져야 합니다.

맨 위로


Data Manipulation in Depth

SQL Server CE는 SQL Server 기능들의 하부 구조를 가지고 있습니다; 데이터베이스 엔진 또한 더 작습니다. 이것은 SQL Admin 서비스와 같은 기능을 제거함으로 가능했습니다. 관리자에게 에이전트, 작업, 경고, 연산자 혹은 스케줄이 없는 Windows CE의 서비스와 같은 것이 없었기 때문에 필수적인 일이었습니다. SQL Server CE가 단일 사용자 제품이므로 링크된 서버들이 없고, 파일 암호에 의해 보안성이 조절되기 때문에 GRANT, DENY, 혹은 REVOKE가 필요 없습니다. 또한 SQL Server's Transact-SQL 확장이 없습니다; 저장된 프로시저, 트리거, 복수 설명 배치, DECLARE, SET, IF, WHILE, 문자열 기능, 숫자 기능 및 닐라딕 (무인수) 기능들이 없습니다.

어쨌든, 데이터 기능들은 SQL Server CE에 존재합니다. 어떠한 표준 SQL은 제외되어야만 했습니다; 보기나 UNION이 없습니다. 모든 SQL Server 데이터 종류들이 포함되는 것은 아니지만 제외된 것들 대부분은 현재 존재하는 데이터 형태로 전환될 수 있습니다. 예를 들면, Windows CE는 단지 Unicode를 지원하기 때문에 NCHAR, NVARCHAR, NTEXT등과 같은 문자 데이터 형태들의 Unocode 버전만 지원합니다. CHAR 형태의 SQL Server 데이터는 SQL Server CE로 이동될 때 NCHAR로 전환됩니다. 우연하게 만일 여러분이 영어와 같은 ASCII기반 지역화를 사용하고 있다면, Unicode가 되어야 하는 모든 텍스트와 문자 데이터 형태들은 공간을 절약하기 위해 ASCII(UTF-8)로 압축될 것입니다. SQL Server CE를 위한 Unicode의 선택은 Windows CE 그 자체의 기본 문자 모음에 의해 결정된다는 점을 주의하십시오. ANSI와 Unicode 기능 호출(MessageBoxA 와 MessageBoxW) 모두를 지원하는 Windows NT와 Windows 2000과는 달리 Windows CE는 단지 Win32® 기능 호출의 Unicode 버전만이 사용 가능합니다 (MessageBoxW).

SQL Server CE가 제공하는 것들은 테이블, 색인, 기본값 및 관련 무결성입니다. 이것은 또한 표준 SQL Data Manipulation Language (DML)을 사용하는 테이블의 열들을 추가하고, 수정하고, 삭제하는 능력을 갖고 있습니다. 그러므로 여러분의 응용 프로그램은 resultset의 데이터를 수정하기 위해 데이터베이스 파일에 연결하여 데이터베이스에 SELECT, INSERT, UPDATE, 혹은 DELETE 명령을 포함하거나, recordset을 열어 다양한 recordset 메소드들을 ressultset의 데이터를 수정하기 위해 사용함으로 SQL Server CE의 데이터를 복제할 수 있습니다. 여러분의 SQL Server CE 기반 응용 프로그램은 기존의 SQL Server 응용 프로그램에 의해 여러분이 기대했던 것보다 더 기초적일 수 있지만, 이동 중인 경우에 이것은 유용하게 사용될 수 있는 충분한 기능을 제공할 것입니다. 완전한 Transact-SQL syntax의 부족은 기존 Windows CE가 설치된 장치의 사용 가능한 메모리의 필수적인 한계입니다. 그리고 아직 이 크기의 한계에 대하여 SQL Server CE는 여러분이 필요로 할 수 있는 Windows CE 기반 응용 프로그램에 대해 충분하게 충족시키는 SQL 명령들의 모음들을 제공합니다.

두 개의 프로그래밍 개체 모델들이 SQL Server CE 데이터베이스를 위해 존재합니다: ADOCE와 ADOXCE. ACOXCE 개체는 만들기, 수정하기, 그리고 데이터베이스, 테이블 및 색인을 제거하기와 같은 데이터베이스 정의 언어 (DDL) 실행들을 위하여 사용됩니다. 우리는 세 가지의 이유로 ADOXCE를 이 문서에서 다루지 않습니다. 첫 째, ADOXCE 개체들은 유지 관리 중심입니다(데이터 조작 중심과 반대). 둘 째, 여러분이 ADOXCE로 할 수 있는 대부분의 것들은 또한 ADOCE를 사용하여 할 수 있습니다. 셋 째, 대부분의 SQl Server CE 데이터베이스 정의와 만들기는 RDA 혹은 복제에 의해 이뤄집니다. 만일 여러분이 ADOXCE에 관심을 가지고 있다면, 여러분은 몇 가지의 견본 응용 프로그램들을 SQL Server 다운로드에서 찾으실 수 있습니다.

ADOCE 개체들은 SQL Server CE 데이터베이스에 연결하고 SQL 명령들을 받고 실행하기 위한 응용 프로그램에 의해 사용됩니다. 그 이름에서 알 수 있듯이 이 개체 모델은 ADO 개체 모델과 유사합니다; 이것은 MoveNext, EOF 및 Execute와 같은 속성과 메소드들과 함께 Connection과 Recordset과 같은 개체들을 포함하고 있습니다.

맨 위로


지원된 SQL

ANSI표준 SQL 언어는 세 부분으로 나누어 집니다; DDL, DML 및 Data Control Language (DCL). ADOCE 개체들은 보통 네 가지의 명령들을 실행하기 위해 사용됩니다: 선택하기, 삼입하기, 업데이트 하기 그리고 삭제하기. 어쨌든, 앞에서 언급한 바와 같이 이것들은 또한 세 가지의 명령들을 실행하기 위해 사용될 수 있습니다: 만들기, 수정하기 그리고 삭제하기. 이 방법으로 ADOCE는 ADOXCE가 할 수 있는 것들 보다 더 많은 것들을 할 수 있고, 대부분의 개발자들은 ADOXCE를 알려고 하지도 않고 ADOCE에만 치중합니다. ADOCE는 이 동사들이 SQl Server CE에 존재하지 않기 때문에 세 가지의 DCL 명령들을 실행하는데 사용될 수 없습니다: 승인하기, 거절하기 및 해지하기.

SQL Server CE 데이터베이스에 연결하기 위해서, 여러분의 응용 프로그램은 연결 개체와 연결 문자열을 필요로 합니다. SQl Server CE 데이터베이스로의 연결을 만들기 위해서 필요한 정보의 두 가지 명령은 제공자 이름과 데이터베이스 파일 이름이기 때문에, 연결 명령줄과 코드 모두는 만들기 쉽습니다. 예를 들면:

Dim refConn As ADOCE.Connection
Set refConn = CreateObject("ADOCE.Connection.3.1")
refConn.Open
"Provider=Microsoft.SQL Server.OLEDB.CE.1.0; " & _
"Data Source=Northwind.sdf"
일단 데이터베이스로의 연결이 열리면, 데이터 변경 명령은 다음 세 가지 조각들 중 하나와 유사하게 보일 수 있습니다:

refConn.Execute "DELETE Categories WHERE CategoryID = 3"
refConn.Execute "INSERT Categories " & _
"(CategoryName, Description) " & _
"VALUES ('Taco', 'Fast Food')"
refConn.Execute "CREATE TABLE MyTable (" & _
" PKCol int not null IDENTITY PRIMARY KEY, " & _
" AttrCol nvarchar(100) not null DEFAULT 'NA')"
일단 데이터베이스로의 연결이 열리면, 데이터 변경 명령은 다음 세 가지 조각들 중 하나와 유사하게 보일 수 있습니다:

refConn.Execute "DELETE Categories WHERE CategoryID = 3"
refConn.Execute "INSERT Categories " & _
"(CategoryName, Description) " & _
"VALUES ('Taco', 'Fast Food')"
refConn.Execute "CREATE TABLE MyTable (" & _
" PKCol int not null IDENTITY PRIMARY KEY, " & _
" AttrCol nvarchar(100) not null DEFAULT 'NA')"
recordset을 만드는 명령을 제안하기 위한 코드는 다음과 같이 보일 수 있습니다:
Dim refRS As ADOCE.Recordset
Set refRS = refConn.Execute("SELECT * FROM MyTable")
recordset을 실행하기 위한 루프는 다음과 같이 보일 수 있습니다:
Do Until refRS.EOF
Print refRS.Fields(0) & " : " & refRS.Fields(1)
refRS.MoveNext
Loop
결과적으로 정리를 위한 코드는 다음과 같이 보일 수 있습니다:
refRS.Close
Set refRS = Nothing
refConn.Close
Set refConn = Nothing

맨 위로


복제

이전에 언급한 바와 같이, SQL Server CE 기반 응용 프로그램들은 한 개 혹은 두 개의 메카니즘을 사용하는 SQL Server와 SQL Server CE간의 데이터를 전송합니다: SQL Server의 통합 복제 혹은 RDA. RDA는 SQL Server CE가 SQL Server의 이전 버전들(즉, 버전 6.5와 7.0)에서 가동될 수 있도록 혹은 통합 복제를 설정하지 않고자 하는 관리자들을 위해 고안되었습니다.

만일 여러분이 이미 통합 복제에 대해 알고 있다면, RDA를 설명하기가 쉬워짐으로 SQL Server의 통합 복제부터 설명을 시작하겠습니다.

맨 위로


통합 복제

복제 작업을 해본 분들은 사전 계획과 디자인이 중요하다는 것을 알고 있습니다. 첫 번째로 복제를 시도하면, 사람들은 종종 두 장소에 동시에 존재하는 데이터를 유지하는 것이 간편한 작업이라고 생각합니다. 하지만, 복제에 관련된 복잡함의 단지 두 가지 경우를 생각해 보십시오.

첫 번째 경우는 SQL Server가 트리거를 호출하는 기능을 제공하는 것입니다; TableX의 변화는 자동적으로 TableY에도 변화를 초래할 것입니다. 하지만, SQL Server CE는 트리거를 지원하지 않습니다. 만일 TableX와 TableY가 SQl Server CE 데이터베이스에 복제되었다면, TableX의 변화는 TableY에 자동적인 변화를 초래하지 않을 것입니다. 그와 같이 동일한 테이블(TableX)에서 실행된 문서를 사용하는 것은 다른 결과를 만들 것이고, 테이블은 더이상 동시에 존재하지 않을 것입니다. 그러므로 SQL Server로부터 트리거 논리를 SQL Server CE측의 응용 프로그램 코드에 복사하는 것은 중요합니다.

또 다른 경우는 만일 여러분이 외부 키를 갖고 있는 테이블을 복제한다면, 여러분은 외부 키 테이블에 삽입된 줄을 유효화시키는 것 뿐만 아니라 기존 키 테이블을 복제해야 합니다. 아마도 여러분은 Delivery Route West92을 위한 열과 같은 외부 키 테이블의 열 만을 복제하고자 할 것입니다. 여러분은 단지 Delivery Route West92에 관련된 일차적인 키 테이블 (Product 테이블)의 열만을 복제하면 되지만, delivery route 코드는 Product 테이블의 칼럼이 아닙니다. 이 조작은 강화된 관계에 관련된 모든 테이블들을 게시하는 것에 의해 이루어질 수 있지만, 또한 게시 정의에 관계된 테이블의 공동 필터에 의해 지원받는 수평 필터를 추가함으로 이루어질 수 있습니다.

여러분이 이러한 것들을 고려한 후에는 통합 복제를 매우 돋보이게 하는 통합 복제와 RDA 사이의 주요 차이점들이 있습니다. 여러분이 곧 볼 수 있겠지만, RDA는 설정이 간편하고 통합 복제보다 더 많은 코드에 충분하게 연관되어 있습니다. 통합 복제는 장치에 분산된 논리를 갖는 것 보다는 응용 프로그램의 논리에 대한 보다 많은 서버 조절 능력을 제공합니다. 예를 들면, 한정된 IDENTITY 칼럼과 동적 수평 부분들은 장치가 아닌 서버에 존재하는 논리의 두 가지 주요 예제들입니다. 이것은 충분하게 장치의 코드 양을 줄일 수 있고 응용 프로그램 유지 관리가 장치 보다는 서버에서 수행될 수 있도록 할 수 있습니다.

여러분이 SQL Server CE 기반 응용 프로그램에 사용하려고 하는 것을 포함하여 어떠한 복제 구성표도 잘 계획되고 디자인되어야만 합니다. 그러므로 우리는 SQL Server의 통합 복제의 기본 개념을 잠시 살펴보도록 하겠습니다.

SQL Server CE 기반 응용 프로그램에서 사용되는 것처럼 통합 복제에서 SQL Server는 한 개 혹은 그 이상의 데이터베이스에서 한 개 혹은 그 이상의 정의된 게시물들을 갖고 있는 Publisher와 같이 연관되어 있습니다. SQL Server CE 데이터베이스 들은 Subscribers와 같이 연관되어 있습니다. 게시물들은 테이블, 칼럼 및 필터들의 정의된 모음으로 구성되어 있습니다. 이들 선택된 테이블들은 Articles of a Publication과 같이 연관되어 있습니다; 그리고 "only columnA, columnB, columnC of TableX" or "only those rows of TableY where route code equals 'West92'"와 같은 하위 집합의 정의는 필터와 같이 연관되어 있습니다. 필터들은 여러분이 앞의 문장에서의 첫 번째 예와 같이 테이블의 수직 하위 구조를 복제 하거나 두 번째 예와 같은 테이블의 수평 하위 구조 혹은 두 가지 모두를 복제할 수 있도록 합니다.

Subscriptions는 SQL Server에 정의된 바와 같이 게시물들의 개념에 직접 연결되어 있습니다. eMbedded Visual Basic혹은r eMbedded Visual C++기반 으용 프로그램은 데스크톱의 통합 클라이언트를 위한 subscription을 관리할 때 정의된 동일한 메소드와 등록 정보를 사용하여 subscription을 만들기 위해 SQL Server CE ActiveX® 조절을 사용합니다.

초기 동기화를 위한 코드의 예들이 그림 4에 나타나 있습니다. 재 동기화를 위한 코드도 거의 비슷합니다.(그림 5를 보십시오). 초기 동기화가 이미 완료되었으므로, AddSubscription 메소드 호출은 필요 없습니다. 개체 속성 값들은 그림 4에 나타난 것과 같습니다; 하지만, 설명의 숫자는 코드 견본을 보다 작게 만들기 위해 축소되었습니다.

그림 4그림 5는 세 가지를 나타내고 있습니다. 첫 째, 프로그램으로 복제를 실행하는 것은 개체를 만들고, 몇 가지의 등록 정보를 설정하고 그리고 세 가지의 메소드들(데스크톱에서 실행된 것과 같은 Unitialize, Run 그리고 Terminate)을 호출하는 것을 연루 시킵니다. 둘 째, 초기 동기화를 할 때, SQL Server CE 데이터베이스틑 자동으로 생성됩니다. 셋 째, 적절하게 IIS Server를 구성하는 것과 같은 연결성 문제들은 위에서 언급한 바와 같이 어떻게 여러분이 여러분의 응용프로그램을 코드할 것인지에 영향을 끼칩니다.

우리는 이 여결성 문제들을 지금 다루고, 몇 전형적인 응용 프로그램 시나리오들을 실험할 것입니다. SQL Server CE Books Online에서 찾을 수 있는 세부 사항들을 재차 다뤄지지 않습니다. 우리는 적절한 Books Online 내용들을 참조함으로 높은 수준의 SQL Server CE 기반 응용 프로그램에서 IIS로 그리고 SQL Server로의 연결을 다룰 것입니다. 그리고 나서, 우리는 각각의 시나리오를 실험하며, 하나 하나를 구현하는 세부 사항들을 살펴볼 것입니다. 통합 복제와 RDA 모두가 sscesa10.dll을 통해 SQL Server로 연결되므로, 여기에 포함된 거의 모든 내용들은 RDA 프로그래밍에 적용될 수 있습니다.

SQL Server CE에서 IIS로 그리고 SQL Server로의 연결을 위해서 여러분은 다음 사항들을 수행해야만 합니다:
  1. 그 응용 프로그램을 위해 IIS를 가동하는 서버의 가상 디렉터리를 만드십시오. 프로그램 파일을 IIS에서 만들어진 가상 디렉터리에 설치하기 위해 SQL Server CE 서버측 설치 프로그램을 선택하십시오. (SQL Server CE Books Online의 "IIS 구성하기"를 보십시오)

  2. 만일 이것들이 없다면, 응용 프로그램 하나 하나를 위한 운영 시스템 사용자와 그룹을 추가하십시오. (User Manager for Domains in Windows NT와 같은 OS의 사용자 관리 클라이언트 도구를 사용하십시오.) 이 작업은 일반적으로 네트 워크 관리자에 의해 이뤄집니다.

  3. SQL Server 로그인과 같은 OS 사용자와 그룹을 추가하고 그것들을 위해 필요한 데이터베이스 승인을 지정하십시오. (SQL Server Enterprise Manager 클라이언트 프로그램. 이것은 일반적으로 SQL Server 관리자에 의해 이뤄집니다.)

  4. 만일 여러분이 통합 복제를 사용하고 있다면, SQL Server를 업그레이드하고 SQL Server CE와 작업하기 위해 저장된 프로시저를 실행하십시오. 이것은 다음 SQL Server의 Service Pach 버전에서는 필요하지 않을 것입니다. (SQL Server CE Books Online의 "SQL Server System Stored Procedures 업데이트 하기"를 보십시오.)

  5. 만일 여러분이 통합 복제를 사용하고 있다면, IIS가 액세스할 수 있도록 스냅샷 파일들이 저장될 디렉터리에 읽기 권한을 지정하십시오. 이 단계는 단지 여러분이 NTFS를 사용하는 경우에만 해당됩니다. FAT(32)에는 이것이 이뤄 지지 않았습니다.(사실 이뤄질 수 없습니다) (그 디렉터리에 NTFS 액세스 승인을 허용 하는 것은 독립적으로 이뤄 져야 합니다).

  6. 만일 여러분이 통합 복제를 데이터 전송 메카니즘과 같이 사용하고 있다면, SQL Server publications를 만드십시오.
이제 몇 개의 전형적인 응용 프로그램 시나리오들을 실험하고 어떻게 하나 하나를 구현하는지 보도록 하겠습니다.

맨 위로


시나리오 1: 공용 데이터로의 읽기 전용 액세스

여러분의 Windows CE 기반 응용 프로그램은 원래 공용인 SQL Server 데이터의 읽기 전용 액세스를 할 것입니다. 여러분은 데이터로의 특유의 액세스를 제공할 필요가 있지만, 그 액세스를 트랙할 필요는 없습니다.

익명의 사용자가 기본 사용자 계정과 IUSR 기계명을 통해 액세스할 수 있도록 IIS 가상 디렉터리 등록 정보를 구성하십시오.

그림 6은 어떻게 이것이 Northwind 데이터베이스를 위한 Windows 2000에서 이뤄질 수 있는지를 보여줍니다.


그림 6 익명의 사용자 액세스를 가능하게 하기


SQL Server Windows Authenticated 로그인과 같이 ISUR 기계명을 추가하고 공용으로 사용될 데이터를 읽기 전용으로 만드십시오.

그림 7은 SQl Server 인증 구성 속성 시트에 부여되는 승인들을 보여줍니다.

NT_AUTHENTICATION에 PublisherSecurityMode 속성 값을 설정함으로 sscesa10.dll에서 SQL Server로의 연결을 위한 Windows Authentication 모드를 명확하게 하기 위한 클라이언트 응용 프로그램에 코드를 추가하십시오. 이것에 대한 견본이 이곳(그림 5에서 발췌)에 제시됩니다:

Attribute VB_Name = "ReplWindowsAuth"
' Declare and create the SQL Server CE Replication Object.
Dim refRepl As SSCE.Replication
Set refRepl = CreateObject("SSCE.Replication.1.0")
ooo
' Instruct sscesa10.dll to connect to SQL Server using
' Windows Authentication.
refRepl.PublisherSecurityMode = NT_AUTHENTICATION
이제 언제라도 Windows CE 기반 응용 프로그램이 DDL에 연결되면, DDL은 IUSR 기계명으로 작동되고 SQL Server에 IUSR 기계명으로 연결할 것입니다. 이것은 응용 프로그램에게 어떠한 SQL Server 로그인 정보도 서버에 에공할 필요 없이 IUSR 기계명이 액세스할 수 있는 모든 데이터로의 액세스를 제공합니다.

맨 위로


시나리오 2: 개인 데이터로의 읽기 전용 액세스

이 시나리오에서, 여러분의 Windows CE 기반 응용 프로그램은 응용 프로그램에 개인적인 SQL Server 데이터로의 읽기 전용 액세스를 갖게 될 것입니다. 여러분은 응용 프로그램이 특정한 정보를 액세스할 수 있게 되기를 바랄 수도 있지만, 어떠한 사용자도 그들이 응용 프로그램을 이렇게 사용하지 않는 한은 그 정보에 액세스할 수 없을 것입니다.

이 것을 위해서는 읽기 전용 데이터 액세스를 시도할 때 응용 프로그램에 의한 사용을 위해 OS 사용자 혹은 그룹을 추가하십시오. 여러분은 로컬 사용자와 그룹들을 만들고 관리하기 위해 사용하는 일반 관리 도구들을 사용하여 이것을 할 수 있습니다.(Windows 2000에서 이 화면을 위한 경로는 다음과 같습니다: Control Panel | Administrative Tools | Computer Management | Local Users and Groups. Windows NT 에서의 경로는 훨씬 더 간단합니다: Start | Programs | Administrative Tools | User Manager for Domains).

IIS 가상 디렉터리 등록 정보가 이 사용자를 통한 익명의 액세스를 할 수 있도록 구성하십시오. 이것의 예는 그림 8에 나타나 있습니다. 그리고 나서, 사용자를 SQL Server Windows Authenticated 로그인으로 추가하고 응용 프로그램 데이터의 액세스를 읽을 수 있도록 허용하십시오 (그림 7을 다시 보십시오).


그림 8 익명 사용자 계좌

이전의 시나리오에서와 마찬가지로, NT_AUTHENTICATION에 PublisherSecurityMode 속성 값을 설정함으로 sscesa10.dll에서 SQL Server로의 연결을 위한 Windows Authentication 모드를 지정하도록 하기 위해 Windows CE 기반 응용 프로그램을 코드하십시오.

이 두 시나리오들은 SQL Server CE에서 IIS로의 연결을 위한 익명의 액세스를 사용합니다. 이것은 sscesa10.dll이 클라이언트 응용 프로그램에 의해 제공된 추가적인 정보에 상관 없이 특정 사용자를 실행하도록 할 것입니다. 앞서 말한 바와 같이 틀라이언트 응용 프로그램을 실행하는 사용자의 ID는 SQL Server 데이터로의 액세스를 조절하는데 사용될 수 없습니다. 이 경우는 일반적으로 읽기 전용 환경에 적용되지만, 데이터가 응용 프로그램에 의해 변경되고 있을 때에는 바람직하지 않습니다.

맨 위로


시나리오 3: 개인 데이터로의 읽기/쓰기 액세스

여러분의 응용 프로그램은 그것에 개별적인 SQL Server 데이터를 액세스하고 업데이트할 필요가 있습니다. 수정은 사용자별 기준으로 추적되어야 합니다. 예를 들면, 여러분은 어떠한 드라이버가 어떠한 배달 기록을 만들었는지를 알아야 할 것입니다.

OS 설정은 매우 직접적입니다. OS 사용자를 추가하십시오.(아마도 각각의 드라이버에 하나씩). 각각의 응용 프로그램 클래스에 한 OS 그룹을 추가하십시오. 마지막으로, 그 사용자들을 그들의 그룹에 추가하십시오.

IIS 보안측의 경우에는 보다 헷갈릴 수 있습니다. 첫째로, IIS 가상 디렉터리 등록 정보를 Integrated Windows Authentication 혹은 Basic Authentication 어디에서도 익명의 액세스를 승인하지 않도록 구성하십시오. 응용 프로그램을 상호 작용하기 위한 가장 좋은 Integrated Windows Authentication은 Windows CE 3.0 그리고 보안 네트워크 환경을 필요로 합니다; Basic Authentication은 Internet 응용 프로그램들에 보다 적합하고, 사용 가능성이 높습니다. 만일 여러분이 Integrated Windows Authentication에서 문제점들에 직면한다면, Basic Authentication을 사용해 보십시오. 여러분은 그림 9에서 이것을 설정할 때 어떠한 화면이 나오는지 볼 수 있습니다.


그림 9 Basic Authentication

최종 설정 단계는 앞에서와 마찬가지로 SQL Server 액세스와 관련이 있습니다. OS 그룹을 SQL Server Windows Authenticated 로그인으로 추가하고 응용 프로그램의 데이터로의 액세스를 승인하십시오.

Windows CE를 실행하는 장치에서는 sscesa10.dll로부터 SQL Server로의 연결을 위한 Windows Authentication 모드를 지정하고 보안 컨텍스트를 지정하도록 응용 프로그램을 코드 하십시오. 일반적으로 여러분은 응용 프로그램을 실행하는 사람의 OS 사용자 이름과 암호를 사용하게 될 것입니다. 이것은 SQL Server로의 연결의 ID 뿐만 아니라 sscesa10.dll 실행 ID입니다. 그림 10에서 여러분이 작성에 필요한 코드의 예를 볼 수 있습니다. 여러분은 그 그룹의 모든 OS 사용자들이 SQL Server에 연결할 수 있도록 하기 위해 SQL Server에 한 개의 로그인 만(OS 사용자 그룹에 속한)을 추가해야 합니다. 단지, 그룹명 만이 로그인에 추가될지라도, SQl Server는 각각의 사용자 이름으로 연결 작동을 추적할 수 있습니다.

맨 위로


원격 데이터 액세스

앞에서 언급한 바와 같이, SQL Server CE와 SQL Server 사이에서 데이터를 옮기기 위한 두 번째 매서드는 Remote Data Access입니다. RDA의 설정이 보다 단순하기 때문에 특히 통합 복제에 기본적으로 갖추고 있는 기능들(예를 들면, 한정된 ID 열과 동적 수평 파티션들)을 복제하고자 할 때 대체로 보다 많은 코드가 필요할 수도 있습니다. 가장 큰 이점은 이것이 SQL Server CE를 실행하는 장치가 SQL Server의 이전 버전들(SQL Server 6.5와 SQL Server 9.0)에 연결될 수 있도록 한다는 점입니다. 단지 SQL Server 2000만이 통합 복제를 지원합니다. RDA는 SQL Server CE 기반 응용 프로그램이 아래의 사항을 할 수 있도록 합니다:
  • 데이터를 SQL Server CE에 옮길 필요 없이 SQL Server 데이터를 직접 수정합니다.
  • 데이터를 SQL Server로 부터 SQL Server CE 테이블로 SELECT 명려을 가져옵니다.
  • 데이터를 SQL Server CE 테이블로부터 유사한 SQL Server 테이블로 보냅니다.
SQL Server CE를 위한 대부분의 RDA 프로그래밍은 프로그래밍 개체인 하나의 RDA 개체를 사용합니다. 이 개체는 SubmitSQL, Pull, 그리고 Push와 유사한 세 가지 메소드들을 가지고 있습니다. 이것은 연결 정보의 제공과 에러 관리를 위한 속성 모음을 가지고 있습니다. 예를 들면, Pull 메소드는 SELECT 명령이 SQL Server에서 실행되도록 지정합니다. SQL Server CE의 테이블의 이름은 데이터, SQl Server 연결 문자열을 매개 변수로 수신할 것입니다.

맨 위로


SubmitSQL

SubmitSQL 메소드는 프로세싱을 위해 SQL Server로 돌아오지 않는 SQL 설명을 완벽하고 간단하게 제출하는 SQL Server CE를 우회합니다. 예를 들면, 그림 11의 코드는 sscesa10.dll이 SFD00 SQL Server에 위치한 Northwind 데이터베이스로의 Windows Authenticated 연결을 지시하고 Region 테이블에 행을 삽입합니다.

만일 여러분이 통합 복제 개체와 사전에 작업을 해보았다면, InternetURL, InternetLogin, 및 InternetPassword와 같은 InternetXxx 등록 정보들과 친숙할 수도 있습니다. 새로운 것은 연결 문자열인 SubmitSOL의 두 번째 매개 변수입니다. 역시 연결 문자열 매개 변수를 가지고 있는 나머지 두 개의 RDA 메소드들을 실험한 후에 더 자세하게 다루도록 하겠습니다.

맨 위로


Pull과 Push

Pull은 SubmitSQL와 유사합니다; 이것은 SQL 설명을 프로세싱을 위한 SQL Server에 처리합니다. 하지만, 이 문자열은 행들을 반환해야만 합니다. 이 열들을 수용하기 위한 SQL Server CE 테이블은 지정되어야만 하고 또한 테이블은 사전에 만들어진 것일 수 없습니다.

예를 들면, 그림 12의 코드는 Northwind Categories 테이블로부터 정보를 가져와서 Northwind.adf의 SQLCETargetTable 이라는 테이블에 저장합니다.

Pull 메소드를 이해하기 위해서 여러분은 RDA의 변화 추적 기능을 이해해야 합니다. Pull 메소드가 SQL Server로부터 행을 검색하기 위해 사용될 때, TRACKINGON 매개 변수가 지정될 수 있습니다; on 상태일 때, 가져온 행들의 후속적인 변화들이 추적됩니다. 통합 복제와 같이 이 추적은 가져온 테이블의 몇 가지 정보가 필요합니다. 이것이 왜 새로운 SQL Server CE 테이블이 SELECT 설명 보다 더 많은 칼럼들을 가지고 있는지에 대한 이유입니다. Pull 메소드가 새로운 테이블에 각각의 행을 위한 추적 정보와 함께 행들을 가져다 놓으면, 여러분은 이제 그 행들이 SQL Server 소스 테이블을 추적할 수 있는 그 행들을 갖고 있는 SQLl Server CE 테이블을 가지게 됩니다. Push 메소드는 Pull이 SQl Server 데이터베이스에 실행된 때부터 만들어진 모든 변화를 통과하기 위해 이것에 의존하고 있습니다.

예를 들면, 그림 13의 코드는 Pull이 실행된 이후에 SQL Server CETargetTable에 만들어진 모든 변화를 업로드할 수 있습니다. 이것은 Pull 대신에 Push를 사용하는 경우를 제외하고 그림 12의 코드에도 동일합니다.

모든 세 가지 RDA 메소드들은 연결 문자열 매개변수를 필요로 합니다. 모든 SQL Server 클라이언트 응용 프로그램은 이 동일한 연결 문자열을 제공해야만 합니다. 이것은 공급자 이름, 연결 모드, 서버 이름, 데이터베이스 이름 , (추가적으로) 로그인 이름 및 암호를 지정합니다. 여러분이 SQL Server 클라이언트를 만들도록 하는 Visual Basic 6.0과 같은 대부분의 개발 환경은 여러분을 위해 연결 문자열을 생성하는 Data Environment와 같은 도구들을 제공합니다. 이들은 견본 문자열들을 생성하고 각각의 공급자를 위한 구문을 배우기 위한 가장 좋은 방법입니다.

모든 세 가지의 RDA 메소드들에 이 매개 변수의 존재는 SQL Server CE 처리의 연결되지 않은 metaphor를 재확인합니다. 모든 메소드는 연결을 하고 작업을 수행하고 연결을 끊을 수 있도록 SQL Server 연결 문자열 매개 변수의 지정을 필요로 합니다. Pull과 Push 사이의 SQL Server CE에서 생긴 변화는 SQL Server CE 데이터베이스가 연결되지 않았을 때 생깁니다.

맨 위로


Choosing RDA or Merge Replication RDA 혹은 통합 복제 선택하기

중요한 디자인상의 문제는 두 개의 연결 솔루션 중 어떤 것을 사용할 것인지 제시해야 한다는 것입니다. 만약 SQL Server 6.5 혹은 7.0으로 작업을 해야 한다면 선택하기가 쉽습니다. merge replication이 지원되지 않기 때문에 RDA를 사용해야 합니다. 하지만 SQL Server 2000에서는 두 가지 메소드 중 아무 것이나 사용해도 됩니다.

가장 큰 차이점은 통합 복제가 데스크톱 데이터와 SQL Server CE 데이터의 관계를 단정적으로 지정할 수 있게 해주고 RDA는 전송될 데이터를 정의하기 위해 SQL 코드를 작성해야 한다는 점입니다. 그러므로 통합 복제에서는 중앙 데이터 저장소가 데이터의 움직임을 제어하는 반면에 RDA에서는 Windows CE로 작동되는 장치가 제어를 할 수 있게 합니다.

초기에는 RDA가 더 나은 선택으로 보일 수도 있습니다. 여러분은 단지 SELECT 설명을 코딩하고 PULL 메소드를 사용하면 됩니다. 이렇게 되면 SQL Server CE는 테이블을 만들고 선택된 데이터를 테이블 내로 전송합니다. Replication을 설정할 필요는 없습니다.

간단하거나 일회적인 응용 프로그램에서는 그러할 수도 있습니다. 하지만 주 응용 프로그램에서는 아마도 통합 복제가 더 좋은 방법일 것입니다. 통합 복제는 RDA에서는 볼 수 없는 기능들을 제공하기 때문입니다. 아까 명시했던 충돌 해결이 이들 기능 중 하나입니다. 또 다른 기능은 한정된 ID 칼럼이며, 이는 ID 칼럼 값이 회사 전체의 SQL Server CE 데이터베이스에서 자동으로 지정되게 해 줍니다. 이 때 이러한 행들이 SQL Server 데이터베이스로 업로드될 때의 충돌에 대한 걱정을 할 필요는 없습니다. 동적 수평 파티션 또한 통합 복제에서 사용 가능한 매우 유용한 내장 기능성의 한 예입니다.

RDA에는 포함되어 있지 않은 이러한 단정적인 능력은 RDA 응용 프로그램으로 수동 코딩을 하기가 매우 어렵습니다. 회사 응용 프로그램 개발에 더 심도 있게 들어가면 갈수록 통합 복제의 필요성은 커지게 됩니다. 훌륭한 복제 시나리오가 시작될 때 생각, 계획, 디자인을 필요로 하긴 하지만 이로 인해 코드가 줄어든다는 것을 생각하면 본격적인 응용 프로그램을 만들 때 도움이 될 것입니다.

맨 위로


오류 해결

다른 SQL Server들처럼 SQL Server CE의 프로그래밍 개체도 오류 정보를 오류 모음 형식으로 나타냅니다. SQL Server CE에 연결하기 위해 ADOCE 개체가 사용된 경우, 오류 모음은 Connection 개체에 존재합니다. ISAPI DLL로 SQL Server에 연결하기 위해 SQL Server CE 개체가 사용된 경우, RemoteDataAccess 개체와 Replication 개체에 오류 모음이 존재하고 Error보다는 ErrorRecords로 이름이 붙여집니다.

ADO 프로그래밍처럼 메소드 호출에서 생기는 실패는 오류 모음에 한 개 이상의 오류 개체를 더하고 Visual Basic 오류 같은 표준 오류를 증가시킵니다. 오류의 오류 모음을 시작하고 사용자에게 정보를 보여줌으로써 해결됩니다.

두 가지 요인 때문에 SQL Server CE의 오류 취급은 SQL Server의 오류 해결보다 어렵습니다. 우선, eMbedded Visual Basic은 Visual Basic과는 다른 오류 해결 능력을 가지고 있습니다. eMbedded Visual Basic의 오류 해결은 ASP 페이지의 VBScript에 사용 가능한 기능들과 관련시키는 것이 가장 쉽습니다. 둘째로, footprint를 작게 유지하기 위해 SQL Server CE는 오류 문자열이 없습니다. 대신에 오류 번호만을 제공하며, 이를 지원하는 Books Online에서 번호를 찾아서 테스트 메시지를 보아야 합니다.

그러므로 만약 여러분의 응용 프로그램이 SQL Server 데이터베이스에 ADOCE 연결이 되어있는 상태에서 데이터를 SQL Server 데이터베이스로 SQL Server CE Pull 하려고 하면 예기되는 메시지인 "Cannot open multiple connections to the same database" 같은 메시지 보다는 지정되지 않은 오류 메시지를 수신하게 됩니다.

SQL Server CE의 오류 해결에 있어서 두 번째로 어려운 점은 개발 환경의 제한입니다. 예를 들어 eMbedded Visual Basic은 Visual Basic에는 있는 오류 trapping 능력을 가지고 있지 않습니다. eMbedded Visual Basic은 오류 발생시 특정한 줄로 가지 못하게 합니다.

여러분이 가지고 있는 On Error 옵션은 Go To 0과 Resume Next 뿐이기 때문에 eMbedded Visual Basic은 VBScript와 더 비슷합니다. 여러분의 응용 프로그램이 해결해야 하는 오류를 접했을 때, 다음 과정을 따라야 합니다:
  1. 오류 검색을 꺼야 합니다.
  2. SQL Server CE 메소드를 호출해야 합니다.
  3. 오류가 있는지 테스트해야 합니다.
  4. 오류가 생겼을 경우에는 오류 모음을 검토해야 합니다.
  5. 오류 검색을 켜야 합니다.
이에 대한 예제는 그림 14에 나와 있습니다.

여러분의 응용 프로그램은 메소드를 호출하기 전에 정상 오류 검색을 꺼야 합니다. 이 정상적인 오류 검사가 프로그램의 실행을 멈추기 때문입니다. eMbedded Visual Basic에서의 오류 해결은 지금까지 프로그래밍해 보셨던 환경들보다 더 제한되어 있습니다. 하지만 당장 필요한 작업에는 적합합니다.

맨 위로


결론

Windows 데스크톱에 SQL 응용 프로그램을 만들어본 경험이 있는 개발자는 SQL Server 2000 WIndows CE Edition에서 옛날에 익숙했던 점들을 많이 발견하실 수 있을 것입니다. SQL 데이터베이스 설명과 ADOCE, OLEDB CE 프로그래밍 인터페이스 같은 옛 standby의 호스트가 있어 이것들로 함께 작업하실 수 있습니다. 새로운 기능은 이동 데이터를 중앙 데이터 저장소에 병합할 수 있도록 SQL Server CE가 제공하는 연결성 모델입니다. 내장된 웹 응용 프로그램을 가지고 있는 개발자들은 여기서 익숙한 점을 많이 찾아보실 수 있을 것입니다. 이 제품이 제공하는 것은 데이터의 이동 사이의 움직임을 관리할 수 있는 high-power, 고객 지향의 데이터베이스 엔진이고, 연결된 장치와 데이터 저장소까지 제공될 수 있습니다. 그리고 물론 이 제품은 독립 데이터베이스로서 아주 잘 실행될 수 있습니다.

맨 위로


Paul Yao는 Windows 프로그래밍 guru, Windows CE 전문가이며 Windows 프로그래밍에 대해 처음 출간된 책의 공동 저자입니다. 그의 회사는 프로그래머들에게 Windows와 Windows에 관련된 기술을 교육시키는 데 전문입니다. 그의 웹사이트인 http://www.paulyao.com/ 를 한 번 방문해 보십시오.

David Durant는 SQL Server와 응용 프로그램 개발에 대한 전문 독립 컨설턴트/트레이너입니다. 그는 워싱턴주의 White Salmon에서 부인, 그리고 그녀가 좋아하는 모든 동물들과 살고 있습니다. 그는 SQL Server의 고향과 그의 손자들을 만나기 위해 Redmond에 자주 갑니다.

Top of Page Top of Page


Microsoft