Access 2007에서 Ado 또는 DAO를 사용하는 것이 더 낫습니까?

https://stackoverflow.com/questions/1039224

22-07-2019
|

문제

Access 2007에서 새 데이터베이스를 작성할 때 Ado (ActiveX Data Objects) 또는 DAO (데이터 액세스 개체)를 사용해야합니까?

편집 :이 데이터베이스의 일부는 Excel 2007 스프레드 시트에서 데이터를 가져 오는 것입니다.

해결책

레코드의 경우, 한때 '제트'의 공식 이름은 이제 '액세스 데이터베이스 엔진'입니다.

ACE (Access2007 Engine .accdb 형식) 기능의 경우 Acedao 여야합니다.

Jet 4.0 기능의 경우 Ado Classic이어야합니다.

Jet 3.51 기능과 이전의 경우 Ado 또는 DAO를 선택하십시오. 두 가지 모두에 장점과 단점이 있습니다. 대부분의 액세스 데이터베이스 엔진 기능은 둘 다에 공통적입니다. 상호 배타적 인 기능은 논쟁의 여지가 있습니다. 라이프 스타일 선택은 아마도 큰 문제가 아닙니다. 스마트 코더는 두 가지 중 최고를 사용합니다 :)

나는 상당히 조금 사용했고 Ado는 개인적 선호도입니다. 그것은 DAO보다 현대적이므로 건축 적으로 개선입니다. 더 평평한 객체 모델, DAO의 찢어지지 않은 문제 등은 더 많은 속성과 방법과 이벤트가 소개됩니다 (DAO는 비동기 연결 및 레코드를 가져옵니다. ADO 레코드 세트는 연결이 끊어지고 계층 적이며 제조 될 수 있으며 DAO 레코드 세트는 할 수 없습니다. 기본적으로 그들은 DAO에 대해 좋은 일을했고 더 좋게 만들었습니다.

Dao는 강한 점수가 없습니다. 우선, Access/Jet의 Ado보다 더 많은 DAO 코드 예제를 찾을 수 있습니다.

추신, 어떤 이유로, Dao를 좋아하는 사람들은 정말로 Ado를 싫어합니다. 선전을 무시하십시오. Ado는 더 이상 사용되지 않습니다. ACE에는 OLE DB 제공 업체가 있으며 현재 ACE를 64 비트로 사용하는 유일한 방법입니다. Ado.net은 VB.net보다 Access 프로젝트에서 VBA6을 대체 한 ADO Classic을 대체하지 않았습니다.

편집 : "Jet 4.0 기능의 경우 Ado Classic이어야합니다."DAO 3.6은 Jet 4.0에 새로운 기능에 대한 몇 가지 개선 사항 만 받았기 때문입니다. 예를 들어, DECIMAL 데이터 유형 스케일/정밀도를 지정할 수 없습니다. 다른 기능은 DAO에서 완전히 누락되었습니다. 예를 들어, DAO (또는 그 문제에 대한 ACE의 Acedao)를 사용하여 Jet 4.0에서 다음을 수행 할 수 있습니까?

CREATE TABLE Test (
   col1 CHAR(4) WITH COMPRESSION DEFAULT '0000' NOT NULL, 
   CHECK (NOT EXISTS (
                      SELECT T1.col1 
                        FROM Test AS T1 
                        WHERE T1.col1 <> '0000' 
                        GROUP 
                           BY T1.col1 
                       HAVING COUNT(*) > 1
                      ))
);

(힌트 : 테이블 레벨 데이터 무결성 제약 조건이있는 압축 가능한 고정 폭 텍스트 열.) 아니요.

Afaik Acedao의 유일한 개선 사항은 새로운 ACE 기능을위한 것이 었습니다. 그리고 왜 그들은해야합니까? 우리는 여전히 격차를 막기 위해 고민합니다. 팀이 그 성가신 수정과 같이 더 생산적으로 시간을 보냈습니다. DECIMAL 정렬 버그, 나에게 에이스에 대한 가장 좋은 점 ;-)

다른 팁

DAO는 여기에서 권장되는 기술입니다. Ado는 감가 상각이 많았으며 현재 Ado.net으로 교체되고 있습니다.

