Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: 'docwiki 번역'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. Docwiki에 있는 "GetIt Package Manager Window"를 번역한 글 (번역 업데이트: 2022년 9월 1일) << 위로 가기: 겟잇 패키지 매니저 (GetIt Package Manager) 겟잇 패키지 매니저 창 (GetIt Package Manager Window)을 사용하여 겟잇 패키지를 찾을 수 있다. 이 창에서는 해당 패키지를 설치(install), 제거(uninstall), 업데이트(update), 구독(subscribe) 할 수도 있다. 항목 설명 검색 필드에 단어를 하나 또는 그 이상 입력하여 패키지 목록에 필터링된 패키지만 표시되도록 한다. 패키지 이름, 제공사, 설명 중에 입력한 검색어가 들어 있는 패키지가 표시된다. 검색어를 입력할 때 패키지 목록이 바로 반영된다. Filter 패키지 목록에 있는 패키지를 필터링할 옵션을 클릭할 수 있다. All: 모든 패키지를 표시하고, 따로 제외되는 패키지가 없도록 한다. Install(설치) 하려면 해당 패키지를 선택한다. Installed: 설치된 패키지들이 표시되고 Uninstall을 선택하여 제거 할 수 있다.이옵션해당 패키지 Subscription Only: 서브스크립션(구독)을 유지하고 있는 경우에만 설치 또는 업데이트를 할 수 있는 패키지만 보여준다. Updates: 업데이트가 있는 패키지들이 표시된다. 해당 패키지의 업데이트 버전을 보려면, 의존하는 모든 라이선스 약관을 동의해야 한다. Sort by 패키지 목록을 정렬할 수 있는 옵션 3가지는 아래와 같다. Name: 패키지 이름을 기준으로 알파벳 순서 올림차순으로 정렬한다. Vendor: 제공사 이름을 기준으로 알파벳 순서 올림차순으로 정렬한다. Date: 설치할 수 있게된 시점을 기준으로 패키지 목록을 정렬한다. Categories 패키지 목록을 필터링하는 카테고리는 아래와 같다. All: 모든 패키지를 표시하고, 따로 제외되는 패키지가 없도록 한다. Libraries: 라이브러리 패키지만 표시한다. Components: 컴포넌트 패키지만 표시한다. Internet Of Things: IoT(사물인터넷) 패키지만 표시한다. Trial: 써드-파티 제공사의 겟잇 패키지 평가판만 표시한다. Industry Templates: 산업별 템플릿만 표시한다. 이 템플릿은 해당 산업에 맞게 이미 구현되어 있으므로 사용자가 자신에게 맞게 변경하여 사용하면 된다. IDE Plugins: IDE 플러그인만 표시한다. Styles: 스타일이 담긴 패키지만 표시한다. 스타일은 사용자가 UI 컴포넌트의 모습을 변경할 때 사용하는 UI 템플릿이다. C++ Libraries: C++ (CX) 라이브러리만 표시한다. Sample Projects: 샘플 프로젝트만 표시한다. Trial Packages: 평가판 버전이 제공되는 패키지만 표시한다. 알아둘 점: 위에 나열된 Categories 시스템은 고정된 것이 아니므로 시간이 가면서 카테고리가 추가될 수도 있다. 패키지 목록 각 패키지 상자에는 해당 패키지에 대한 안내와 install 또는 uninstall 버튼이 제공된다. 아이콘: 각 패키지마다 자신을 대표하는 아이콘이 표시된다. 패키지 아이콘의 가장 위-왼쪽 구석에는 아래 아이콘 중 하나가 작게 표시되어, 해당 패키지가 어떤 언어를 지원하는 지를 알려 준다. 델파이, C++ 모두 델파이 C++ 알아둘 점: 해당 패키지가 델파이와 C++ 모두에서 사용할 수 있고, 그 중 델파이 버전이 C++까지도 지원하는 경우, 겟잇 패키지 매니저에서는 델파이 아이콘만 표시된다. 이름과 버전: 패키지의 이름과 버전. 패키지 이름과 버전을 클릭하면 해당 패키지에 대한 자세한 정보가 표시되는 웹 페이지가 열린다. 제공사(Vendor): 패키지를 제공하는 제공사(vendor) 이름. 제공사 이름을 클릭하면 해당 제공사에 대한 자세한 정보가 표시되는 웹 페이지가 열린다. Install: 해당 패키지가 설치되어 있지 않은 경우 Install 버튼이 표시되고, 설치가 완료되면, 가장 위-오른쪽 구석에 Installed(설치됨) 아이콘이 표시된다. Uninstall: 설치된 패키지인 경우, Uninstall 버튼이 표시된다. Renew subscription: 서브스크립션(구독)을 유지하고 있어야 설치되는 패키지인 경우, 해당 업데이트 서브스크립션 페이지로 이동한다. Open Link: IDE 밖으로 나가서 설치해야 하는 패키지는 Open Link 버튼이 표시된다. 알아둘 점: 설치가 미루어진 패키지는 당신에게 IDE를 다시 시작하여 설치 과정을 완료하라고 요청할 것이다. IDE를 바로 다시 시작하기를 원하지 않는 경우, 해당 패키지는 당신이 IDE를 다시 시작할 때 설치를 시작한다. 설치가 미루어진 패키지에는 Cancel Pending Installation 버튼이 표시되므로 지연된 해당 설치를 취소할 수 있다. 기타 참고 (See Also) 겟잇 패키지 매니저를 사용하여 패키지 설치하기 겟잇 의존 (GetIt Dependencies)
  2. Docwiki에 있는 "Installing a Package Using GetIt Package Manager"를 번역한 글 (번역 업데이트: 2022년 9월 1일) << 위로 가기: 겟잇 패키지 매니저 (GetIt Package Manager) 겟잇 패키지 매니저 (GetIt Package Manager)를 사용하여 RAD 스튜디오 안에 라이브러리(library) 또는 패키지(package)를 설치하려면, Tools > GetIt Package Manager 를 선택하여 (GetIt Package Manager Window)을 연다. 설치하려는 겟잇 패키지를 찾는다. 이 창의 가장 위-오른쪽 구석에 있는 검색 상자를 사용할 수도 있다. 설치하려는 겟잇 패키지에 표시된 Install 버튼을 클릭한다. 대화 창이 열리면, 해당 패키지의 라이선스 조항, 패키지가 의존하는 항목을 읽고 약관 전체에 동의한다면 Agree all을 클릭한다. 패키지 설치를 IDE를 실행하지 않는 동안 수행한다. IDE를 다시 시작할 것인지 여부를 묻는 대화 상자가 나타나면 No를 클릭한다. 그러면 IDE에서 하던 작업을 계속할 수 있고 해당 패키지 설치는 IDE가 종료될 때까지 대기하게 된다. Install 창이 열리고 해당 패키지 다운로드 및 설치의 진행 상태가 표시된다. 설치가 끝나면, Close 버튼을 클릭하여 Install 창을 닫는다. 알아둘 점: 몇몇 패키지의 경우, 해당 다운로드가 완료된 후에 설치자(Installer)가 실행된다. 런-타임 (run-time) 패키지, 또는 런-타임과 디자인-타임 (run-time and design-time) 패키지의 경우, 겟잇 패키지 매니저 (GetIt Package Manager)는 해당 패키지를 해당 패키지가 지원하는 모든 플랫폼 용으로 컴파일한다. RAD 스튜디오에 새 플랫폼 지원을 추후에 추가하는 경우, 해당 패키지 역시 새로 추가된 플랫폼용으로 다시 컴파일되어야 한다. 그렇게 하려면, 해당 패키지를 제거(uninstall) 후 다시 설치(install)하거나 또는 수작업으로 해당 패키지를 컴파일한다. 기타 참고 (See Also) 겟잇 패키지 매니저 창 (GetIt Package Manager Window) Boost 겟잇 의존 (GetIt Dependencies)
  3. Docwiki에 있는 "Feature Manager"를 번역한 글 (번역 업데이트: 2022년 9월 1일) << 위로 가기: Graphic Utilities Index Tools > Manage Platforms 기능 관리자 (Feature Manager)는 설치된 RAD 스튜디오에 프로그래밍 언어(들), 타겟 플랫폼(들), 언어 지원 기능, 도움말 자료 등의 기능을 추가하거나 제거할 때 사용하는 대화 창이다. 새 기능을 추가하는 경우에는, 반드시 인터넷에 연결되어 있어야만 한다. 그래야 선택한 기능을 설치하기 위한 파일을 다운로드를 할 수 있기 때문이다. 목차 1 기능 선택 페이지 (Feature Selection Page) 2 작업 진행 페이지 (Operation Progress Page) 3 작업 완료됨 페이지 (Operation Complete Page) 4 작업 취소됨 페이지 (Operation Canceled Page) 5 기타 참고 (See Also) 1 기능 선택 페이지 (Feature Selection Page) 기능 선택 (Feature Selection) 페이지에서는 RAD 스튜디오에 설치될 수 있는 기능이 아래에 있는 탭 2개에 나누어져 들어있다. Platform Selection (플랫폼 선택) 탭에는 사용자가 선택할 수 있는 프로그래밍 언어와 타겟 플랫폼이 한쌍씩 짝지어져 있다. Additional Selection (추가 선택) 탭에는 아래 기능들이 있다. Additional Languages (추가 언어) Samples (샘플) Help (도움말) Optional Additional Software (추가 선택 소프트웨어) 이미 설치되어 있는 기능은 체크 표시가 되어 있다. 사용자는 설치하고 싶은 기능에 체크 표시 넣거나, 제거하고 싶은 기능에서 체크 표시를 뺄 수 있다. 가장 아래-왼쪽 구석에 예상되는 다운로드 크기, 예상되는 다운로드 시간, 예상되는 필요 공간이 필드 3개 즉, Estimated Download Size, Estimated Download Time, Estimated Required Space가 표시된다. 가장 아래 오른쪽-구석에 있는 Apply 버튼을 클릭하면, 선택한 기능 설치와 선택 해제된 기능 제거가 시작된다. 알아둘 점: 안드로이드 지원 설치를 처음 선택한 경우, 추가 선택 페이지 (Additional Selection Page)에서 제공되는 안드로이드 필수 개발 도구(들)이 설치되어야 한다. 자세한 내용은 Installation Notes 참조 2 작업 진행 페이지 (Operation Progress Page) Operation Progress(작업 진행) 페이지는 설치 진행 경과를 표시한다. RAD 스튜디오의 기능을 설치하는 동안 몇몇 항목들을 다운로드(download), 추출(extraction), 설치(installation) 가 진행된다. 이 페이지에서는 이 항목들의 설치 진행 정보를 아래와 같이 표시한다. 이 페이지 가장 위에는, 현재 설치되고 있는 항목이 표시된다. 이 페이지 아래쪽에는, 진행 표시 막대 2개가 표시된다. 위에 있는 진행 표시 막대는 현재 설치되고 있는 항목의 다운로드, 추출, 설치 진행 상태를 표시한다. 아래에 있는 진행 표시 막대는 모든 항목이 설치되기까지 얼마나 진행되고 있는 지를 표시한다. 이 페이지 가장 아래에 있는 Cancel 버튼을 클릭하면, 설치가 취소된다. 3 작업 완료됨 페이지 (Operation Complete Page) Operation Complete(작업 완료됨) 페이지는 설치 작업이 성공하였음을 알려준다. 이 페이지 가장 아래에 있는 Start Working 버튼을 클릭하면, 설치된 RAD 스튜디오가 실행을 시작(Start)한다. 4 작업 취소됨 페이지 (Operation Canceled Page) Operation Canceled(작업 취소됨) 페이지는 설치 작업이 취소되었음을 알려준다. 이 페이지에 있는 Retry 버튼을 클릭하면 설치를 계속하고, Close 버튼을 클릭하면 이 기능 설치자 (Feature Installer)가 종료(Exit)된다. 5 기타 참고 (See Also) Adding or Removing Features Using the Feature Manager 기능 설치자 (Feature Installer) 겟잇 패키지 매니저 (GetIt Package Manager)
  4. Docwiki에 있는 "Feature Installer"를 번역한 글 (번역 업데이트: 2022년 8월 31일) << 위로 가기: Graphic Utilities Index 이 내용은 RAD 스튜디오를 설치할 때 필요한 설치 도구 중 하나에 대한 안내이다. 설치 지침은 설치 방법을 참고하라. 기능 설치자 (Feature Installer)는 설치 마법사 중 하나이다. 이것은 RAD 스튜디오 기능 중에서 처음부터 설치할 것들을 지정한다. 예를 들면, 프로그래밍 언어(들), 타겟 플랫폼(들), 언어 지원 기능, 도움말 자료 등을 취사 선택하여 조합할 수 있다. RAD 스튜디오 설치자(Installer)는 설치 진행 중에 자동으로 이 기능 설치자 (Feature Installer)를 구동한다. 의도치 않게 이 기능 설치자를 닫은 경우에는, 설치를 완료한 후에 RAD 스튜디오를 실행하고 Tools > Manage Platforms 메뉴를 선택하여 다시 열 수 있다. 설치 중에는, 반드시 인터넷에 연결되어 있어야만 한다. 그래야 선택한 기능을 설치하기 위한 파일을 다운로드를 할 수 있기 때문이다. RAD 스튜디오를 설치한 후에도, 이 기능 관리자 (Feature Manager)를 열어서 기능을 추가로 설치하거나, 설치된 기능을 제거할 수 있다. 목차 1 플랫폼 선택 페이지 (Platform Selection Page) 1.1 예상되는 필요 공간 (Estimated Required Space) 2 추가 선택 페이지 (Additional Selection Page) 3 작업 진행 페이지 (Operation Progress Page) 4 작업 완료됨 페이지 (Operation Complete Page) 5 작업 취소됨 페이지 (Operation Canceled Page) 6 기타 참고 (See Also) 1 플랫폼 선택 페이지 (Platform Selection Page) 플랫폼 선택 (Platform Selection) 페이지에서는 RAD 스튜디오 기능 중에서 처음부터 설치할 프로그래밍 언어(들), 타겟 플랫폼(들)을 선택할 수 있다. 이 페이지의 항목은 다음과 같다. 선택할 수 있는 프로그래밍 언어(들)과 타겟 플랫폼(들) 지원 목록. 윈도우 32-bit와 iOS가 기본으로 선택되어 있지만, 설치하기를 원하는 플랫폼(들)을 몇 가지든 직접 선택할 수 있다. 이후에도 언제든 기능 관리자 (Feature Manager) 를 열어서 선택을 변경할 수도 있다. 가장 아래-왼쪽 구석에 필드 3개 즉, Estimated Download Size, Estimated Download Time, Estimated Required Space가 표시된다. 즉 선택한 기능(들)을 모두 다운로드 할 때 예상되는 규모가 표시된다. 예상되는 필요 공간에 대한 더 많은 정보는 예상되는 필요 공간 (Estimated Required Space)을 참고. 가장 아래 오른쪽-구석에 있는 Continue 버튼을 클릭하면 추가 선택 페이지 (Additional Selection Page)가 열린다. 1.1 예상되는 필요 공간 (Estimated Required Space) 기능 설치자 (Feature Installer)는 사용자가 선택한 기능들을 기준으로 설치할 때 필요한 공간을 계산한다. 이 계산에 포함되는 사항은 다음과 같다. 파일을 다운로드하기 위해 필요한 디스크 공간 다운로드한 파일을 추출할 때 필요한 디스크 공간 설치 과정에 필요한 디스크 공간 기능 설치자 (Feature Installer)가 사용하는 디렉토리는 다음과 같다. 다운로드된 파일이 들어갈 Temp(임시) 폴더 (기본 경로는 C:\Windows\Temp). 다운로드된 파일을 추출한 파일 들이 들어갈 %PUBLIC% 문서 경로 (기본 경로는 C:\Users\Public\Documents\). 설치 진행 중에 Options 페이지에서 사용자가 선택한 설치 경로 (기본 경로는 Program Files). 사용자가 Options 페이지에서 선택한 설치 경로가 있는 디스크/파티션이 Temp(임시) 폴더와 %PUBLIC% 문서가 있는 디스크/파티션과 다를 경우, 설치자(installer)는 공간 부족을 탐지하지 못하므로 이후 진행 과정에서 공간 부족 문제가 생길 수도 있다. 그 이유는 필요한 공간을 계산할 때 Options 페이지에서 사용자가 지정한 디스크/파티션을 사용하기 때문이다. Temp(임시) 폴더와 %PUBLIC% 문서가 있는 디스크/파티션의 공간이 부족한 경우, 이 폴더들의 위치를 다른 곳으로 변경할 필요가 있다. 더 자세한 정보는 Change location of TEMP files folder to another drive와 How can I move default location of Public folders to a new drive?를 참고하라. 2 추가 선택 페이지 (Additional Selection Page) 추가 선택 (Additional Selection) 페이지에서는 RAD 스튜디오 기능 중에서 처음부터 설치할 추가 기능(들)을 선택할 수 있다. 이 페이지에는 아래 내용들이 제시된다. 추가 옵션 기능이 나열되는 트리뷰: 언어 지원, 샘플 애플리케이션, 오프라인 도움말, 추가 옵션 소프트웨어 등. 초기 설치 시 포함할 기능을 모두 선택하면 된다. 가장 아래-왼쪽 구석에 필드 3개 즉, Estimated Download Size, Estimated Download Time, Estimated Required Space가 표시된다. 즉 선택한 기능(들)을 모두 다운로드 할 때 예상되는 규모가 표시된다. Platform Selection (플랫폼 선택) 페이지에서 선택한 기능까지 모두 포함된 규모임). 가장 아래쪽에 버튼 2개: 가장 아래 오른쪽-구석에 있는 Install 버튼을 클릭하면 선택된 기능이 설치되기 시작한다. Back 버튼을 클릭하면 Platform Selection (플랫폼 선택) 페이지로 되돌아 간다. 알아둘 점: 선택 기능과 관련된 보다 자세한 내용은 추가 옵션 소프트웨어 참조 Platform Selection (플랫폼 선택) 페이지에서 안드로이드 플랫폼을 선택하면 아래 개발 도구들이 표시된다. 표시되는 안드로이드 도구 목록 (11 알렉산드리아 기준) Android SDK 25.2.5 - NDK (android-ndk-17b) Java Development Kit 1.8 3 작업 진행 페이지 (Operation Progress Page) Operation Progress(작업 진행) 페이지는 설치 진행 경과를 표시한다. RAD 스튜디오의 기능을 설치하는 동안 몇몇 항목들을 다운로드(download), 추출(extraction), 설치(installation) 가 진행된다. 이 페이지에서는 이 항목들의 설치 진행 정보를 아래와 같이 표시한다. 이 페이지 가장 위에는, 현재 설치되고 있는 항목이 표시된다. 이 페이지 아래쪽에는, 진행 표시 막대 2개가 표시된다. 위에 있는 진행 표시 막대는 현재 설치되고 있는 항목의 다운로드, 추출, 설치 진행 상태를 표시한다. 아래에 있는 진행 표시 막대는 모든 항목이 설치되기까지 얼마나 진행되고 있는 지를 표시한다. 이 페이지 가장 아래에 있는 Cancel 버튼을 클릭하면, 설치가 취소된다. 4 작업 완료됨 페이지 (Operation Complete Page) Operation Complete(작업 완료됨) 페이지는 설치 작업이 성공하였음을 알려준다. 이 페이지 가장 아래에 있는 Start Working 버튼을 클릭하면, 설치된 RAD 스튜디오가 실행을 시작(Start)한다. RAD 스튜디오가 지원하는 파일 유형(들)이 현재 다른 애플리케이션에 연계(associate)되어 있는 경우, RAD 스튜디오가 열리면서 File Association 옵션 페이지와 유사한 대화 창이 나타난다. 여기에서 RAD 스튜디오에 연계(associate)하기를 원하는 파일 유형(들)을 선택할 수 있다. 5 작업 취소됨 페이지 (Operation Canceled Page) Operation Canceled(작업 취소됨) 페이지는 설치 작업이 취소되었음을 알려준다. 이 페이지에 있는 Retry 버튼을 클릭하면 설치를 계속하고, Close 버튼을 클릭하면 이 기능 설치자 (Feature Installer)가 종료(Exit)된다. 6 기타 참고 (See Also) 설치 방법 (Installation) Installer 기능 관리자 (Feature Manager) 겟잇 패키지 매니저 (GetIt Package Manager)
  5. Docwiki에 있는 "GetIt Dependencies"를 번역한 글 (번역 업데이트: 2022년 8월 31일) << 위로 가기: Project Properties Project > Options > Project Properties > GetIt Dependencies 이 대화 창을 사용하면 당신의 프로젝트에서 의존하고 있는 패키지(들) 중 겟잇 패키지 매니저 (GetIt Package Manager)에서 제공되는 것들을 지정할 수 있다. 겟잇 의존 (GetIt Dependencies) 대화 창에 있는 항목들은 다음과 같다. 항목 설명 Required 이 프로젝트에 반드시 필요한 패키지인지 아닌지가 정해진다. 필수 패키지라는 것을 알려주려면 해당 패키지 옆의 체크 박스에 선택 표시를 하고 OK를 클릭한다. Status 패키지가 가질 수 있는 상태(Status)는 다음과 같다: Available: 이 패키지가 설치된 상태이다. 해당 프로젝트와의 관계는 여기에 표시되지는 않는다. Missing: 이 패키지는 해당 프로젝트에 필요하다. 하지만, 설치되지 않은 상태이다. Unavailable: 이 패키지는 해당 프로젝트에 필요하다. 하지만, 더 이상 겟잇(GetIt)에서 제공되지 않는다. Name 패키지 이름 Description 패키지 설명 Install 버튼 Missing 상태인 (즉, 프로젝트에 필요하지만 현재 설치되어 있지 않은) 패키지를 설치하려면 이 버튼을 클릭한다. Install All Missing Packages 버튼 Missing 상태인 (즉, 프로젝트에 필요하지만 현재 설치되어 있지 않은) 패키지를 모두 설치하려면 이 버튼을 클릭한다. 겟잇 의존이 분실된 프로젝트 열기 (Opening a Project with Missing GetIt Dependencies) 설치되지 않은 "겟잇 의존 (GetIt Dependencies)"이 있는 프로젝트를 RAD 스튜디오에서 열면, 아래 그림과 같이 해당 안내와 다운로드 버튼이 제공되는 알림이 표시된다. Yes를 선택하면 Missing 상태인 의존 패키지(들)이 설치된다. No를 선택하면하고, 나중에 겟잇 의존 (GetIt Dependencies) 대화 창에서 Install All Missing Packages 버튼을 사용하여 설치할 수도 있다. 기타 참고 (See Also) 겟잇 패키지 매니저 (GetIt Package Manager) 겟잇 패키지 매니저 창 (GetIt Package Manager Window) 겟잇 패키지 매니저를 사용하여 패키지 설치하기
  6. Docwiki에 있는 "GetIt Package Manager"를 번역한 글 (번역 업데이트: 2022년 7월 5일) << 위로 가기: Graphic Utilities Index << 위로 가기: Tools Menu 겟잇 패키지 매니저 (GetIt Package Manager)를 사용하면 RAD 스튜디오 안에서 추가하고 싶은 패키지(들)을 찾고, 다운로드 하고, (유료인 경우) 구입하고, 설치할 수 있다. 패키지(들)로는 라이브러리, 컴포넌트, IDE 기능 확장, SDK, 샘플 프로젝트, 스타일 등등이 해당된다. 이 패키지들은 겟잇용 웹 포탈인 겟잇나우에서도 볼 수 있다. 주제 겟잇 패키지 매니저 창 겟잇 패키지 매니저를 사용하여 패키지 설치하기 기타 참고 (See Also) 겟잇 의존 (GetIt Dependencies) 기능 설치자 (Feature Installer) 기능 관리자 (Feature Manager) Offline Installer (오프라인 설치자)
  7. Docwiki에 있는 "About Generators"를 번역한 글(최종 번역일: 2022년 8월 21일) << 위로 가기: 제너레이터(Generator)를 가지고 작업하기 제너레이터(generator)는 INSERT, UPDATE 등 데이터를 조작하는 SQL이 작동할 때 읽기-쓰기 데이터베이스 안에 있는 컬럼에 자동으로 들어갈 고유한 일련번호를 생성하는 매커니즘(mechanism)이다. 제너레이터(generator)는 주로 프라이머리 키 (PK, PRIMARY KEY)로 사용되는 컬럼에 들어갈 고유한 값을 생성할 때 흔하게 사용된다. 예를 들어 세금계산서를 기록하고 추적하는 애플리케이션을 만드는 프로그래머는 데이터베이스 안에 있는 각 세금계산서의 계산서 번호가 고유한(unique) 값이 되도록 하고 싶을 것이다. 이 경우 프로그래머는 제너레이터를 사용하면 세금계산서 번호를 자동으로 생성할 수 있다. 그러면 이 작업을 수행하기 위한 코드를 따로 작성하지 않아도 된다. 제너레이터는 데이터베이스 하나 안에 얼마든지 많이 정의할 수 있다. 단 제너레이터 이름이 중복되면 안된다. 제너레이터는 자신이 선언된 데이터베이스 안에서 글로벌(global 또는 전역) 범위로 작동한다. 어떤 트랜잭션(transaction )이든 원하는 제너레이터를 활성화 하면 해당 제너레이터를 사용할 수 있다. 즉 제너레이터의 현재 값을 가져다 쓰거나, 현재 값에 그 다음 숫자 값이 반영되게 할 수 있다. 인터베이스(InterBase)는 트랜잭션(transaction)들이 동일한 제너레이터를 함께 사용하는 경우에도 제너레이터에 중복된 값을 할당하지 않는다. 다음 단계 (Advance To) 제너레이터 생성하기 (Creating Generators)
  8. Docwiki에 있는 "Creating Generators"를 번역한 글(최종 번역일: 2022년 8월 21일) << 위로 가기: 제너레이터(Generator)를 가지고 작업하기 데이터베이스에서 제너레이터(generator)를 생성(create)하려면 CREATE GENERATOR 진술을 사용한다. CREATE GENERATOR는 해당 데이터베이스에 제너레이터를 하나 선언하고 시작값을 (기본값인) 0으로 지정한다. 해당 제너레이터의 시작값(starting value)을 0이 아닌 다른 숫자로 지정하려면 SET GENERATOR 를 사용하여 새 값을 명시한다. CREATE GENERATOR 의 문장 구조는 다음과 같다. CREATE GENERATOR 제너레이터_이름; 아래 진술은 이름이 EMPNO_GEN인 제너레이터를 생성한다. CREATE GENERATOR EMPNO_GEN; 다음 단계 (Advance To) 제너레이터 값을 지정하기 또는 재지정하기 (Setting or Resetting Generator Values)
  9. Docwiki에 있는 "Setting or Resetting Generator Values"를 번역한 글(최종 번역일: 2022년 8월 21일) << 위로 가기: 제너레이터(Generator)를 가지고 작업하기 SET GENERATOR 진술은 제너레이터(generator)에서 만들 처음 만들 숫자 값을 지정한다. 새 제너레이터에서는 처음으로 지정(set)할 때에 사용하고, 이미 있는 제너레이터인 경우에는 재지정(reset)할 때 사용한다. 이 처음 만들 숫자 값 즉 아래 <정수(int)> 자리에 숫자 -263부터 263 – 1 까지 중 하나를 지정할 수 있다. GEN_ID() 함수가 호출되면, 제너레이터의 값은 GEN_ID() 함수에 전달되는 <증가폭(step)> 파라미터 만큼을 이 <정수(int)>에 더한 숫자 값이 된다. SET GENERATOR 의 문장 구조는 다음과 같다. SET GENERATOR NAME TO 정수(int); 아래 진술은, 이름인 CUST_NO_GEN인 제너레이터의 값이 1,000이 되로록 하는 예문이다.. SET GENERATOR CUST_NO_GEN TO 1000; 중요: 중복되는 숫자가 나오지 않는다고 확신하는 경우라 아니라면, 제너레이터의 값을 재지정(reset) 하면 안된다. 예를 들어 제너레이터는 프라이머리 키(PK, PRIMARY Key) 또는 고유 무결성 제약 (UNIQUE integrity constraint)이 지정된 컬럼에 숫자를 할당하기 위해 사용되는 경우가 흔한데, 만약 제너레이터 값을 재지정(reset) 함으로써 제너레이터 값이 해당 컬럼에서 이미 사용된 값과 중복되는 경우에는 이어지는 모든 INSERT와 UPDATE 작업은 실행되지 못하고 "Duplicate key (키가 중복됨)" 오류 메시지를 받게 된다. 다음 단계 (Advance To) 제너레이터 사용하기 (Using Generators)
  10. Docwiki에 있는 "Using Generators"를 번역한 글(최종 번역일: 2022년 8월 21일) << 위로 가기: 제너레이터(Generator)를 가지고 작업하기 CREATE GENERATOR 진술을 사용하여 제너레이터(generator)를 만들고 나면, 만들어진 제너레이터가 해당 데이터베이스 안에 존재하지만 아직은 실제로 숫자를 만들어내지는 않은 상태이다. 이 숫자 생성기 즉 제너레이터(generator)를 불러내려면 인터베이스의 GEN_ID() 함수를 호출해야 한다. GEN_ID() 함수에는 파라미터 두개 즉 호출할 제너레이터의 이름 (이것은 이미 해당 데이터베이스 안에 정의되어 있는 것이어야 한다)과 <증가폭(step)> 값을 받는다. 증가폭 값은 얼마나 차이를 두고 다음 값이 생성되는 지를 지정하는 값인데, 만약 음수로 지정되면 그만큼 작아진 값이 생성된다. GEN_ID() 는 트리거(trigger), 스토어드 프로시저(stored procedure) 안에서 호출될 수도 있고 애플리케이션 안에서 INSERT, UPDATE, DELETE 동작을 발생시킬 때 호출될 수도 있다. 애플리케이션에서 SELECT 진술 만에서 GEN_ID() 를 사용하여 제너레이트에서 값을 받아와서 그 값을 INSERT 진술 안에 넣어서 사용할 수도 있다. GEN_ID()의 문장 구조는 다음과 같다. GEN_ID(제너레이터 이름, 증가폭); 숫자를 생성하려면 아래 단계를 따라 진행하면 된다. 제너레이터를 생성한다. 트리거(trigger) 또는 스토어드 프로시저(stored procedure) 또는 애플리케이션 안에서 해당 제너레이터를 지정하여 GEN_ID() 를 호출하도록 한다. 해당 제너레이터가 값을 반환하는 시점은 트리거가 발효될 때 또는 스토어드 프로시저 또는 애플리케이션이 실행될 때이다. 생성된 숫자 값을 실제로 사용할 것인지 아닌 지는 해당 트리거, 스토어드 프로시저, 애플리케이션에서 결정한다. 예를 들어, 트리거에서 컬럼에 해당 값을 넣을 수 있다. 생성된 숫자를 데이터베이스 컬럼 안에 넣기를 멈추려면, 해당 트리거, 스토어드 프로시저, 애플리케이션를 삭제하거나 또는 더 이상 GEN_ID() 를 불러내지 않도록 변경()한다. 중요: 제너레이터에서 반환하는 숫자는 64-비트 값이다. 생성된 값을 ISC_INT64 변수로 담을 수 있는 컬럼을 정의해야 하는데 DECIMAL 또는 NUMERIC 데이터 타입을 사용해야 한다. 예: 아래 진술은 GEN_ID() 를 사용하여 이름이 G인 제너레이터를 호출하여 SALES 테이블 안에 있는 주문 번호를 1씩 증가한다. INSERT INTO SALES (PO_NUMBER) VALUES (GEN_ID(G,1)); 트리거에서 제너레이터를 사용하는 방법에 대한 자세한 내용은 Working with Triggers 에 있다. 스토어드 프로시저에서 제너레이터를 사용하는 방법에 대한 자세한 내용은 Working with Stored Procedures 에 있다. 다음 단계 (Advance To) 제너레이터 제거하기 (Dropping Generators)
  11. Docwiki에 있는 "Dropping Generators"를 번역한 글(최종 번역일: 2022년 8월 21일) << 위로 가기: 제너레이터(Generator)를 가지고 작업하기 데이터베이스에서 제너레이터를 제거(drop)하려면 다음 문장 구조를 사용한다. DROP GENERATOR 제너레이터_이름 DROP GENERATOR 명령은 트리거(trigger)나 사용자 정의 함수(UDF)를 제거할 때와 마찬가지로 해당 제너레이터를 의존하고 있는 것들이 있는 지를 점검하여 만약 의존하고 있는 것이 있다면 이 명령은 수행되지 않는다. 명시된 "제너레이터_이름"이 해당 데이터베이스에 정의된 제너레이트의 이름 중에 없는 경우에도 수행되지 않는다. 이미 제거된 제너레이터를 애플리케이션에서 호출하려고 하면 런타임 에러 (runtime error)가 반환된다. 알아둘 점: 인터베이스 이전 버전까지는 이 DROP GENERATOR 명령이 없었다. 따라서 사용자들은 해당 시스템 테이블에서 특정 제너레이터를 삭제하도록 SQL 진술을 만들어서 사용했다. 이제는 이런 방식을 사용하기 않기 바란다. DROP GENERATOR 명령을 사용하면 된다. 시스템 테이블 변경은 언제나 해당 데이터베이스 전체를 망가뜨려서 사용할 수 없게 만들 가능성이 있기 마련이다. 아주 작은 에러나 계산 오류 만으로도 말이다. 다음 단계 (Advance To) Data Definition Guide
  12. Docwiki에 있는 "Working with Generators"을 번역한 글(최종 번역일: 2022년 8월 21일) << 위로 가기: Data Definition Guide 이 글에서 다룰 내용: 제너레이터(Generator) 란 무엇인가 제너레이터(Generator)를 새로 만들고(create), 변경하고(modify), 제거하는(drop) 방법 제너레이터(Generator)를 사용하는 방법 주제 제너레이터란 무엇인가 (About Generators) 제너레이터 생성하기 (Creating Generators) 제너레이터 값을 지정하기 또는 재지정하기 (Setting or Resetting Generator Values) 제너레이터 사용하기 (Using Generators) 제너레이터 제거하기 (Dropping Generators) 다음 단계 (Advance To) 제너레이터란 무엇인가 (About Generators)
  13. Docwiki에 있는 "Getting Started with Change Views"을 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 목차 1 ODS 플랫폼 업데이트 2 마이그레이션 이슈와 의존성 (Migration Issues and Dependencies) 3 요구사항과 제약조건 (Requirements and Constraints) 3.1 요구사항 (Requirements) 3.2 제약조건 (Constraints) 3.3 백업(Backup)/복구(Restore) 고려 사항 3.4 지연된 제약조건 확인 (Deferred Constraint Checking) 3.5 트리거 비활성화 (Trigger Inactivation) 3.6 백업를 가지고 데이터베이스 복구 (Database Restore from a Backup) 4 다음 단계 (Advance To) 1 ODS 플랫폼 업데이트 체인지 뷰스 (Change Views)를 위해서는 해당 인터베이스 데이터베이스 파일의 기반인 ODS가 맞아야 한다. 따라서 기존에 사용하던 데이터베이스인 경우에는 반드시 백업하고 알맞은 ODS 버전으로 복구해야만 이 기능을 사용할 수 있다. 복구된 데이터베이스에 새 ODS 포맷이 반영되고 나면 해당 데이터베이스를 더이상으로 이전 버전의 인터베이스에 붙이지 못한다. 2 마이그레이션 이슈와 의존성 (Migration Issues and Dependencies) FOR ROW (..., DELETE)가 정의된 구독(subscription)인 경우, 삭제(delete)된 행도 반환된다. 여기에는 삭제 전에 컬럼(들)에 있던 값들이 제공된다. 존재하는 데이터를 제시하는 리포팅 애플리케이션에서는 삭제가 정의된 구독이 해당 트랜잭션에 묶이지 않도록 주의해야 한다. 이 경우에는, 더 이상 존재하지 않는 데이터(들) 까지도 포함되어 결과세트(resultset)로 반환된다. 3 요구사항과 제약조건 (Requirements and Constraints) 3.1 요구사항 (Requirements) 체인지 뷰스 (Change Views)로 작업할 때 "홀수 번호 (odd-numbered)" SQL DATA TYPES(SQLVAR 변수, sqltype)를 사용해야 한다. 이렇게 하면 반환된 컬럼(column) 데이터에 대한 상태를 SQLVAR 안에 있는 SQL 표시기 변수에서 받을 수 있다. 체인지 뷰스 (Change Views)에서 데이터를 조회(select)할 때에는 트랜잭션 격리 수준 중 SNAPSHOT을 사용해야 한다. 체인지 뷰스 (Change Views)에서 데이터를 수정할 때에는 어떤 격리 수준이든 사용할 수 있다. 인터베이스의 테이블은 레코드 포맷의 버전을 최대 256개까지 가질 수 있다. 구독 하나가 테이블 하나를 참조하게 되면 해당 테이블에 새 레코드 포맷이 생긴다. CREATE SUBSCRIPTION 진술을 많이 만들 때에는 자동커밋(autocommit) DDL 동작을 비활성화하도록 하면 좋다. 그러면 많은 구독(들)이 여러 데이블을 참조할 때 레코드 포맷이 하나만 만들어진다. 3.2 제약조건 (Constraints) TRANSACTION ID는 구독 타임스탬프(TIMESTAMP)를 얻기 위한 프록시(PROXY) 역할을 한다 체인지 뷰스 (Change Views) 기능은 TRANSACTION ID에 크게 의존한다. TRANSACTION ID는 체인지 뷰스 (Change Views)에서 조회(select)가 발생한 마지막 타임스탬프를 관찰(observe)하는 프록시 역할을 하기 때문이다. 덕분에 변경된 데이터를 중복으로 다시 전송하지 않는다. 지금은, 커밋(commit)된 데이터의 TRANSACTION ID가 데이터베이스 백업에 저장되지 않는다. 따라서 백업을 사용하여 데이터베이스를 복구(restore)하면, TRANSACTION ID가 다시 0으로 지정된다. TRANSACTION ID는 32-비트 공간이므로 고객 사이트에서 사용하다보면 소진될 수도 있다. 그런 경우에는 데이터베이스를 백업하고 복구(restore)해야 한다. TRANSACTION ID를 64-비트 (48-비트가 될 확률이 높다)로 전환하는 프로젝트를 한다면, 합리적인 수준의 시간 동안 TRANSACTION ID가 소진되지 않게 될 수 있을 것이다. 예를 들어 TRANSACTION ID가 48-비트가 된다면, 페이지 크기가 4KB인 데이터베이스가 10,000 tps(초당 트랜잭션) 이상을 100년 동안 지속적으로 실행할 수 있다. 이것은 데이터 변경 뷰(changed data view)들을 지원할 뿐만 아니라, 인터베이스 데이터베이스를 TRANSACTION ID 소진 때문에 백업/복구하는 상황도 완전히 없앨 수 있다. 3.3 백업(Backup)/복구(Restore) 고려 사항 논리 백업(logical backup)/복구는 모든 구독 정의 (subscription definition)를 백업하고 복구하지만, 이 구독을 사용하는 구독자(subscriber)들을 추적하는 데이터는 백업되지 않고 복구되지도 않는다. 구독자(subscriber)들은 새 (또는 복구된) 데이터베이스에서 각자 자신의 구독을 개시/활성화를 해야 한다. 3.4 지연된 제약조건 확인 (Deferred Constraint Checking) 체인지 뷰스(Change Views) 기능은 원본 데이터베이스 안에서 발생한 변경의 순서 (sequence 또는 order)를 획득(capture)하지 않는다. 이 진술(statement)은 테이블 하나 안에서 뿐만 아니라 서로 다른 여러 테이블에 걸쳐서 발생된 변경에서도 마찬가지로 똑같이 적용된다. 의사-컬럼(pseudo-column)인 RECORD_VERSION 또는 TRANSACTION_ID를 노출하고 해당 컬럼을 기준으로 정렬하는 방식으로 대충 변경 순서를 짐작할 수는 있다. 하지만 이렇게 짐작한 결과가 모든 사용 사례에서 언제나 정확한 순서를 알려준다고 확신해서는 안된다. 구독을 하나 또는 그 이상 사용하여 동기화 매커니즘을 구현하는 경우에는, 제약조건(constraint) 확인을 충족해야 하는데 그러기 위해서는 변경이 발생한 순서가 중요할 수 있다. 인터베이스는 제약조건 확인 시 IMMEDIATE 만을 지원한다. 인터베이스에서 DEFERRED 제약조건 확인을 지원해야 한다는 요구사항이 있다. 그래야 목적지(destination) 데이터베이스에서 다양한 제약조건이 작동되고 있는 경우에도 구독 변경을 문제없이 적용할 수 있다. 3.5 트리거 비활성화 (Trigger Inactivation) 인터베이스에서는 "기명 트리거(named trigger)"를 비활성화 하도록 선언할 수 있다. 구독된 변경 사항이 목적지(destination) 데이터베이스에 적용될 때 트리거가 발동하지 않도록 방지해야 하는 상황이 있을 수 있기 때문이다. 트리거 비활성화 여부는 애플리케이션에 따라 알맞게 결정하면 된다. 하지만 지금 언급하는 트리거 비활성화는 그 범위(scope)를 해당 데이터베이스 세션 하나로만 제한해야 한다. 인터베이스는 해당 트리거를 해당 데이터베이스에 연결하는 모든 데이터베이스 세션에서 비활성화 한다. 작동 범위 제한이 필요하다는 요구사항이 있다. 만약 구현된다면, 제약조건 지연 (Deferred Constraint)이 요구되는 것과 마찬가지 일 것이다. 3.6 백업를 가지고 데이터베이스 복구 (Database Restore from a Backup) 논리 백업 파일 (logical backup file) 또는 물리적 덤프(dump) 파일을 사용하여 데이터베이스를 복구하면, 구독자(subscriber)들은 이미 받은 구독 변경 사항을 되찾을 수 있다.구독자는 RDB$SUBSCRIPTIONS.RDB$CHECK_OUT_TIMESTAMP 메타데이터를 저장할 수 있어서 변경이 중복으로 처리되는 이슈가 있을 때 도움을 받을 수 있다. 4 다음 단계 (Advance To) 체인지 뷰스에서 구독 생성하기 (Creating Subscriptions to Change Views)
  14. Docwiki에 있는 "Creating Subscriptions to Change Views"를 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 데이터베이스 연결(connection)의 자연스러운 경계를 넘어서 테이블(들)을 한(1) 세트를 대상으로 변경된 데이터를 관찰(observe)하려면, 반드시 구독 하나를 생성하고 이 구독에 해당 테이블(기반 테이블 또는 뷰)들을 나열해야 한다. CREATE SUBSCRIPTION 문장 구성(Syntax) CREATE SUBSCRIPTION <구독_이름> ON< <테이블_이름>[(필요한 컬럼들을 쉼표로 구분하여 나열)][FOR ROW (CHANGE | {INSERT, UPDATE, DELETE})] [,<테이블_이름>[(필요한 컬럼들을 쉼표로 구분하여 나열)][FOR ROW (CHANGE | {INSERT, UPDATE, DELETE})] ...] [DESCRIPTION 사용자를 위한 설명]; FOR ROW 절은 해당 구독에서 어떤 변경 유형에 대해서 컬럼-수준 변경 추적을 할 것인지를 지정한다. FOR ROW 절을 생략하면 기본 설정인 FOR ROW (CHANGE)로 작동한다. CHANGE 옵션은 INSERT와 UPDATE 데이터 변경 동작을 추적하고 추적 대상 컬럼 중 어느 하나라도 값이 변경하면 즉시 해당 행(row)을 반환한다. INSERT, UPDATE, DELETE를 명시하면, 변경 추적 대상 컬럼 모두에 해당 변경 상태가 지정된다. 이 옵션은 "깊은 레코드 검사(deep record introspection)"라고 부른다. CHANGE 옵션은 "얕은 레코드 검사(shallow record introspection)"라고 부른다. CHANGE 옵션은 보다 성능이 좋고 INSERT, UPDATE, DELETE가 모두 넣은 옵션은 보다 완전도가 높다. DELETE는 기본 설정에 해당되지 않으므로, 포함하려면 직접 명시해야 한다. "깊은 레코드 검사"는 추적 대상 컬럼 모두에 대해 해당 컬럼의 값을 변경 시킨 동작을 정확히 알아야 하는 경우에 필요하다. "얕은 레코드 검사"는 추적 대상 컬럼 중 어느 컬럼에서든 값 변경이 발생했는 지 그 여부만 알면 되고, 추적 대상 컬럼 "모두에 대해 각각" 무슨 동작에 의해 변경되었는 지 (또는 변경되지 않았는 지)를 알 필요가 없는 사용 사례인 경우에 사용할 수 있다. 즉, 해당 구독으로 관찰한 바에 따르면 해당 행(row)은 어떤 동작에 의해서든 변경되었다는 점을 알려준다. 테이블만 명시한 경우에는 해당 테이블의 모든 컬럼을 추적한다. 일부 컬럼(들)만 추적하고 싶은 경우에는 원하는 컬럼(들)을 나열하여 명시할 수 있다. 예를 들어, CREATE SUBSCRIPTION 예문 CREATE SUBSCRIPTION sub_employee_changes ON EMPLOYEE (EMP_NO, DEPT_NO, SALARY) DESCRIPTION 'EMPLOYEE 테이블 안에서 발생한 변경 구독'; CREATE SUBSCRIPTION sub_customer_deletes ON CUSTOMER FOR ROW (DELETE) DESCRIPTION 'CUSTOMER 테이블에서 발생한 삭제 구독'; CREATE SUBSCRIPTION sub_various_changes ON EMPLOYEE FOR ROW (INSERT, UPDATE, DELETE), CUSTOMER FOR ROW (INSERT, UPDATE, DELETE), SALES FOR ROW (UPDATE), DEPARTMENT (LOCATION) FOR ROW (UPDATE) DESCRIPTION '여러 테이블에서 발생한 여러 변경을 구독'; 특정 컬럼들을 목록으로 나열하는 것은 옵션 사항이다. 위 예제에서는 EMPLOYEE 테이블에 이 옵션을 적용하여 해당 컬럼들의 변경만 추적하도록 했다. 또한 EMPLOYEE 테이블에는 FOR ROW 절이 없기 때문에, 기본(default) FOR ROW 옵션인 CHANGE 옵션이 적용된다. CHANGE 옵션은 INSERT와 UPDATE 데이터 변경 동작을 추적하고 값이 변경된 모든 컬럼의 값을 담은 행(row)를 즉시 반환한다. CUSTOMER 테이블에는 FOR ROW 절에 DELETE가 명시되어 있기 때문에 행(row) 삭제 (delete)만 추적된다. 목차 1 DROP SUBSCRIPTION (구독 제거) 2 GRANT SUBSCRIBE (구독 권한 부여) 3 SET SUBSCRIPTION (구독 지정) 4 다음 단계 (Advance To) 1 DROP SUBSCRIPTION (구독 제거) 알아둘 점: 이 기능은 인터베이스 XE7 업데이트 1부터 제공된다. 변경 뷰(들)을 관찰하기(observe)를 완전히 그만하려면, 해당 구독(subscription)을 반드시 제거(drop) 해야 한다. RESTRICT를 명시하는 경우, 구독자(subscriber)가 있는 지 확인 동작이 수행된다. 만약 구독자가 있으면 에러가 반환되고 구독은 제거(drop)되지 않는다. CASCADE를 명시하는 경우, 해당 구독을 구독하는 모든 구독자가지 모두 제거(drop)된다. RESTRICT와 CASCADE 중 어느것도 명시하지 않으면, RESTRICT로 간주한다. DROP SUBSCRIPTION 문장 구성(Syntax) DROP SUBSCRIPTION <구독_이름> [RESTRICT | CASCADE]; 2 GRANT SUBSCRIBE (구독 권한 부여) 목록에 나열된 테이블 상의 변경을 사용자가 추적할 수 있도록 하려면, 그 사용자에게 해당 구독을 구독할 수 있는 SUBSCRIBE 특권(privilege)을 부여한다. GRANT SUBSCRIBE 문장 구성(Syntax) GRANT SUBSCRIBE ON SUBSCRIPTION <구독_이름> TO <사용자_이름>; REVOKE SUBSCRIBE ON SUBSCRIPTION <구독_이름> FROM <사용자_이름>; 3 SET SUBSCRIPTION (구독 지정) 구독(subscription)을 활성화(Active)로 지정하려면, 애플리케이션에서 SET SUBSCRIPTION 진술을 발행한다. SET SUBSCRIPTION 진술에서는 구독 여러개를 활성화할 수 있고 AT 절을 사용하여 구독한 변경을 수신하는 목적지 또는 장비의 이름을 명시한다. 구독자(subscriber)의 사용자 이름은 데이터베이스 연결에서 식별되는 사용자의 신원이라고 암묵적으로 이해될 수도 있다. 해당 사용자를 위한 동일한 스키마 오브젝트에 대한 여러 구독을 AT 절을 통해서 명시적으로 지정하는 것은 다음 두가지 동기에서 비롯되었다. 첫째, 사용자 한명은 여러 장비에서 구독을 받을 수 있는데 해당 장비들은 연결이 끊어질 수도 있어서 변경된 세트를 받기 위해 다른 시간에 다른 목적으로 독립적으로 필요한 구독을 조회할 수도 있다. 둘째, 몇몇 다중-사용자 (multiuser) 애플리케이션에서는 데이터베이스 연결 풀링을 사용하여 단일 사용자 이름(예: CRM_User 또는 심지어 SYSDBA) 만으로 데이터베이스를 연결한다. 이런 경우에, 구독은 변경 세트를 조회할 때 대체 식별자 ( alternate identifier)를 제공받아야만 어느 사용자를 위한 구독인 지를 구별할 수 있다. 이런 추가 식별자로는 목적지(destination) 즉 "장비 이름"의 식별자라고도 생각해 볼 수 있다. SET SUBSCRIPTION 진술은 구독자(subscriber)를 위해 구독을 활성화/비활성하여 해당 명령을 실행하는 트랜잭션에 구독(subscription)을 묶기(bind)/풀기(unbind)를 한다. 구독이 묶인 트랜잭션에 의해 실행되는 사용자-수준(user-level) 쿼리에서는 구독 대상 테이블(들)은 모두 해당 구독 안에서 변경 뷰(들)로 작동한다. 따라서 변경 뷰를 계속 원한다면, 이어지는 다른 트랜잭션들에서도 SET SUBSCRIPTION 를 발행해야 한다. 트랜잭션이 커밋(commit)되는 시점에는, 해당 구독자(subscriber)의 트랜잭션 상태가 업데이트 되어서 해당 구독자들이 해당 커밋 이전의 변경을 보지 않고 해당 커밋 이후에 발생된 변경들을 볼 수 있게 된다. 트랜잭션을 롤백(rollback)하면 해당 구독자의 트랜잭션 상태는 변경되지 않기 때문에 해당 변경 뷰는 여전히 롤백 이전의 변경을 계속 볼 수 있지만 롤백 이후의 새 변경을 보지는 못한다. 만약 구독이 묶여있는(bind) 트랜잭션이지만, 이 트랜잭션에서 구독의 추적 대상인 테이블 중에서 어느 하나도 읽지 않는다면 해당 구독의 해당 구독자 트랜잭션의 문맥은 업데이트 되지 않는다. SET SUBSCRIPTION 문장 구성과 예문 SET SUBSCRIPTION [<구독_이름> [, <구독_이름> ...]] [AT <목적지>] {ACTIVE | INACTIVE}; SET SUBSCRIPTION sub_employee_changes, sub_customer_deletes AT '스마트폰_123' ACTIVE; SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE; SELECT * FROM CUSTOMER; COMMIT or COMMIT RETAIN; 이 예문은 구독 두(2)개를 활성화하고 구독의 추적 대상 테이블(들)에서 변경된 데이터를 반환한다. COMMIT은 해당 트랜잭션 동안 참조된 스키마 오브젝트(들)에 대한 모든 구독을 업데이트 하여 가장 마지막에 관찰(observe)된 타임스탬프(timestamp)와 트랜잭션 문맥(context)을 지정한다. COMMIT RETAIN은 가장 마지막 관찰 상태를 변경하지 않고 그대로 최신 스냅샷을 유지한다. 구독은 해당 트랜잭션이 커밋(COMMIT)될 때 풀린다. 구독이 풀린 이후에 구독 대상 스키마 오브젝트(들)에 대한 후속 쿼리(query)는 일반 데이터 세트를 반환한다. 즉 데이터 변경 상태와 관련이 없어진다. 트랜잭션 하나에서 동시에 활성할 수 있는 구독의 갯수에는 제한이 없다. 4 다음 단계 (Advance To) 진술 실행(Statement Execution)
  15. Docwiki에 있는 "Statement Execution"을 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 진술(statement)이 한번 준비(PREPARE)되고 나면, 구독 활성화 또는 비활성화를 하기 위해 해당 진술(statement)을 다시 준비할 필요가 없다. 진술은 실행(EXECUTE)이 시작될 때 해당 트랜잭션에 연결된 구독 환경에 맞추어 동적으로 반응한다. 진술 실행(EXECUTE)은 한번 시작되면 일관성이 유지된다. 따라서 해당 결과 세트를 모두 받아오기(fetch) 전에 해당 구독이 비활성화된다고 해도 여전히 실행이 시작된 시점의 변경 뷰를 반환한다. 활성화된 구독에서 가져오는 도중에 구독을 비활성화 하는 경우 일반 열람 도중에 구독을 활성화하는 경우 PREPARE Q; PREPARE Q SET SUBSCRIPTION ... ACTIVE EXECUTE Q EXECUTE Q FETCH Q FETCH Q SET SUBSCRIPTION ... ACTIVE SET SUBSCRIPTION ... INACTIVE FETCH Q FETCH Q CLOSE Q CLOSE Q 진술 Q 안에서 읽어오는 구독 대상 테이블에 대한 참조는 해당 구독이 비활성화된 후에도 변경 뷰에 있는 행(들)을 반환한다. 그 반대 상황 역시 마찬가지이다. 즉 (변경 뷰가 아닌) 일반 결과세트 역시 결과세트를 받아오는 해당 FETCH 도중에 구독이 활성화되어 끼어들어도 결과세트는 변함없이 일관성이 유지된다. 다음 단계 (Advance To) 체인지 뷰스 API 지원 (Change Views API Support)
  16. Docwiki에 있는 "Change Views API Support"을 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 주제 체인지 뷰스 API는 확장된 SQLVAR 구조인 (해당 SQLIND 멤버를 새로 해석한) XSQLVAR를 통해 지원된다. 검토를 하려면, 개발자가 XSQLVAR.SQLIND 안에 변수 하나를 두고 그곳에 포인터를 위치시키고 NULL의 상태를 요청(request)한다. 쿼리를 실행하면, 인터베이스는 반환하는 행(row)의 해당 컬럼 값이 NULL이 아닌 경우에 0을 NULL 인 경우에는 -1을 이 포인터에 넣는다. 새 해석에 따르면, 이중(dual) 개념인 NULL 상태와 CHANGE 상태는 해당 SQLIND 멤버 변수 안에서 겹친다. 해당 SQLIND 변수에서 가장 낮은 비트(bit)들은 컬럼 변경 표시자로 쓰도록 예약되어 있다. Bit 0은 INSERT; Bit 1은 UPDATE; Bit 2는 DELETE; Bit 3은 CHANGE를 가리킨다. NULL 상태를 확인하려면, 개발자는 SQLIND를 확인 할 때, -1인지를 확인하지 말고 0보다 작은지를 확인해야 한다. SQLIND 주소에 0 또는 0 보다 큰 값이 들어 있으면 NULL이 아닌 값이라는 표시이다. NOT NULL NULL 변경 상태 SQLIND = 0 SQLIND = -1 체이지 뷰스와 구독(subscription)이 사용되지 않았던 예전의 SQLIND에서 반환하는 값. 여기에는 변경 상태가 정의되지 않는다. SQLIND >= 0 SQLIND < 0 새 SQLIND에서 반환하는 값. 변경 상태가 제시될 "수"도 있고 테스트 할 수 있다. SQLIND > 0 SQLIND < -1 변경 상태가 제시된다. 일단 SQLIND 값에 변경 상태가 들어있다고 결정된 경우, 구체적인 상태를 테스트하기 전에 미리 SQLIND_NULL 비트가 있을 가능성을 깨끗이 해소해야 한다. 아래에 있는 SQLIND_xxxxxx 정의는 <ibase.h>에 들어잇다. 이러한 정의를 대상으로 다양한 비트 OR 연산을 수행하여 관심있는 변경 상태를 테스트할 수 있다. SQLIND 값 변경 상태 SQLIND_CHANGE_VIEW 해당 컬럼은 <same> 값이다; 이 컬럼의 값은 변경되지 않았다. SQLIND_CHANGE_VIEW | SQLIND_CHANGE <unknown> 이다. 즉 해당 컬럼의 값이 변경 여부를 알 수 없다. SQLIND_CHANGE_VIEW | [ SQLIND_CHANGE ] | { SQLIND_INSERT | SQLIND_UPDATE | SQLIND_DELETE } SQL 작동(operation)들의 조합 몇가지가 해당 컬럼의 값을 변경했다. SQLIND_CHANGE_VIEW는 태그 비트(bit)로써 변경 상태가 존재하는 지 여부를 알려준다. 나머지 정의들은 FOR ROW 절에 있는 옵션들인 CHANGE, INSERT, UPDATE, DELETE에 각각 이름에 맞게 대응된다. CHANGE 옵션은 <unknown> 변경 상태를 일으킬 수 있는데 이 옵션에서는 어느 컬럼이든 변경이 감지되기만 하면 무조건 변경된 행(row)이 바로 반환되기 때문이다. 이 경우 변경이 발생한 컬럼의 값들은 분명한 상태를 반환하지만, 그 외의 컬럼들은 <unknown> 상태를 반환한다. 구독에 의해 변경된 데이터는 해당 구독에서 나중에 관찰(observe)하면 보이지 않는다. 이것은 양방향 복제 상황에서 체인지 뷰스가 구성 요소로 적용될 가능성을 고려했기 때문이다. 복제 쌍에서 발생된 변경에 대해 어느 한쪽에서 다른 쪽에 업데이트하고, 그 다른쪽에서 그 복제를 다시 반대 방향으로 복제하는 것은 바라지 않는다. 다음 단계 (Advance To) 체인지 뷰스 SQL 언어 지원 체인지 뷰스 SQL 언어 지원 (Change Views SQL Language Support)
  17. Docwiki에 있는 "Change Views SQL Language Support"을 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 아래 예문은 체인지 뷰스 (Change Views)를 지원하기 위해 재작성된 ISQL 명령-줄 (command-line) 도구(유틸리티)를 보여준다. 데이터베이스 안에 정의된 구독(subscription)들을 목록으로 표시하려면, SHOW SUBSCRIPTIONS 명령을 사용한다. 특정 구독의 세부 내용을 표시하려면, SHOW SUBSCRIPTION <구독_이름> 명령을 실행한다. ISQL SHOW SUBSCRIPTION 명령 SHOW SUBSCRIPTIONS; Subscription Name =================================================================== SUB_CUSTOMER_DELETES SUB_EMPLOYEE_CHANGES SUB_VARIOUS_CHANGES SHOW SUBSCRIPTION sub_employee_changes; Subscription name: SUB_EMPLOYEE_CHANGES Owner: SYSDBA Description: EMPLOYEE 테이블 안에서 발생한 변경 구독 EMPLOYEE (SALARY, DEPT_NO, EMP_NO) SHOW SUBSCRIPTION sub_customer_deletes; Subscription name: SUB_CUSTOMER_DELETES Owner: SYSDBA Description: CUSTOMER 테이블에서 발생한 삭제 구독 CUSTOMER FOR ROW (DELETE) SHOW SUBSCRIPTION sub_various_changes; Subscription name: SUB_VARIOUS_CHANGES Owner: SYSDBA Description: 여러 테이블에서 발생한 여러 변경을 구독 EMPLOYEE FOR ROW (INSERT, UPDATE, DELETE), CUSTOMER FOR ROW (INSERT, UPDATE, DELETE), SALES FOR ROW (UPDATE), DEPARTMENT (LOCATION) FOR ROW (UPDATE) ISQL SET CHANGES 명령 ISQL에는 SET 진술(statement)들의 모음이 있어서, 표시할(display) 결과 세트를 토글(toggle)할 수 있다. SET CHANGES 표시 토글은 해당 컬럼의 데이터 값과 해당 변경 상태를 옆에 달아서 함께 보여 줄 것인지 아닌 지를 왔다갔다 할 수 있다. <CHANGE> 컬럼은 의사(pseudo) 컬럼이며 여기에는 해당 컬럼의 값을 변경한 DML 진술의 유형이 표시된다. 이 변경 상태 모두는 새 구조인 XSQLDA의 멤버인 XSQLVAR.SQLIND에 의해서 반환된다. 데이터 변경 뷰를 지원하기 위해 인터베이스 SQL (ISQL)에 IS SAME 또는 IS NOT SAME 절이 추가되었다. ISQL에서 체인지 뷰스를 받아오기 (Retrieving Change Views from ISQL) <또 다른 사용자가 기존 직원을 다른 부서로 재배치한다. 그리고 또 다른 직원은 급여를 인상한다> SET SUBSCRIPTION sub_employee_changes ACTIVE; SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE; EMP_NO DEPT_NO SALARY 37 120 50000 109 600 75000 SET CHANGES; SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE; EMP_NO <change> DEPT_NO <change> SALARY <change> -------- ---------- ----------- 37 <same> 120 <update> 50000 <same> 109 <same> 600 <same> 75000 <update> COMMIT; SET SUBSCRIPTION 사용에 대한 자세한 정보는 구독 지정(SET SUBSCRIPTION)에 설명되어 있다. ISQL에서 체인지 뷰스를 위한 SQL 확장 (SQL Extensions for Change Views) 알아둘 점: 이 기능은 인터베이스 XE7 업데이트 1부터 제공된다. 데이터 변경 뷰를 지원하기 위해 인터베이스 SQL (ISQL)에 IS [NOT] {CHANGED | INSERTED | UPDATED | DELETED} 절이 추가되었다. 아래 예문을 참조한다. IS [ NOT ] UPDATED를 SELECT 쿼리(query) 안에서 사용하기 SET SUBSCRIPTION sub_employee_changes ACTIVE; SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE WHERE SALARY IS UPDATED; EMP_NO DEPT_NO SALARY -------- ---------- ---------- 109 600 75000 위 예문의 결과를 보면 EMP_NO=37 직원이 부서를 이동한 것에 대한 행이 반환되지 않았다. 그 이유는 이 직원의 경우 부서만 이동했을 뿐 급여 조정이 없었기 때문이다. IS CHANGED 절을 사용하면 어떤 SQL 동작이든 해당 컬럼에 생긴 변경를 모두 탐지한다. 다음 단계 (Advance To) 메타데이터 지원 (Metadata Support) 2 다음 단계 (Advance To)
  18. Docwiki에 있는 "Ad-hoc Subscriptions and SQL Language Support"을 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 체인지 뷰스 (Change Views)를 임시로 구독하려면 애드-혹(ad-hoc) 구독(subscription)을 사용한다. 애드-혹 구독은 연결이 지속되는 동안 실행된다. 사용자는 이름을 가진 (named) 구독이 아니라 원하는 스키마 오브젝트를 직접 구독할 수 있다. 이 임시 구독은 해당 데이터베이스 연결이 종료될 때까지 유효하다. 하지만 연결이 유지되는 동안이라도 사용자가 명시적으로 비활성화면 더이상 유효하지 않다. 아래 예문은 체인지 뷰스 (Change Views)를 지원하기 위해 재작성된 ISQL 명령-줄 (command-line) 도구(유틸리티)를 보여준다. 사용자는 해당 스키마 오브젝트 (예: 테이블)에 대한 임시 구독 특권(privilege)을 받아야만 한다. 임시 구독 권한 부여 (GRANT TEMPORARY SUBSCRIBE) GRANT TEMPORARY SUBSCRIBE 문장 구성 GRANT TEMPORARY SUBSCRIBE[(<필요한 컬럼들을 쉼표로 구분하여 나열>)] ON <테이블_이름> TO <사용자_이름>; REVOKE TEMPORARY SUBSCRIBE[(<필요한 컬럼들을 쉼표로 구분하여 나열>)] ON <테이블_이름> FROM <사용자_이름>; 해당 사용자는 SET SUBSCRIPTION 명령(command)을 발행한다. 이때 구독(subscription) 이름 대신 기반 테이블의 이름을 직접 제공한다. ISQL을 사용하여 데이터 변경 뷰(들)을 받기(RETRIEVE) SET SUBSCRIPTION "Employees" ACTIVE; SELECT NAME, DEPARTMENT, SALARY FROM "Employees"; COMMIT; <또 다른 사용자가 기존 직원을 다른 부서로 재배치한다. 그리고 또 다른 직원은 급여를 인상한다> SELECT NAME, DEPARTMENT, SALARY FROM "Employees"; <CHANGE> NAME DEPARTMENT SALARY update joe sales 50000 update mary finance 75000 SET SAME; SELECT NAME, DEPARTMENT, SALARY FROM "Employees"; <CHANGE> NAME DEPARTMENT SALARY update <same> sales <same> update <same> <same> 75000 COMMIT; SET SUBSCRIPTION "Employees" INACTIVE; ISQL에는 SET 진술(statement)들의 모음이 있어서, 표시할(display) 결과 세트를 토글(toggle)할 수 있다. SET SAME 표시 토글은 해당 컬럼의 데이터 값을 보여 줄 것인지 아니면 변경되지 않는 데이터를 <same>으로 표시하고 변경된 데이터만 해당 값을 표시할 것이지를 왔다갔다 할 수 있다. <CHANGE> 컬럼은 의사(pseudo) 컬럼이며 여기에는 해당 컬럼의 값을 변경한 DML 진술의 유형이 표시된다. 이 변경 상태 모두는 새 구조인 XSQLDA의 멤버인 XSQLVAR.SQLIND에 의해서 반환된다. 데이터 변경 뷰를 지원하기 위해 인터베이스 SQL (ISQL)에 IS SAME 또는 IS NOT SAME 절이 추가되었다. 아래 예문을 참조: IS NOT SAME을 SELECT 쿼리(query) 안에서 사용하기 <SELECT NAME, DEPARTMENT, SALARY FROM "Employees" WHERE SALARY IS NOT SAME; <CHANGE> NAME DEPARTMENT SALARY update mary finance 75000 위 예문의 결과를 보면 joe에 대한 행이 반환되지 않았다. 그 이유는 joe의 경우 부서만 이동했을 뿐 급여 조정이 없었기 때문이다. 다음 단계 (Advance To) 체인지 뷰스 요구사항과 제약사항 (Change Views Requirements and Constraints)
  19. Docwiki에 있는 "Metadata Support"를 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) 구독(subscription) 정보는 새로 추가된 시스템 관계인 RDB$SUBSCRIPTIONS에 자신 만의 고유한 키 (unique key)를 가지고 저장되며 이 키를 통해 RDB$SUBSCRIPTION_NAME, RDB$SUBSCRIBER_NAME, RDB$DESTINATION과 연결된다. RDB$SUBSCRIPTIONS에 있는 부가적인 필드들에는 변경된 데이터의 "체크 인"과 "체크 아웃"을 다룰 수 있는 통제 정보가 저장된다. 통제에 필요한 정보로는 트랜잭션 ID, 타임스탬프, 그리고 해당 스키마 오브젝트에서 발생한 변경 데이터를 가장 마지막에 관찰 (last observation)한 트랜잭션의 문맥(context) 등이 해당된다. "체크 아웃(check out)"이라는 용어의 의미는, 구독이 활성화되어 있는 상황에서, 구독되는 테이블(들)에서 행을 가져오기 즉 변경되는 컬럼을 "읽기(SELECT)"하는 것을 의미한다. "체크 인(check in)"이라는 용어의 의미는 구독이 활성화되어 있는 상황에서, 구독되는 테이블(들)의 행에 "삽입(INSERT)", "업데이트(UPDATE)", "삭제(DELETE)"를 실행하여 구독의 대상인 컬럼에 변경을 발생시키는 것을 의미한다. 데이터베이스에서 SET SUBSCRIPTION ACTIVE가 실행된 세션이 유지되는 동안 구독은 활성화된다. SET SUBSCRIPTION INACTIVE를 실행하면 비활성화 된다. 목차 1 구독/구독자 테이블들 (Subscription/Subscriber Tables) 1.1 RDB$SUBSCRIPTIONS 1.2 RDB$SUBSCRIBERS 1.3 RDB$ENCRYPTIONS 1.4 RDB$FIELDS 1.5 RDB$TRIGGERS 1.6 RDB$RELATIONS 1.7 RDB$RELATION_FIELDS 1.8 RDB$USER_PRIVILEGES 2 다음 단계 (Advance To) 1 구독/구독자 테이블들 (Subscription/Subscriber Tables) 이 주제는 체이지 뷰스 (Change Views) 기능을 구현하기 위해 새로 추가되고 업데이트된 컬럼들을 다룬다. RDB$SUBSCRIPTIONS와 RDB$SUBSCRIBERS는 새로 추가된 테이블로써 구독/구독자 요소를 담당한다. 아래에 나열된 테이블 목록에서 위 2개를 뺀 나머지는 이미 있던 테이블에 컬럼이 새로 추가되거나 변경된 테이블들이다. 1.1 RDB$SUBSCRIPTIONS ODS 버전 16부터 새로 들어간 시스템 관계/테이블이다. 컬럼 이름 데이터 타입 길이 설명 RDB$SUBSCRIPTION_NAME CHAR 67 구독(subscription)의 이름 RDB$RELATION_COUNTER SMALLINT 2 구독 1개 안에 있는 여러 줄로된 항목들을 추적하기 위해 세는 숫자 RDB$RELATION_NAME CHAR 67 관계(relation) 또는 뷰(view)의 이름 RDB$FIELD_NAME CHAR 67 필드(field)의 이름 RDB$DESCRIPTION BLOB 서브타입(subtype) 텍스트: 구독을 설명하는 글 RDB$SECURITY_CLASS CHAR 67 해당 구독의 보안 클래스(security class), SQL 보안을 위한 해당 소유주 RDB$OWNER_NAME CHAR 67 해당 구독을 생성한 사용자 RDB$RUNTIME BLOB 런-타임(run-time) 바이너리 정보를 빼내어 성능을 강화 RDB$FLAGS SMALLINT 2 RDB$INSERT BOOLEAN 2 삽입(INSERT)들이 추적된다. RDB$UPDATE BOOLEAN 2 업데이트(UPDATE)들이 추적된다. RDB$DELETE BOOLEAN 2 삭제(DELETE)들이 추적된다. RDB$CHANGE BOOLEAN 2 모든 동작을 추적한다. 하지만 어떤 컬럼이든 변경이되면 즉시 반환한다. 1.2 RDB$SUBSCRIBERS ODS 버전 16부터 새로 들어간 시스템 관계/테이블이다. 구독자(subscriber) 정보가 저장된다. 컬럼 이름 데이터 타입 길이 설명 RDB$SUBSCRIBER_NAME CHAR 31 구독을 받는 사용자의 이름 RDB$SUBSCRIPTION_NAME CHAR 67 구독의 이름 RDB$DESTINATION CHAR 32 구독자의 목적지(DESTINATION) RDB$FLAGS SMALLINT 2 RDB$CHECK_OUT_TRANSACTION_ID INT64 8 구독을 가장 마지막에 체크아웃 한 트랜잭션 ID RDB$CHECK_OUT_TIMESTAMP TIMESTAMP 8 구독을 가장 마지막에 체크아웃 한 일시 RDB$CHECK_OUT_OLDEST_TRANSACTION_ID INT64 8 가장 마지막 체크아웃 당시 가장 오래 전에 활성화되었던 트랜잭션 RDB$CHECK_OUT_TRANSACTIONS BLOB 한글 가장 마지막 체크아웃 당시 활성화되어 있던 트랜잭션 ID들의 세트 RDB$CHECK_IN_TRANSACTION_ID INT64 8 구독을 가장 마지막에 체크인 한 트랜잭션 ID RDB$CHECK_IN_TIMESTAMP TIMESTAMP 8 구독을 가장 마지막에 체크인 한 일시 RDB$CHECK_IN_TRANSACTIONS BLOB 해당 구독에 의해 체크인된 트랜잭션 ID들의 세트 1.3 RDB$ENCRYPTIONS RDB$ENCRYPTIONS에는 해당 데이터베이스에 저장된 암호화(encryption)의 특성이 기록된다. RDB$FLAGS가 업데이트되었고, 아래에 있는 RDB$ENCRYPTION_ID 컬럼이 새로 추가되었다. 컬럼 이름 데이터 타입 길이 설명 RDB$FLAGS SMALLINT 2 1 무작위(random) 초기화 벡터(vector)가 블록 체인 암호화 모드를 위해 정의된다. 2 일반(plain) 텍스트를 무작위(random)로 덛붙인다. 4 삭제되도록 암호화(encryption)가 표시되었다. 32 이 관계(relation)에 구독이 1개 이상 붙어 있다는 표시이다. RDB$ENCRYPTION_ID SMALLINT 2 해당 암호화 키(Encryption Key)를 위한 고유한 식별자 (unique identifier) 1.4 RDB$FIELDS RDB$FIELDS에는 해당 컬럼(column)의 특성이 기록된다. 각 도메인(domain) 또는 컬럼(column)은 RDB$FIELDS 테이블 안에 상응하는 행(row)을 가지고 있다. 아래에 있는 RDB$SUBSCRIBE_FLAG 컬럼이 새로 추가되었다. 컬럼 이름 데이터 타입 길이 설명 RDB$SUBSCRIBE_FLAG SMALLINT 2 해당 필드에 구독이 1개 이상 붙어 있다는 표시이다. 1.5 RDB$TRIGGERS 트리거를 정의한다. 아래에 있는 RDB$PRIVILEGE 컬럼이 추가되었고 여기에 들어갈 구독 값도 새로 추가되었다. 컬럼 이름 데이터 타입 길이 설명 RDB$PRIVILEGE CHAR 6 RDB$USER 컬럼 안에 나열된 사용자들에게 부여된 권한을 식별한다. 이 필드 안에 들어갈 수 있는 문자와 해당 의미는 아래와 같다. ALL (A) SELECT (S) DELETE (D) INSERT (I) UPDATE (U) REFERENCE (R) MEMBER OF (역할들) (M) DECRYPT (T) ENCRYPT (E) SUBSCRIBE (B) 기존 메타데이터 관계에도 변화가 있다. 1.6 RDB$RELATIONS RDB$RELATIONS는 테이블(table)과 뷰(view)의 특성 몇가지를 정의한다. 아래에 있는 RDB$FLAGS 컬럼이 업데이트 되었다. 컬럼 이름 데이터 타입 길이 설명 RDB$FLAGS SMALLINT 2 1 = SQL이 정의된 테이블 (SQL-defined table). 2 = 글로벌 임시 테이블 (Global temporary table). 4 = <다음에 사용할 수 있도록 남겨둠>. 8 = 커밋(commit) 시점에 임시 행(row)들을 삭제 16 = 커밋(commit) 시점에 임시 행(row)들을 보존; 이 행들은 데이터베이스 분리(detach) 시점에 삭제된다. 32 = 이 관계(relation)에 구독이 1개 이상 붙어 있다는 표시이다. 1.7 RDB$RELATION_FIELDS 데이터베이스에 있는 테이블들을 위해, RDB$RELATION_FIELDS는 아래에 있는 컬럼 4개 즉 RDB$FLAGS, RDB$FIELD_NAME, RDB$RELATION_NAME, RDB$FIELD_SOURCE가 새로 추가되었다. 컬럼 이름 데이터 타입 길이 설명 RDB$FIELD_NAME CHAR 67 사용자가 정의한 컬럼 이름 RDB$RELATION_NAME CHAR 67 사용자가 정의한 테이블 이름 RDB$FIELD_SOURCE CHAR 67 RDB$FIELDS.RDB$FIELD_NAME과 짝이 맞는 내부용 컬럼 이름 RDB$FLAGS SMALLINT 2 1 = 이 필드(field)에 구독이 1개 이상 붙어 있다는 표시이다. 1.8 RDB$USER_PRIVILEGES RDB$USER_PRIVILEGES는 SQL GRANT 진술을 통해 사용자에게 부여된 특권(privilege)에 대한 추적을 유지한다. 아래에 있는 RDB$USER 컬럼과 RDB$GRANTOR 컬럼의 크기가 31에서 67로 업데이트되었다. 컬럼 이름 데이터 타입 길이 설명 RDB$USER CHAR 67 RDB$PRIVILEGE 컬럼 안에 등재된 특권(privilege)이 누구에게 부여(grant)되었는지 그 사용자의 이름이 기록된다. RDB$GRANTOR CHAR 67 특권(privilege)을 부여(grant)한 사용자의 이름 RDB$PRIVILEGE CHAR 6 Subscribe (B) 2 다음 단계 (Advance To) 애드-혹 구독과 SQL 언어 지원 (Ad-hoc Subscriptions and SQL Language Support)
  20. Docwiki에 있는 "Change Views Requirements and Constraints"을 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: 체인지 뷰스 (Change Views) (역자 주: 2022년 8월 시점에서 인터베이스의 체인지 뷰스에 있는 제약 사항 즉, 해법이 필요한 요구 사항들이다) 제약조건 확인 지연 (Deferred Constraint Checking) 체인지 뷰스(Change Views) 기능은 원본 데이터베이스 안에서 발생한 변경의 순서 (sequence 또는 order)를 획득(capture)하지 않는다. 이 진술(statement)은 테이블 하나 안에서 뿐만 아니라 서로 다른 여러 테이블에 걸쳐서 발생된 변경에서도 마찬가지로 똑같이 적용된다. 의사-컬럼(pseudo-column)인 RECORD_VERSION 또는 TRANSACTION_ID를 노출하고 해당 컬럼을 기준으로 정렬하는 방식으로 대충 변경 순서를 짐작할 수는 있다. 하지만 이렇게 짐작한 결과가 모든 사용 사례에서 언제나 정확한 순서를 알려준다고 확신해서는 안된다. 구독을 하나 또는 그 이상 사용하여 동기화 매커니즘을 구현하는 경우에는, 제약조건(constraint) 확인을 충족해야 하는데 그러기 위해서는 변경이 발생한 순서가 중요할 수 있다. 인터베이스는 제약조건 확인 시 IMMEDIATE 만을 지원한다. 인터베이스에서 DEFERRED 제약조건 확인을 지원해야 한다는 요구사항이 있다. 그래야 목적지(destination) 데이터베이스에서 다양한 제약조건이 작동되고 있는 경우에도 구독 변경을 문제없이 적용할 수 있다. 트리거 비활성화 (Trigger Inactivation) 인터베이스에서는 "기명 트리거(named trigger)"를 비활성화 하도록 선언할 수 있다. 구독된 변경 사항이 목적지(destination) 데이터베이스에 적용될 때 트리거가 발동하지 않도록 방지해야 하는 상황이 있을 수 있기 때문이다. 트리거 비활성화 여부는 애플리케이션에 따라 알맞게 결정하면 된다. 하지만 지금 언급하는 트리거 비활성화는 그 범위(scope)를 해당 데이터베이스 세션 하나로만 제한해야 한다. 인터베이스는 해당 트리거를 해당 데이터베이스에 연결하는 모든 데이터베이스 세션에서 비활성화 한다. 작동 범위 제한이 필요하다는 요구사항이 있다. 만약 구현된다면, 제약조건 지연 (Deferred Constraint)이 요구되는 것과 마찬가지 일 것이다. 다음 단계 (Advance To) 체인지 뷰스 용어집 (Change Views Glossary)
  21. Docwiki에 있는 "Change Views Glossary"을 번역한 글(최종 번역일: 2022년 8월 14일) << 위로 가기: 체인지 뷰스 (Change Views) 애드-혹 사용법 (Ad hoc usage) Alternate Identifier (대체 식별자) AT Clause (AT 절) Logical backup file (논리적 백업 파일) ODS (On-disk Structure, 디스크 상의 구조) Physical dump file (물리적 덤프 파일) 구독 지정 (Set Subscription) Transaction ID (트랜잭션 ID) 트리거 비활성화 (Trigger Inactivation) 다음 단계 (Advance To) Data Definition Guide (데이터 정의 가이드)
  22. Docwiki에 있는 "On-disk Structure (ODS)"을 번역한 글(최종 번역일: 2022년 8월 18일) << 위로 가기: Database Configuration and Maintenance (데이터베이스 구성과 관리) 인터베이스의 각 버전은 내부 파일 포맷 안에 저마다 고유한 특징을 가지고 있다. 파일 포맷을 구별하기 위해, 인터베이스는 데이터베이스 파일 안에 "디스크 상의 구조(ODS)" 번호를 기록한다. 대체로, 메이저 ODS 버전 (버전 번호에서 소수점 왼쪽에 있는 숫자가 증가하게 된다)에서 도입되는 기능은 이전 ODS 버전과 하위 호환성이 없다. 인터베이스 2020 업데이트 3의 포맷은 ODS 18이다. 하지만 ODS 17부터 ODS 13까지의 포맷이 적용된 기존 데이터베이스를 여전히 지원한다. 더 오래된 ODS 버전은 지원되지 않으며 연결되지도 않는다. (데이터베이스 백업하기와 복구하기를 통해) ODS 18로 업그레이드하고 새 기능의 혜택을 반영할 것을 권장한다. 인터베이스의 최신 버전에서 데이터베이스를 새로 만들기 또는 백업 파일을 가지고 복구하기 작업을 수행하면, 최신 ODS 버전 포맷이 적용된 데이터베이스 파일이 생긴다. 중요: 이전 버전으로 되어있는 데이터베이스의 ODS를 업그레이드 하려면, 반드시 데이터베이스의 옮기기 전인 기존 버전용 백업 도구(utility)를 사용하여 백업을 하고, 복구할 때에는 새로 옮겨갈 새 인터베이스 버전용 도구를 사용해야 한다. 다음 단계 (Advance To) Read-write and Read-only Databases
  23. Docwiki에 있는 "Change Views"을 번역한 글(최종 번역일: 2022년 8월 14일) << 위로 가기: Data Definition Guide 체인지 뷰스 (Change Views™)는 인터베이스에 반영된 다세대 아키텍처 (multigenerational architecture)를 사용하여 데이터 변경을 획득하는 기술이다. 이 기능을 사용하면 "내가 데이터를 조회한 가장 마지막 시점 이후에 변경된 데이터가 무엇이지?"라는 질문에 빠르게 답할 수 있다. 예전까지 변경 알림은 트리터, 로그(log) 기록, 그리고/또는 트랜잭션 미리-쓰기(write-ahead) 로그 수집 등이 필요했었다. 개발자가 방식으로 업무를 수행하려면 작업 시간이 많이 소요되었고, 트랜잭션 부하 또는 변경량 등도 커서 데이터베이스 성능에도 영향을 끼쳤다. 체인지 뷰스를 사용하면 기존 트랜잭션에 추가 성능 부담이 없다. 그 이유는 변경된 데이터에 대해 일관성 있는 뷰(View)를 유지 하고, 이 뷰를 다른 트랜잭션에서도 관찰(observe)할 수 있기 때문이다. 체인지 뷰스 (Change Views)의 매커니즘 (작동 방식)은 자체 데이터를 따로 두고 의지하는 방식이 아니라, 이미 존재하는 기반 테이블을 위해 존재하는 데이터 즉 기반 테이블에서 파생된 뷰를 기반으로 한다. 체인지 뷰스의 이러한 "암묵적 뷰" 매커니즘은 시간 기반이며 해당 암묵적 뷰에서 트랜잭션이 관찰된 최종 시점 이후에 변경이 발생한 데이터를 반환한다. 체인지 뷰스 (Change Views)는 사용자가 구독(Subscription) 할 수 있다. (구독을 새로 만들면 체인지 뷰스가 구현되고) 해당 데이터베이스 연결 전반에 걸쳐서 모든 변경 데이터를 볼 수 있다. 구체적으로 말하자면, 구독은 연결이 끊긴 오랜 시간 동안 테이블 하나 또는 그 이상에 삽입(insert), 변경(update), 삭제(delete)된 행의 데이터를 컬럼-수준에서 각각 추적 기록한다. 인터베이스 SQL 쿼리 언어는 이전 관찰(observe) 이후에 추적 대상 컬럼에서 변경된 데이터를 검색할 수 있도록 수정되었다. 해당 데이터 변경은 컬럼 수준에서 각각 추적 기록된다. 주제 체인지 뷰스 (Change Views) 사용을 시작하기 체인지 뷰스에서 구독 생성하기 (Creating Subscriptions to Change Views) 진술 실행 (Statement Execution) 체인지 뷰스 API 지원 (Change Views API Support) 체인지 뷰스 SQL 언어 지원 메타데이터 지원 (Metadata Support) 애드-혹(Ad-hoc) 구독과 SQL 언어 지원 (Ad-hoc Subscriptions and SQL Language Support) 체인지 뷰스 요구사항과 제약사항 (Change Views Requirements and Constraints) 체인지 뷰스 용어집 (Change Views Glossary) 다음 단계 (Advance To) 체인지 뷰스 (Change Views) 사용을 시작하기
  24. Docwiki에 있는 "InterBase Editions"을 번역한 글(최종 번역일: 2022년 8월 14일) << 위로 가기: 메인 페이지 인터베이스(InterBase) 에디션은 다음과 같다. 아이비라이트 (IBLite) 인터베이스 투고 (ToGo) 인터베이스 서버 (Server) 인터베이스 데스크탑 (Desktop) 인터베이스 개발자 (Developer) 인터베이스 에디션 별 차이첨을 정리한 표 기능 IBLite 인터베이스 ToGo 인터베이스 Desktop 인터베이스 Server 인터베이스 Developer* 플랫폼 기본 라이선스 당 CPU 코어 1 4 4 8 8 최대 동시 사용자 1 1 1 제한없음 20 사용자 당 연결 갯수 1 8 8 4 4 원격 시스템에 있는 클라이언트에서 데이터베이스에 접근 원격 시스템에 있는 서버 데이터베이스 호스트에 연결 TCP를 수신하는(listening) 서버 강력한 (256bit AES) 암호화: 데이터베이스 단위와 컬럼 단위 암호화 없음 암호화가 강력하지 않음 강력한 네트워크 암호화 (SSL) 암호화 없음 암호화가 강력하지 않음 애드-온 임포트 방식으로 라이선스 추가 가능 데이터베이스 파일 크기 한계 100MB 제한없음 제한없음 제한없음 제한없음 연결(Connection) 당 동시 트랜잭션 1** 제한없음 제한없음 제한없음 제한없음 체인지 뷰스 (Change Views) 서비스 API가 활성화되어 있음 OTW/SSL 지원 메타데이터 업데이트 (ddl 동작) 외부 테이블 접근 성능 모니터링 저널링과 저널(Journal) 보존(Archive) 48 시간 마다 서버를 다시 시작해야 함 RAD 스튜디오 (FireDAC과 IBX)에 연결 드라이버가 있음 원하는 시점으로 데이터 복구, 데이터베이스 복구 시 타임스탬프를 기반으로 무리적인 백업들 사이에서 더 유연하게 복구 배포 가능 Zero-install (설치 작업이 필요 없음), 라이브러리 형태로 임베디드 되는 데이터베이스, 연결 하기만 하면 데이터에 접근 테이블스페이스(Tablespace) 지원 안드로이드 64-비트와 맥OS 64-비트에 인터베이스를 임베드할 수 있음 기타 연결 드라이버: ODBC, JDBC, ADO.NET, PHP+ 명령 줄 () 도구를 개발, 관리, 평가 시 사용 가능 * 개발자(Developer) 에디션에는 서버(Server) 에디션에 있는 기능을 많이 들어있으며 개발 목적으로만 사용해야 함. 운영을 위해 배포하려면 별도의 라이선스가 필요함. 더 자세한 내용은 VAR Program을 참고하거나 또는 데브기어에 문의 ** 알아둘 점: 기술적으로는 트랜젝션 2개가 허용됨. 하지만, 여분의 트랜젝션이 있는 이유는 일부 드라이버가 메타데이터를 쿼리할 때 트랜젝션을 요구하는 경우가 있기 때문임 (예: FireDAC).
  25. Docwiki에 있는 "Tutorial: Using FireDAC from a Multi-Device Application on Desktop Platforms"을 번역한 글: 번역일: 2022년 8월 3일 위로 가기: Database and LiveBindings Tutorials 목차 1 FireDAC을 사용하여 데이터베이스에 연결하기 2 사용자 화면 (UI)를 디자인하고 구성하기 3 라이브바인딩스(LiveBindings) 마법사 사용하기 3.1 라이브바인딩스(LiveBindings) 컴포넌트 추가하기 3.2 그리드(Grid) 컴포넌트 추가하기 4 애플리케이션 런타임 준비 작업 5 애플리케이션을 맥OS로 배포하기 5.1 InterBase ToGO를 맥OS로 배포하기 5.2 맥OS 장비에 있는 로컬 데이터베이스에 연결되도록 코드를 변경하기 6 개발한 애플리케이션을 윈도우 컴퓨터와 맥OS 컴퓨터에서 실행하기 7 기타 참고 (See Also) 이 튜토리얼은 윈도우 컴퓨터와 맥OS 컴퓨터에서 관리하는 로컬 데이터베이스 (InterBase ToGo 데이터베이스 엔진 사용)에 있는 데이터를 조회하는 애플리케이션을 만들기 위해 FireDAC 프레임워크를 사용하는 기본 절차를 설명한다. 참고: 이 튜토리얼을 따라하려면 IBToGo 라이선스가 필요하다. 평가판 사용자라면, 평가판 사용 기간 중에 IBToGo 테스트 배포 라이선스 역시 사용할 수 있으므로 맥OS에 이 데이터베이스를 배포할 수 있다. 평가판용 배포 라이선스를 활성화하는 방법은 InterBase ToGo Deployment에 설명되어 있다. 1 FireDAC을 사용하여 데이터베이스에 연결하기 FireDAC은 데이터 연결을 일원화할 수 있도록 제공되는 유니버설한 데이터 액세스 컴포넌트(들) 세트이다. 이것은 데이터베이스를 사용하는 멀티-디바이스 애플리케이션을 델파이와 C++빌더 개발환경에서 만들 때에도 사용된다. FireDAC의 아키텍처는 강력하고 공통 기반으로 되어 있어서, 델파이 또는 C++빌더에서 InterBase, SQLite, MySQL, SQL Server, Oracle, PostgreSQL, IBM DB2, SQL Anywhere, Access, Firebird, Informix, 등등에 고속으로 직접 접근을 할 수 있다. FireDAC에 있는 엠바카데로 인터베이스(InterBase)용 네이티브 드라이버는 인터베이스 서버, 데스크탑, 디벨로버, 투고(ToGo), IBLite 에디션은 인터베이스 6.0 버전 이상을 지원한다. 윈도우에서 작동하고 있는 Interbase ToGo에서 관리하는 데이터를 조회하려면, 해당 작업을 하는 컴퓨터에 다음과 같은 x86 또는 x64 클라이언트 소프크웨어가 설치되어 있어야 한다. IBTOGO.DLL 라이브러리는 x86 애플리케이션에서 임베디드 데이터베이스인 InterBase ToGo 또는 IBLite를 사용하는 데이터베이스를 다룰 수 있다. IBTOGO64.DLL 라이브러리는 x64 애플리케이션에서 임베디드 데이터베이스인 InterBase ToGo 또는 IBLite를 사용하는 데이터베이스를 다룰 수 있다. 맥OS에서 작동하고 있는 Interbase ToGo에서 관리하는 데이터를 조회하려면, libibtogo.dylib x86 embedded InterBase가 있어야 한다. 2 사용자 화면 (UI)를 디자인하고 구성하기 새 프로젝트를 하나 만들자. 이때 Multi-Device Application을 선택한다. 폼(form) 위에 TFDConnection 컴포넌트를 하나 올려 놓는다. 올려놓은 TFDConnection 컴포넌트를 오른쪽 클릭하고 Connection Editor를 선택한다. FireDAC의 Connection Editor 안에서, 이 TFDConnection의 파라미터(들)을 다음과 같이 지정한다 Driver ID 프로퍼티에는 IB를 지정한다. Database 파라미터에는 다음과 같이 지정한다: C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Data\EMPLOYEE.GDB (데이터베이스가 있는 위치) User_name 파라미터에는 sysdba를 지정한다. Password 파라미터에는 masterkey를 지정한다. Test 버튼을 클릭하여 해당 연결 정보로 성공적으로 연결되는 지를 확인한다. OK를 클릭하여 FireDAC Connection Editor를 종료한다. 오브젝트 인스펙터 (Object Inspector) 안에서 TFDConnection를 선택하고, 이 오브젝트의 프로퍼티(들)을 아래와 같이 지정한다. LoginPrompt 프로퍼티를 False로 지정하여, 사용자에게 데이터베이스 로그인을 요구하는 창이 나타나지 않도록 한다. Connected 프로퍼티를 True로 지정한다. 3 라이브바인딩스(LiveBindings) 마법사 사용하기 라이브바인딩스(LiveBindings) 마법사를 사용하여 라이브바인딩스 컴포넌트(TBindSourceDB, TBindingsList), TFDQuery, Grid 컴포넌트를 추가한다 3.1 라이브바인딩스(LiveBindings) 컴포넌트 추가하기 View > LiveBindings Designer를 선택하여 LiveBindings Designer를 연다. LiveBindings Wizard 를 선택한다. binding task에서 Create a data source를 선택하고 Next 버튼을 클릭한다. Data source 페이지에서 FireDAC을 선택하고 Next 버튼을 클릭한다. Command Type을 Query로 변경한다. Command Text 프로퍼티에서 select * from employee를 지정한다. Test Command 버튼을 클릭한다. Next 버튼을 클릭한다. Add data source navigator를 선택한다. Finish 버튼을 클릭한다. 위 작업을 마치자 마자 TBindSourceDB 컴포넌트, TBindNavigator 컴포넌트, TFDQuery 컴포넌트가 폼(form) 위에 추가된다. 3.2 그리드(Grid) 컴포넌트 추가하기 LiveBindings Wizard 를 다시 연다. binding task에서 Link a grid with a data source를 선택한다. Next 버튼을 클릭한다. TSringGrid를 선택한다. Next 버튼을 클릭한다. BindSourceDB1을 선택한다. Finish 버튼을 클릭하여 LiveBindings 마법사를 종료한다. 위와 같이 했다면, 바인딩 다이어그램의 모습이 다음과 같아야 한다. 4 애플리케이션 런타임 준비 작업 FireDAC의 아키텍처는 서로 헐겁게-짝지어지는(loosely-coupled) 여러 계층으로 구성되고 (multilayered) 각 층마다 담당하는 서비스가 있다. 서비스 API는 COM 인터페이스로 정의되어 있어서 다른 계층에서 요청을 보낼 때 해당 인터페이스 팩토리(interface factory)를 사용한다. FireDAC이 올바로 작동되도록 하려면, 반드시 IFDGUIxWaitCursor 인터페이스와 IFDPhysDriver 인터페이스에 대한 구현을 연결해야만 한다. NavigatorBindSourceDB1을 선택하고 Align 프로퍼티에 Top을 지정한다. StringGridBindSourceDB1을 선택하고 Align 프로퍼티에 Client를 지정한다. TFDGUIxWaitCursor 와 TFDPhysSQLiteDriverLink 를 폼(form)위에 놓아둔다. 5 애플리케이션을 맥OS로 배포하기 앞에서 당신이 사용한 InterBase는 개발 장비인 데스크탑에 있는 것이다. 즉, 사용하는 InterBase의 실제 위치가 당신의 로컬 하드 디스크 드라이브 (예: C:\Users\Public\Documents\Embarcadero\Studio\22.0\Samples\Data\EMPLOYEES.GDB)에 있다. 당신의 애플리케이션을 맥OS로 배포하려면, 해당 데이터베이스 파일도 맥OS의 파일 시스템 안에 복사해야 한다 (예, /Users/<user>/EMPLOYEE.GDB). 또한 Interbase ToGo 파일(들) 역시 반드시 맥OS에 배포되어야 한다. 5.1 InterBase ToGO를 맥OS로 배포하기 Project > Deployment를 선택하여 배포 관리자 (Deployment Manager)를 연다. 배포 관리자의 윗부분에 있는 target platforms 드롭-다운 목록에서 All-Configurations - macOS platform를 선택한다. Add Featured Files 를 선택한다. Interbase ToGo 데이터 모듈을 선택하고 OK를 선택하여 Featured Files 대화창을 종료한다. 그 전에 엠바카데로로부터 ToGo 라이선스 파일을 받아두었어야 한다. 이 라이선스 파일의 이름은 reg_nnnnnnn.txt 과 같은 형태이며, nnnnnnn는 자동 생성된 숫자이다. 받아둔 라이선스 파일을 사용하여 reg_ibtogo.txt (C:\Users\Public\Documents\Embarcadero\InterBase\redist\InterBase2020 경로에 있음) 파일을 덮어써놓은 경우에는 해당 라이선스 파일을 선택하기만 하면 된다. 받아둔 라이선스 파일 이름을 그대로 사용한 경우에는, Add Files를 선택하고, 애플리케이션과 함께 배포되어야 하는 파일 목록 안에 이 라이선스 파일도 추가한다. 5.2 맥OS 장비에 있는 로컬 데이터베이스에 연결되도록 코드를 변경하기 앞에서 설명한 바와 같이, TFDConnection 컴포넌트는 지금 개발 장비인 윈도우 컴퓨터 안에 있는 데이터베이스를 연결하고 있다. 따라서 데이터베이스에 연결하기 전에 연결할 데이터베이스의 위치를 바꿔주어야 한다. 다음과 같이 한다. 폼 디자이너 (Form Designer)에서 FDConnection1 컴포넌트를 선택한다. 오브젝트 인스펙터 (Object Inspector)에서 BeforeConnect 이벤트를 더블-클릭한다. 이벤트 핸들러에 아래 코드를 추가한다. 델파이: procedure TForm9.FDConnection1BeforeConnect(Sender: TObject); begin {$IFDEF MACOS} FDConnection1.Params.Values['Database']:= '$(DOC)/EMPLOYEE.GDB'; {$ENDIF} end; C++빌더: void __fastcall TForm9::FDConnection1BeforeConnect(TObject *Sender) { #ifdef __MACOS__ FDConnection1->Params->Values["Database"] = "$(DOC)/EMPLOYEE.GDB"; #endif } 알아둘 점: $(DOC)은 경로 변수 (path variable)이다. 경로 변수를 이용하면 경로 표현식 작성을 간편하게 할 수 있다. $(DOC)는 맥OS에서는 사용자의 홈 디렉토리 (/Users/<user>)를 가리킨다. 6 개발한 애플리케이션을 윈도우 컴퓨터와 맥OS 컴퓨터에서 실행하기 이제 애플리케이션을 실행할 준비가 끝났다. 이제 배포된 애플리케이션에서도 개발환경(IDE)에서와 마찬가지로 데이터를 조회할 수 있다. 또한 TBindNavigator 컴포넌트를 사용하여 원하는 데이터로 가서 레코드를 변경할 수도 있다. 애플리케이션을 실행하려면, 프로젝트 창 (Projects Window)에서 원하는 타겟 플랫폼을 선택한다. 다음 명령 중 하나를 실행한다. Run > Run Run > Run Without Debugging 7 기타 참고 (See Also) Connect to InterBase IBLite and IBToGo Licensing in RAD Studio Preparing a FireDAC Application for Run Time LiveBindings in RAD Studio 모바일 튜토리얼: FireDAC을 모바일 애플리케이션에서 사용하기 (iOS, Android)
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.