MS Access를 MySQL 데이터베이스 백엔드의 프런트 엔드로 사용하는 데 문제가 있습니까?

Question

두 명의 사용자가 원래 하나의 MDB 파일을 통해 서로 충돌하지 않고 MS Access로 작성된 동일한 데이터베이스를 공유하려고했습니다.

테이블을 간단한 MS Access 데이터베이스에서 Migration Toolkit (잘 작동 함)을 사용하여 MySQL로 옮기고 Access를 설정하여 ODBC를 통해 테이블에 연결하도록했습니다.

지금까지, 나는 다음에 실행했습니다 :

• 당신은// 업데이 트를 삽입 기본 키 (이 놀람)없이 테이블의 행을 삭제할 수 없습니다.
• MS Access의 일련 번호 필드가 기본 키 여야합니다. 그렇지 않으면 MySQL에서 정수 열로 끝납니다. (natch, PK가 아닌 이유는 무엇입니까?)
• 테이블이 MySQL의 InnoDB 테이블 유형으로 마이그레이션되었습니다. , 그러나 Access 관계는 MySQL 외래 키 제약 조건이되지 않았습니다.

일단 데이터베이스가 사용 중이면 다른 문제가 있습니까? 특히 두 사용자가 같은 테이블에서 작업 할 때?

Answer 1

MySQL 백엔드에 대한 MS 액세스 프론트 엔드와 마찬가지로 작동하는 응용 프로그램이 있습니다. 필자는 Win32 프론트 엔드를 작성하는 데 엄청난 고통을 겪었습니다.내 머리 꼭대기에서 다음과 같은 문제가 발생했습니다.

• ODBC 링크 개발은 오래 전에 끝난 것처럼 보입니다. 주위에는 다양한 버전이 있습니다. 매우 혼란 스럽습니다. ODBC 링크는 유니 코드/UTF8을 지원하지 않으며 다른 문제도있었습니다 (일부는 신중한 구성으로 극복 할 수 있음).
• MS Access와 호환되도록 db 스키마를 수동으로 조정할 수도 있습니다.
• MySQL 데이터베이스의보다 정교한 SQL 조작을 수행하려면 통과 쿼리를 사용해야 할 수도 있음을 명심해야합니다.
• VBA를 많이 사용하면 프론트 엔드 파일이 손상 될 수 있으므로주의하십시오. 데이터베이스를 정기적으로 압축합니다 (주 메뉴, 도구 | 데이터베이스 유틸리티 | 압축 및 복원, 또는 그와 유사한 것 --- 네덜란드어 버전 사용) 백업을 많이 만들려면이 필요합니다.
• 액세스는 네트워크 트래픽을 많이 발생시키는 경향이 있습니다. 진짜로 거대한 제비 같이. 나는 그것을위한 해결책을 찾을 수 없었다. 네트워크 모니터를 사용하는 것이 좋습니다.
• 액세스는 부울 값을 0/-1로 저장하려고합니다. IMHO, 0/+ 1이 더 의미가 있으며, MySQL에서 기본 작업 방식이라고 생각합니다. 큰 문제는 아니지만 확인란이 작동하지 않는 경우 반드시 확인해야합니다.

하나의 가능한 대안은 백엔드 (데이터 포함)를 공유 드라이브에 넣는 것입니다. 나는 이것이 잘 문서화되어 있다는 것을 기억한다. some general advice on splitting into a frontend and a backend과 code that automatically reconnects to the backend on startup을보고 싶을 수 있습니다. 좀 더 많은 샘플 코드를 보내거나 여기에 게시 할 수도 있습니다.

그렇지 않으면 MS SQL을 고려할 수도 있습니다. 나는 그것에 경험이 없지만, 나는 MS Access와 함께 훨씬 더 잘 작동한다고 생각한다!

Answer 2

나는 이것이 귀하의 질문에 직접적으로 대답하지 않는다는 것을 알고 있지만, SQL Server 2005 migration tool for Access을 확인해 보는 것이 좋습니다. 필자는이 도구를 사용한 적이 없지만 SQL Server 2005 Express Edition을 사용하여 MySQL과 동일한 문제가 있는지 확인할 가치가 있습니다.

Answer 3

두 명의 사용자 만 액세스 할 수 있다면 다음과 같이하십시오. .mdb를 공유 드라이브에 놓습니다.

문제가 있다고 가정하기보다는 먼저 시도해 보셨습니까?

나는 최대 동시 접속 사용자 수는 5 명이라고 생각하지만, 때때로 이것을 지나치게 밀어 붙였습니다.

다른 한편으로는 단일 사용자 환경 (나)에서 MySQL에 대한 프런트 엔드로 Access를 한 번 사용했습니다. 그것은 유일하게 불쾌한 경험이었고, 두 명의 사용자가 더 좋을 것이라고 상상할 수는 없습니다.

Answer 4

는 일반적으로, 의존 : 응용 프로그램 측 그냥 양식을 통해 데이터를 업데이트되었을 때

내가 많은 문제가 없었어요. 둘 이상의 사용자가 동일한 행을 업데이트하면 경고/오류가 발생할 수 있습니다. 하지만 Access는 지속적으로 라이브 레코드 세트를 항상 업데이트하고있는 것으로 보입니다.

앨리스가 이미 레코드 365로 작업하고 있고 Bob이이를 업데이트 한 다음 앨리스가 변경 사항으로 앨리스를 업데이트하려고하면 문제가 발생할 수 있습니다. 내가 기억 하듯이, Alice는 암호 오류 메시지를받습니다. 이러한 오류를 잡아 내고 적어도 사용자에게 친숙한 오류 메시지를 제공하면 사용자가 더 쉬울 것입니다.

레코드 세트를 통해 VB 코드에서 레코드를 편집 할 때 특히 폼에 같은 데이터를 편집 할 때 더 많은 문제점이있었습니다. 반드시 다중 사용자 문제는 아닙니다. 그러나 동일한 데이터에 대해 여러 개의 연결이있는 한 명의 사용자가 있기 때문에 거의 동일한 상황이 발생합니다.

Answer 5

가레스 심슨 의견을 말했다 :

는 두 사용자가 있다면, 당신은 공유 드라이브에 .MDB를 넣어 경우 이 잘해야 액세스 할 수 있습니다.

어, 아니오. 각 사용자가 프런트 엔드의 전용 사본을 가져서는 안되는 다중 사용자 액세스 응용 프로그램은 없습니다. 이는 각 사용자가 워크 스테이션에 MDB를 가져야 함을 의미합니다. 왜? 프런트 엔드의 개체가 잘 공유되지 않기 때문에 (이 시나리오에서는 MySQL을 백 엔드로 사용하지는 않지만 거의 Jet 데이터 테이블이 아닙니다.)

가레스 심슨 계속 :

내가 액세스를 위해 권장되는 최대 동시 사용자가 I이 과거를 밀어 떨어진 오지 않을 한 때 5 만 믿습니다.