DAO는 MS 액세스를 사용하기위한 기본 및 권장 데이터 객체 모델 일뿐 만 아니라 계속 향상되고 있으며 이제 SharePoint에 대한 새로운 기능이 많이 있습니다. Access 2007에서 우리는 이제 SharePoint 목록을 지원합니다. 이는 2007 년의 새로운 DAO 객체 모델을 통해 SharePoint 목록을 SQL 서버 테이블로 사용하고 볼 수 있음을 의미합니다. 즉, SharePoint 목록에서 SQL을 사용할 수 있음을 의미합니다 (FAC에는 SharePoint 목록을 사용할 수있는 OLEDB 제공 업체도 없지만 DAO를 사용하면 이제 수행 할 수 있습니다). Ado에 추가 된 이런 종류의 것은 없습니다. 따라서 SharePoint는 Access (Access) Point of View의 목록에서 이러한 SharePoint 목록을 표준 테이블로 본다.

또한 Access의 DAO는 복잡한 데이터 유형이라고 부르는 것을 지원합니다. 이것은 SharePoint의 XML 목록을 지원하기 위해 수행되었습니다. 다음 버전의 Access (2010)에 대해서는 DAO에 추가 된 새로운 추가 기능이 추가되는 것을 보게 될 것입니다 (Jet는 이제 ACE라고합니다).

따라서 DAO가 사용하기에 올바른 좋은 모델이라는 것은 의심의 여지가 없습니다. Ado는 더 이상 개선되지 않았으며 Ado.net에 의해 대체되었습니다.

따라서 미래는 DAO에 속하며 Microsoft가 MS 액세스 및 SharePoint 작업에 대한 액세스를 업그레이드하는 조건으로 돈을 투자하는 것이 분명합니다.

Access 2007은 필드 정의에 대한 다중 값 기능을 받았으며, 이는 다시 SharePoint를 지원하기위한 향상의 결과였습니다. 그러나 이러한 기능은 JET의 일부이며 이러한 개선 사항은 SharePoint없이 사용할 수 있습니다. 그들은 이제 DAO의 일부입니다.

편집 : 아마도 나는 이것을 조금 확장하고, 우리가 여기에 반대되는 답변이 무엇인지 명확히하려고 노력할 것입니다. Access 2007을 사용할 때 DAO를 사용하는 것이 훨씬 낫다는 것을 확신 할 수 있습니다.

혼란이 발생하는 경우, 기본 데이터 객체 모델 액세스 2007을 사용할 때 도구 참조를 보면 여기서 문제는 더 이상 DAO라고 불리지 않는다는 것입니다. 이제 에이스라고합니다.

ac MS-Access에서 DAO를 사용할 때 새로운 참조가 다음을 알 수 있습니다.

Microsoft Office 12.0 액세스 데이터베이스 엔진 객체 라이브러리

이제 위는 약간의 입이 가득 차 있지만, 위는 Ado 대신 DAO를 사용할 때 참조 액세스 2007에 맞습니다.

다시 말해, 아마도 우리는 이것을 DAO II라고 부를 것입니다.

다시 말해,이 데이터 엔진은 계속 향상되며,이 엔진의 64 비트 버전을 Office 2010 (Office 14)을 가장 잘 볼 수 있습니다.

따라서 질문이나 혼란은 Access 2007에서 DAO를 사용하는 것을 언급 할 때 어떤 용어를 사용할 것인지에 중점을두고 있습니다. 여기서 혼란은 실제로 문서와 도구조차도 DAO라고 부르지 않는다는 것입니다.

Access 2007의 하루가 끝나면 DAO를 사용하려는 경우 위의 참조를 설정하고 DAO 3.6에 대한 참조를 설정하지 않음을 의미합니다. 어쨌든, ADO가 감가 상각 될 때 ADO를 사용하기 시작하는 것은 전혀 의미가 없으며, Access를위한 새로운 DAO 객체 모델은 Microsoft에 의해 계속 향상되고 투자되고 있습니다.

나는 이것이 혼란스러운 것을 정리하는 데 도움이되기를 바랍니다. DAO/JET는 감가 상각되고 있지만 새로운 버전 Access 2007은 동일한 코드 기반을 기반으로합니다. 따라서 액세스의 새로운 데이터 엔진을 고려하고 새로운 DAO 객체 모델이라고 할 수 있습니다.

