데이터베이스 동기화 - MS Access
https://stackoverflow.com/questions/1801658
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
랩톱에서 여러 개의(동일한 스키마) 액세스 2003 데이터베이스를 사용하는 순간 문제가 있습니다.
데이터를 중앙 액세스 데이터베이스에 동기화하는 자동화된 방법을 찾아야 합니다.
노트북의 데이터는 추가만 되므로 업데이트/삭제 작업은 문제가 되지 않습니다.
이 작업을 쉽게 수행할 수 있는 도구는 무엇입니까?최고의 도구나 솔루션에 대한 결정에 영향을 미치는 요소는 무엇입니까?
해결책
액세스에 내장 된 제트 복제를 사용할 수는 있지만, 나는 당신에게 경고 할 것입니다. 또한 주요 충돌을 피하기 위해 임의의 서명 정수를 선택하기 때문에 PK를 엉망으로 만들 것입니다. 따라서 주어진 레코드의 다음 PK로 -1243482392912로 끝날 수 있습니다. 그것은 당신이 어떤 종류의 조회를하고 있다면 (고객 ID, 주문 번호 등) 액세스 동기화를 자동화 할 수는 없지만 (VBA를 사용하여 같은 것을 가짜 할 수는 있지만 여전히 가짜를 할 수는 없습니다. , 데이터베이스가 열릴 때만 실행됩니다).
권장하는 방법은 "Central"데이터베이스에서 SQL Server 2005/2008을 사용하고 "원격"데이터베이스의 백엔드로 SQL Server Express Edition을 사용한 다음 링크 된 테이블을 사용하여 이러한 SSEE 데이터베이스에 연결하고 연결하는 것입니다. 그것들을 동기화하기위한 복제. 중 하나를 설정하십시오 복제 또는 스냅 샷 복제를 병합하십시오 "Central"데이터베이스를 게시자로 및 SSEE 데이터베이스로 구독자로 사용합니다. Access Jet Replication과 달리 PK 번호 매기기를 제어 할 수 있지만 가입자가 변경 사항을 추진하지 않으므로 문제가되지 않습니다.
SQL Server가 가져올 확장 성 외에도 Windows Synchronization Manager를 사용하여이를 자동화 할 수 있습니다 (동기화 된 폴더가있는 경우 로그온/로그 오프 할 때 팝업하고 동기화하는 성가신 작은 상자입니다). 주어진 간격, 시작, 종료 또는 하루에 동기화 및/또는 컴퓨터가 유휴 상태 일 때 또는 주문형에서만 동기화됩니다. 한 달 동안 액세스가 실행되지 않더라도 사용자가 네트워크에 연결할 때마다 데이터 세트를 업데이트 할 수 있습니다. 아주 멋진 것들.
다른 팁
액세스 복제는 어색 할 수 있으며, 점검을 통해 쿼리 만 필요하므로 스스로 글을 쓰는 것이 가장 좋습니다. 각 랩톱에서 수집 한 데이터가 겹치지 않으면 너무 어려울 수 있습니다.
기본 키를 고려해야합니다. 레코드가 올바르게 관련되도록 사용자 또는 노트북 이름을 키에 통합하는 것이 가장 좋습니다.
이 스레드의 답변은 분명히 사용하지 않았으며 들었던 것들을 반복하는 사람들의 제트 복제에 대한 잘못된 정보로 가득 차 있거나 실제로 애플리케이션 설계 오류를 반영하는 제트 복제로 문제를 일으키고 있습니다.
액세스에 내장 된 제트 복제를 사용할 수는 있지만, 나는 당신에게 경고 할 것입니다.
제트 복제는 Flakey가 아닙니다. 다른 복잡한 도구와 마찬가지로 제대로 사용하면 완벽하게 신뢰할 수 있습니다. 복제되지 않은 데이터베이스에 문제가 발생하지 않는 특정 사항이 복제 될 때 문제로 이어질 수 있지만, 이는 복제의 특성 때문에 추론을 겪는 것은 사실입니다. 어느 데이터베이스 엔진에는 수반됩니다.
또한 주요 충돌을 피하기 위해 임의의 서명 정수를 선택하기 때문에 PK를 엉망으로 만들 것입니다. 따라서 주어진 레코드의 다음 PK로 -1243482392912로 끝날 수 있습니다. 그것은 당신이 어떤 종류의 조회를하고 있다면 (고객 ID, 주문 번호 등)를 입력하는 pita입니다.
대리 Autonumber PKS는 처음에 사용자에게 노출되어서는 안됩니다. 그들은 무대 뒤에서 레코드에 가입하는 데 사용되는 무의미한 숫자이며, 사용자에게 노출되면 응용 프로그램 디자인의 오류입니다.
시퀀스 번호가 필요한 경우 직접 굴러 가서 복제품 간의 충돌을 방지하는 방법에 대한 문제를 처리해야합니다. 그러나 그것은 복제의 문제입니다 어느 데이터베이스 엔진. SQL Server는 데이터베이스 엔진 수준에서 개별 복제본에 대한 시퀀스 번호 블록을 할당하는 기능을 제공하며 정말 좋은 기능이지만 여러 SQL Server 인스턴스를 유지 관리하는 데있어 관리 오버 헤드가 증가하는 비용이 발생합니다 (모든 보안 및 성능 문제 포함 그것은 수반됩니다). Jet Replication에서는 코드 로이 작업을 수행해야하지만 복잡한 문제는 아닙니다.
또 다른 대안은 하나의 열이 소스 복제본을 나타내는 화합물 PK를 사용하는 것입니다.
그러나 이것은 JET의 복제 구현에서 약간의 결함이 아닙니다. 의미있는 시퀀스 번호가 필요한 복제 시나리오의 문제입니다.
액세스 동기화를 자동화 할 수는 없습니다 (VBA를 사용하여 같은 것을 가짜로 만들 수 있습니다. 그러나 여전히 데이터베이스가 열릴 때만 실행됩니다).
이것은 특허 적으로 사실이 아닙니다. Jet Synchronizer를 설치하면 Synchs (Direct, Indirect 또는 Internet Synchs)를 예약 할 수 있습니다. 그것 없이도 주기적으로 실행하고 동기화를 수행하도록 VBScript를 예약 할 수 있습니다. 이들은 액세스 애플리케이션을 열 필요없이 자동화 된 제트 동기화를 수행하는 두 가지 방법입니다.
MS 문서의 견적 :
제트 및 복제 객체를 사용하십시오
JRO는 제트 복제를 관리하는 가장 좋은 방법이 아닙니다. 우선, DAO 자체가 부족한 기능은 단 하나의 기능을 가지고 있습니다. 그러나 앱에 종속성을 추가하려면 (JRO는 참조가 필요하거나 늦은 바인딩을 통해 사용될 수 있음) 제트 복제 제어를위한 진정한 유용한 라이브러리에 의존성을 추가 할 수도 있습니다. TSI Synchronizer, Michael Kaplan이 만든 Jet Replication에 대한 세계 최고의 전문가 (이후 그의 집중 영역으로 국제화로 옮겼습니다). 스케줄링 스케줄링, 모든 종류의 동기화 시작 및 매우 필요한 Movereplica 명령 (복제를 중단하지 않고 복제본을 이동하거나 바꾸는 유일한 법적 방법)을 포함하여 제트가 노출하는 거의 모든 복제 기능을 완전히 프로그래밍 방식으로 제어합니다.
JRO는 Microsoft의 중단 된 Ado-ee-ee-Everwhere 캠페인의 추악한 의붓 자식 중 하나입니다. 그 목적은 제트 특정 기능을 제공하여 Ado 자체에서 지원되는 것을 보충하는 것입니다. ADO를 사용하지 않는 경우 (제트 백엔드가있는 액세스 앱에 있지 않아야 함) JRO를 사용하고 싶지 않습니다. 위에서 말했듯이 DAO에서는 아직 사용할 수없는 한 가지 기능 만 추가합니다 (즉, 간접 동기화를 시작). 나는 제트 특정 기능을위한 독립형 라이브러리를 만들어 Microsoft가 뚜렷하다고 생각할 수는 없다고 생각합니다. 그런 다음 그들이 선택했을 때 지원할 수있는 모든 유용한 기능을 의도적으로 제외시킵니다.
이제 위에서 제시 한 답변에 잘못된 주장을 처분 했으므로 여기에 내 추천이 있습니다.
부록 전용 인프라가 있기 때문에 @remou가 추천 한 내용을 수행하고 새로운 레코드가 갈 때마다 수동으로 보내기 위해 무언가를 설정하십시오. 그리고 그는 제트 복제를 사용했던 것처럼 PK 문제를 여전히 다루어야한다는 것이 옳습니다. 이는 여러 위치에 새 레코드를 추가 해야하는 요구 사항에 의해 필요하며 모든 복제/동기화 응용 프로그램에 공통적이기 때문입니다.
그러나 한 가지주의 사항 : 향후 추가 전용 시나리오가 변경되면 삭제 및 업데이트를 관리하기 위해 처음부터 시작하여 처음부터 시작하거나 많은 털이 많은 코드를 작성해야합니다 (이것은 쉽지 않습니다-나를 믿으십시오. '내가 해냈어!). 제트 복제를 사용하는 것만으로도 한 가지 장점 (양방향 동기화에 가장 가치가 있지만 여러 위치에서 편집)이 문제없이 추가 전용 시나리오를 처리 한 다음 전체 병합 복제를 쉽게 처리해야한다는 것입니다. 미래의 요구 사항.
마지막으로, 제트 복제로 시작하기에 좋은 곳은 제트 복제 위키. 자원, 모범 사례 및 페이지를 믿지 않는 것이 아마도 가장 좋은 곳일 것입니다.
당신은 읽어야합니다 입장 데이터 베이스 복제, 거기에 몇 가지 정보가 있기 때문입니다.
하지만 내 생각에는 이것이 귀하의 애플리케이션에서 올바르게 작동하려면 다음을 사용하여 맞춤형 솔루션을 출시해야 할 것입니다. 사용 가능한 메서드 및 속성 그 목적을 위해.
Microsoft Access 데이터베이스(.mdb 파일만 해당)의 복제 세트 구성원 간의 데이터 및 디자인 정보 교환을 프로그래밍 방식으로 제어해야 하는 경우 JRO(Jet 및 복제 개체)를 사용합니다.예를 들어 JRO를 사용하면 사용자가 데이터베이스를 열 때 사용자의 복제본을 나머지 집합과 자동으로 동기화하는 프로시저를 작성할 수 있습니다.프로그래밍 방식으로 데이터베이스를 복제하려면 데이터베이스를 닫아야 합니다.
Microsoft Access 97 이하 버전으로 데이터베이스를 만든 경우 DAO(데이터 액세스 개체)를 사용하여 데이터베이스를 프로그래밍 방식으로 복제하고 동기화해야 합니다.
DAO 메서드와 속성을 사용하여 이전 버전의 Microsoft Access에서 복제된 데이터베이스를 만들고 유지 관리할 수 있습니다.복제 세트 구성원 간의 데이터 및 디자인 정보 교환을 프로그래밍 방식으로 제어해야 하는 경우 DAO를 사용하십시오.예를 들어 DAO를 사용하면 사용자가 데이터베이스를 열 때 사용자의 복제본을 나머지 집합과 자동으로 동기화하는 프로시저를 작성할 수 있습니다.
다음 방법과 속성을 사용하여 복제된 데이터베이스를 생성하고 유지 관리할 수 있습니다.
MakeReplica방법Synchronize방법ConflictTable재산DesignMasterID재산KeepLocal재산Replicable재산ReplicaID재산ReplicationConflictFunction재산Microsoft Jet는 부분 복제본(전체 복제본의 레코드 하위 집합을 포함하는 복제본)을 만들고 유지 관리하기 위한 다음과 같은 추가 방법과 속성을 제공합니다.
ReplicaFilter재산PartialReplica재산PopulatePartial방법
꼭 읽어보세요 데이터 동기화 문서의 일부.
A07로 업그레이드 할 때까지 A00의 복제를 몇 년 동안 사용했습니다 (사라질 때). 우리가 기업 수준에서 가장 문제가되는 문제는 갈등. 적시에 관리되지 않았거나 너무 많은 경우 사용자가 좌절하고 데이터를 신뢰할 수 없게됩니다.
복제는 잘 작동했습니다 원격 사이트가 항상 인터넷에 연결된 것은 아닙니다. 이를 통해 데이터로 작업하고 가능할 때 동기화 할 수있었습니다. 적어도 2 회 매일.
동기화를 관리하는 원격 컴퓨터에 별도의 데이터베이스를 설치하므로 동기화를 불러 일으키기 위해 데스크탑의 아이콘 만 클릭해야했습니다.
사용자는 레거시 시스템에서 업데이트되는 지정된 FTP 파일을 피드를 푸시/당기는 별도의 버튼이있었습니다.
이 프로세스는 전국에서 30 개의 "노드"가 작동하여 데이터를 관리하고 FTP 서버로 업데이트했기 때문에 상당히 잘 작동했습니다.
이 길을 진지하게 고려하고 있다면 알려 주시면 내 문서를 보낼 수 있습니다.
랩탑에 연결하고 DB에서 차이점을 선택하여 마스터에 삽입하는 동기화 소프트웨어를 직접 작성할 수 있습니다.이 작업이 얼마나 쉬운지는 데이터 구성표에 따라 다릅니다.(FK가 포함된 테이블이 많은 경우...현명하게 수행해야 합니다).직접 작성해 보시는 게 가장 효율적일 것 같아요.
이러한 종류의 동작을 자동화하는 것을 복제라고 하며, 액세스 지원 그럴 것 같지만 구현되는 것을 본 적이 없습니다.
대부분의 경우 랩탑이 메인 DB에 연결되어 있지 않은 경우 (데이터를 복제하는 것)는 좋은 생각이 아닙니다.
이를 수행하기 위한 타사 도구를 찾으려면 복사하기 전에 테이블 간 차이점을 쉽게 수행할 수 있고 점진적으로 수행할 수 있는 도구를 찾으십시오.
fwiw :
- 자가 숫자. 나는 다윗과 동의합니다 - 그들은 결코 노출되어서는 안됩니다. 그 유혹을 제거하기 위해 나는 임의의 자동 너버를 사용합니다.
- 복제. 나는 이것을 몇 년 전, 예약 된 동기화와 PK로 안내를 사용하여 이것을 광범위하게 사용했습니다. 나는 네트워크 위의 딸꾹질이 복제본을 손상 시켰으며, 결과적으로 데이터를 구제하고 복제본을 재발행해야한다는 것을 반복적으로 발견했습니다. 괴로운!