아니요, 이것은 완전히 잘못되었습니다. MDB 사용자의 이론적 인 한계는 255입니다. 당연히 현실적인 것은 아닙니다. 약 20 명의 사용자가되면 Access App을 잘 작동하도록 신중하게 프로그래밍해야하기 때문에 (Access-to- Jet 응용 프로그램은 서버 데이터베이스 응용 프로그램을 효율적으로 만드는 것과 동일한 종류입니다 (예 : 사용 가능한 가장 작은 데이터 집합 검색).

이 경우 각 사용자는 프런트 엔드 MDB의 개별 복사본이 있어야하므로 Access/Jet의 다중 사용자 제한은 전혀 관련이 없습니다.

Answer 6

각 레코드에 날짜/시간 스탬프를 넣지 않아도됩니다. 때때로 MS 액세스는 "다른 사용자가 레코드를 변경 또는 삭제했습니다"라고 생각하여 변경을 허용하지 않습니다! 나는 이것을 어려운 방법으로 찾아 냈다.

Answer 7

나는이 주제에 너무 신선한 아니라는 것을 알고 있지만, 단지 몇 가지 추가 설명 :

• : 당신이 특히 큰 함께 효과적으로 MS 액세스를 사용하려면

  는 다중 사용자 데이터베이스의 경우, 다음을 수행하십시오

  은 MDB를 프론트 엔드 애플리케이션과 백엔드 (데이터 전용) 파일로 분리합니다. 두 개의 별도 MDB 파일이 있습니다.

• 데이터 및 구조가있는 모든 테이블을 외부 데이터베이스로 마이그레이션하십시오. 그것은 다음과 같습니다 : MySQL (매우 잘 작동하고 데이터베이스 크기 제한이 없으며 MS 기술이 아니기 때문에 더 많은 기술이 필요합니다. 그러나 많은 경우에 좋은 선택입니다. 또한 더 많은 RAM과 추가 CPU로 백엔드를 확장 할 수 있습니다. 요구 사항 및 하드웨어 기능에 따라 다름). 오라클 (돈이 충분하거나 기업 라이센스가있는 경우) 또는 Oracle 10g XE (문제가되지 않는다면 데이터베이스 크기가 최대 4GB로 제한되며 항상 1GB의 RAM과 1 개의 CPU가 사용됩니다) MS SQL Server 2008 (모든 경우에 MS Access 프론트 엔드 및 MS SQL Server 백엔드를 보유하는 훌륭한 조합이지만 라이센스를 지불해야합니다! - 장점 : 밀접한 통합, 두 기술이 모두 동일한 벤더를 형성 함, MS SQL Server 동시에 효과적으로 유지하기가 쉽습니다) 또는 Express Edition (Oracle XE와 같은 이야기 - 거의 동일한 제한 사항).

• MS Access 프론트 엔드를 백엔드 데이터베이스로 다시 연결하십시오. 백엔드 용 MS SQL Server를 선택한 경우 MS Access의 마법사를 사용하는 것만 큼 쉽습니다. MySQL의 경우 - ODBC 드라이버를 사용해야합니다 (간단하고 매우 효과적입니다). Oracle의 경우 - Microsoft의 ODBC 드라이버를 사용하지 마십시오. 오라클에서 제공하는 이들의 작업이 훨씬 더 효과적입니다 (Oracle ODBC 및 MS Oracle ODBC 드라이버를 통해 MS Access에서 SQL 쿼리를 실행하는 데 필요한 시간을 Oracle과 비교할 수 있습니다). 이 시점에서 견고한 데이터베이스 백엔드와 완전한 기능의 MS Access 프론트 엔드 인 MDB 파일을 갖게됩니다.

• MDB 프론트 엔드를 MDE로 컴파일하면 많은 속도를 낼 수 있습니다. 또한 MS Access 애플리케이션을 최종 사용자에게 배포하는 유일한 합리적인 형태입니다.

• (매일 작업) - MS Access 프론트 엔드에서 MDE 파일을 사용하십시오. 더 많은 미시시피 액세스 프론트 엔드 개발 MDB 파일을 사용하십시오.

• 악의적으로 작성된 ActiveX 구성 요소를 사용하여 MS Access 프론트 엔드 기능을 향상시키지 마십시오. 자신에게 더 잘 쓰거나 적절한 것을 구입하십시오.

• MS 액세스에 많은 문제가 있다는 신화를 믿지 않습니다. 이것은 때로는 도움이 될 수있는 훌륭한 제품입니다. 문제는 많은 사람들이 그것이 장난감이라고 생각하거나 MS Access가 일반적으로 간단하다고 가정합니다. 일반적으로 그들은 많은 오류와 문제점을 스스로 생성하고 지식과 경험이 부족합니다. MS Access에서 성공하려면이 도구를 이해하는 것이 중요합니다. 이는 다른 기술과 마찬가지로이 규칙과 같습니다.

나는 MySQL 백엔드에 상당히 앞선 MS Access를 사용하고 있으며 (이 응용 프로그램을 유지 관리하는 개발자로서) 매우 만족한다고 말할 수 있습니다.내 친구, 사용자는 GUI (프론트 엔드), 속도 (MySQL)에 매우 익숙해졌으며 레코드 잠금 또는 데이터베이스 성능에 대해 아무런 문제가 없으므로 만족합니다.

또한 훌륭한 사례와 다른 사람들의 경험에 대해 많이 읽는 것이 중요합니다. 나는 많은 경우에 MS Access가 좋은 해결책이라고 말할 것이다. 개인 전용 MS Access 데이터베이스 (MDB 파일)의 형태로 실험을 시작한 다음 분할 된 MS Access (MDE - 프론트 엔드, MDB - 백엔드) 및 마지막으로 MS Access 프론트 엔드로 발전한 많은 전용 사용자 정의 시스템을 알고 있습니다. (MDE) 및 "심각한"데이터베이스 백엔드 (주로 MS SQL Server 및 MySQL)가 있습니다. 또한 MS Access 솔루션을 항상 작동하는 프로토 타입으로 사용할 수 있다는 점도 중요합니다. 데이터베이스에서 백엔드를 사용할 준비가되어 있습니다 (MySQL은 가정합니다). 프론트 엔드를 원하는 기술로 다시 작성할 수 있습니다 (어쩌면 데스크탑 C# 응용 프로그램 - 당신이 필요로하는 것!).

나는 MS Access로 작업하는 것을 고려하는 데 도움이되기를 바랍니다.

감사합니다, Wawrzyn http://dcserwis.pl