나는 현재이 문제에 대해 NDA 아래에 있지만 다음 버전의 Office (2010)에 대해 다시 한 번 향상된 개선 사항을 볼 수 있다고 말할 수 있습니다.

따라서 액세스 개발자들 사이에서 액세스 애플리케이션을 개발하고 기본 데이터 엔진을 사용할 때 선호하는 것은 DAO 객체 모델을 사용하는 것입니다 (그러나 더 이상 ACE라고 부르는 것을 명심하십시오).

질문에 대한 답은 당신이하는 일에 달려 있습니다. ADO 인터페이스가 더 다재다능한 형식의 데이터를 사용하여 작업을 사용하는 경우 ADO를 사용하십시오. Jet Data를 사용하거나 Jet Database Engine을 사용하여 ODBC를 통해 다른 데이터베이스 엔진과 함께 작동하는 경우 DAO가 올바른 선택입니다.

그러나 그 대답은 당신이 액세스에서 일하고 있다고 가정합니다. 다른 프로그래밍 환경에서 일하고 있다면 답이 완전히 다를 수 있습니다.

그것은 당신의 필요에 따라 다릅니다. 어느 도구도 곧 사라질 것으로 예상되지 않습니다.

Ado 또는 Dao에 대한 경험이 없다면 Dao가 훨씬 쉽고 훨씬 쉽습니다. 따라서 Ado가 필요하지 않으면 Dao를 사용하십시오.

이 중요한 항목을 추가했습니다. "외부 소스에서 액세스 DB로 데이터를 가져 오려고합니다." 이 연결은 Ado가 필요할 수 있습니다.

ADO는 현재 권장 액세스 방법입니다. 나는 DAO가 꽤 많은 수년 동안 더 이상 사용되지 않았다고 생각합니다.

Access 2000 이후 -에 따르면 이 링크,

쓸모없는 데이터 액세스 기술 목록 - http://msdn.microsoft.com/en-us/library/ms810810.aspx#mdac 기술 로드맵 Old_topic9

2008 년 12 월 개정 된 위의 기사에서 인용 - "DAO (Data Access Objects) : DAO는 Jet (Access) 데이터베이스에 대한 액세스를 제공합니다.이 API는 Microsoft Visual Basic, Microsoft Visual C ++ 및 스크립팅 언어에서 사용할 수 있습니다. Microsoft Office 2000 및 Office Xp. DAO 3.6에는이 기술의 최종 버전이 포함되어 있습니다. 64 비트 Windows 운영 체제에서는 사용할 수 없습니다. "

Dao는 Ado에 비해 성능 측면에서 흔들리는 것입니다. 비교가 없습니다.

이것이 의견이되었을 때 (담당자가 없음) 대답이라고 사과하지만 DAO/Acedao가 Jet 4.0 레코드 잠금을 지원하지 않는다는 잘못된 주장을 정리하고 싶었습니다. 그것은 특정 MS 기사가 주장하는 것에 관계없이 기본 동작입니다.

문제는 DAO 편집/업데이트를 사용할 때 거대한 팽창 (엄청나게 단편화 된 DB 파일)을 소개 할 수 있으며 DAO/Acedao에서는 꺼질 수 없다는 것입니다.

이 문제가있는 경우 올바른 Jet OLEDB : 데이터베이스 잠금 모드 설정을 사용하여 OLEDB 연결을 통해 먼저 데이터베이스를 열어서 데이터베이스를 끄면 데이터베이스를 페이지 수준 잠금으로 설정할 수 있습니다. 이 속성은 결과적으로 연결, DAO 또는 다른 방식으로 존중되므로 빠른 업데이트 등 DAO를 사용할 수 있습니다.

그러면 DAO는 SQL 문을 실행하는 것과 비교하여 일반적인 8 배의 성능으로 되돌릴 수 있습니다.

다음은 문제를 가리키는 몇 가지 링크입니다.

Acedao는 행 레벨 잠금을 지원합니까?

http://www.access-programmers.co.uk/forums/showthread.php?t=47040

MS KB 기사 (ADO로 잠금 모드 설정 코드를 포함한 MS KB 기사, 해당 DB에서 DAO를 사용합니다. http://support.microsoft.com/?id=306435

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow