MDAC (Microsoft Data Access Components)
UDA(Universal Data Access)는 여러 기업 환경의 정보에 접근하는 방법을 제공하기 위한 마이크로소프트의 전략이다. UDA는 다양한 정보 소스에 빠르게 접근할 수 있으며, 관계형 또는 비 관계형 데이터베이스를 모두 접근할 수 있다. 그리고 개발 툴과 개발 언어에 비 독립적이면서도 쉽게 인터페이스를 프로그래밍할 수 있도록 지원한다. 이 기술은 다양한 데이터 소스에 접근할 수 있으며, 쉽게 유지보수할 수 있는 솔루션을 제공하며, 개발 툴, 어플리케이션, 플랫폼 모두에 최상의 선택이 될 것이다.
UDA는 데이터 소스간의 이동에 소요되었던 많은 비용과 시간을 줄여주며, ODBC, RDO, DAO를 포함하는 차기 표준 인터페이스로 예상되고 있다.
MDAC(Microsoft Data Access Components)는 UDA를 지원하며, ADO(ActiveX Data Objects), Remote Data Service(RDS), OLE DB, ODBC(Open Database Connectivity) 그리고 OLE DB for OLAP을 포함하고 있다.
MDAC은 버전 1.0에서 시작하여 1.5, 2.0, 2.1 그리고 2.5 버전까지 발전되어 왔다. MDAC 1.0은 ODBC 3.0, ADO 1.0, ADC(Advanced Data Connector) 1.0 그리고 OLE DB 1.0을 포함하고 있었으며, 1996년에 발표되었다.
MDAC 1.5는 ODBC 3.5, ADO 1.0, OLE DB 1.5 그리고 RDS(Remote Data Service) 1.5를 포함하고 있었으며, 97년에 발표되었으며, 여러 번의 Minor 업그레이드(MDAC 1.5, MDAC 1.5a, MDAC 1.5b, MDAC 1.5c, MDAC 1.5d)를 거쳐왔다.
MDAC 2.0은 ODBC 3.51, OLE DB 2.0, ADO 2.0, RDS 2.0 그리고 OLE DB for OLAP을 포함하고 있었으며, 98년 말에 발표되었다. MDAC 2.0은 비주얼 스튜디오 6의 2번 CD에 포함되어져 있다. MDAC 2.1은 MDAC 2.0의 기능을 보안하여서 발표되었으며, MS SQL 서버 7.0에 포함되어져 있다.
MDAC을 사용할 때 주의해야 될 점은 MDAC을 포함하고 있는 프로그램을 설치하고 나면 MDAC의 버전이 변경되기 때문에 최신 버전의 MDAC으로 환경을 보전해 주어야 한다. 예를 들어, 비주얼 스튜디오 6.0을 설치했다면 MDAC은 2.0으로 변경된다. 그렇기 때문에 비주얼 스튜디오 6.0을 설치한 후에 다시 MDAC 2.1을 설치해 주어야 최신 버전의 MDAC을 사용할 수 있다.
Windows NT 4.0에서 옵션 팩을 다시 설치했다면 MDAC은 1.5로 변경된다. 이럴 경우에도 역시 MDAC 2.1을 다시 설치해야 한다.
MDAC 2.5는 99년 말에 Windows 2000과 함께 발표될 예정이며, MDAC 2.5는 Windows 2000의 시스템 레벨의 구성요소로 만들어졌다. 그렇기 때문에 Windows 2000에서는 MDAC을 별도로 설치할 필요 없이 Windows 2000 운영체제를 설치할 때 함께 설치하면 된다. 그리고 현재 MDAC 2.5에 대한 모습을 보려면 Windows 2000 베타 3를 설치해서 사용하면 된다.
그러면 MDAC에 포함된 5가지 구성요소에 대해서 간략하게 살펴본다.
- ODBC - Open Database Connectivity의 약어로서, MS SQL 서버, 오라클(Oracle),인포믹스(Informix), 사이베이스(Sybase), DB2 등의 관계형 데이터베이스에 접속하기 위한 인터페이스 규격이다. ODBC는 마이크로소프트에 의해서 제안되었으며, 현재로서는 대부분의 관계형 데이터베이스의 표준 인터페이스로 사용되고 있다. ODBC에 대응하는 것으로 IBM, 노벨(Novell), 워드 퍼펙 등과 같은 회사들이 연합하여 정의한 데이터베이스 인터페이스로는 IDAPI(Integrated Database Application Programming Interface)가 있다.
- ADO - ActiveX Data Object의 약어로서, 기존의 DAO(Data Access Object)와 RDO(Remote Data Object)를 대체하는 데이터 접속 개체이다. ADO에 대한 자세한 내용은 이 장의 2절에서 다루고 있다.
- OLE DB - Object Linking & Embedding Database의 약어로서, ODBC를 대체하는 기술로 부각되고 있는 마이크로소프트의 기술이다. OLE DB에 대한 자세한 내용은 이 장의 3절에서 다루고 있다.
- RDS - Remote Data Service의 약어로서, 웹 환경에서 데이터베이스를 조작하기 위한 마이크로소프트의 기술인 ADC(Advanced Database Connector)의 다음 버전이다. RDS에 대한 자세한 내용은 제 6부 User Interface 프로그래밍에서 다루고 있다.
- OLEDB for OLAP - Object Linking & Embedding Database for On Line Analytic Processing의 약어로서, MS SQL 서버의 일부인 Decision Support Service(코드명 Plato, OLAP Server)의 데이터를 조작하기 위한 기술이다.
ActiveX Data Object
ActiveX Data Object(ADO)는 마이크로소프트의 새로운 데이터 접속 개체로서 대부분의 데이터 형태를 접속해서 처리할 수 있도록 지원하고 있다. ADO는 로컬 데이터베이스 처리에 주로 사용된 DAO (Data Access Object)와 관계형 데이터베이스 처리에 주로 사용된 RDO(Remote Data Object)의 대부분의 기능을 지원하고 있으며, 기존의 데이터 관련 개체에서 지원하지 못하던 새로운 기능들도 추가로 지원하고 있다.
ADO는 MDAC(Microsoft Data Access Component)에 포함되어져서 배포되며, 비주얼 베이직 6에는 기본으로 ADO 1.5가 탑재되어 배포된다. ADO 1.0 버전은 RDO의 부분 기능만을 지원했으며, 주로 웹 프로그래머들에 의해서 사용되었다. 대부분의 웹 프로그래머들은 CGI(Common Gateway Interface)나 PERL(Practical Extraction and Report Language)을 이용해서 데이터베이스 관련 기능을 처리했으며, 일부 마이크로소프트의 SQL 서버를 사용하는 웹 개발자들은 IDC(Internet Database Connector)를 사용해서 데이터베이스를 처리했다. 하지만, IDC의 기능이 미비해서 웹 어플리케이션을 개발하는데 어려움이 많았으며, 이런 상황에서 ADO의 출현은 웹 프로그래머들에게 희소식이었다. 이렇게 ADO는 웹 개발자들에 의해서 처음 사용되어져 왔으며, ADO 1.5 버전은 DAO와 RDO의 대부분의 기능을 지원하게 되었고, 비주얼 스튜디오 6에 포함되었다. DAO와 RDO의 기능에 새로운 기능을 추가한 ADO 2.0은 98년 말에 발표되었으며, 마이크로소프트 SQL 서버 7.0에 포함되었다. 그리고 2000년 2월에 발표된 Windows 2000에 포함된 ADO 2.5는 Record와 Stream이라는 새로운 개체를 추가해서 새로운 모습으로 발표되었다.
[그림] ADO와 DAO/RDO 구조의 비교
ADO는 기존의 데이터 관련 개체에 비해서 다음과 같은 장점들을 가지고 있다.
- 적은 메모리를 요구하기 때문에 서버의 자원을 적게 사용한다.
- 인터넷과 인트라넷을 통한 데이터 접근에 최적화 되도록 구현되었기 때문에 네트워크에 부하를 적게 준다.
- 배치 커서(Batch Cursor), 클라이언트 커서(Client-Side Cursor), 서버 커서(Server-Side Cursor)를 포함해서 복합적인 커서를 지원한다
ADO를 이용하면 DAO나 RDO 보다는 간단하게 어플리케이션을 구축할 수 있다. 이유는 DAO나 RDO 는 계층적 구조로 이루어진 반면에 ADO는 내부의 개체들이 각각 독립적으로 존재하기 때문에 다른 개체와의 연결 없이도 데이터를 처리할 수 있기 때문이다. 하지만, 그런 ADO의 구조로 인해 적절한 방법을 선택해서 어플리케이션을 구축하기 위해서는 많은 노력과 지식이 필요하게 된다.
ADO는 마이크로소프트 비주얼 베이직, 엑티브 서버 페이지(Active Server Pages), 마이크로소프트 비주얼 C++, 마이크로소프트 엑세스(Access), 마이크로소프트 엑셀(Excel), 마이크로소프트 워드(Word) 그리고 ADO와 OLE DB를 지원하는 여러 개발 환경에서 사용할 수 있다.
ADO는 확장된 형태의 ADOX와 ADO MD를 지원한다. ADOX는 Data Definition Language와 Security를 처리하는 ADO의 확장된 형태로서 테이블과 저장 프로시저 같은 스키마 개체를 조작하고 개체에 대한 권한을 부여(Grant)하거나 회수(Revoke)한다. 비주얼 베이직과 같은 개발 도구에서 ADOX를 사용하려면 형식 라이브러리를 참조해야 한다. ADOX의 형식 라이브러리는 "Microsoft ADO Ext. for DDL and Security"이며, ADOX 라이브러리 파일 이름은 Msadox.dll이다. 그리고 프로그램 ID (ProgID)는 "ADOX"이다. 다음 그림은 비주얼 베이직 참조 메뉴에서 ADOX를 참조하는 화면이다.
[그림] ADOX 참조 화면
ADO MD의 MD는 Multidimensional Data의 약어이며, ADO MD는 OLAP 데이터와 같은 다차원의 스키마 또는 큐브(Cube)를 조회하거나 결과를 검색하기 위해 사용되는 구성요소이다. ADO MD를 사용하기 위해 OLE DB Provider는 OLAP(On Line Analytic Processing)을 지원하는 Multidimensional Data Provider(MDP)이어야 한다. 비주얼 베이직에서 ADO MD를 사용하려면 ADO MD 형식 라이브러리를 참조해야 한다. ADO MD의 라이브러리 파일 이름은 msadomd.dll이며, 프로그램 ID(ProgID)는 "ADOMD"이다. 다음 그림은 비주얼 베이직 참조 메뉴에서 ADO MD를 참조하는 화면이다.
[그림] ADO MD를 참조하는 화면
ADOX와 ADO MD에 대한 내용은 이 책에서 다루지 않으며, 자세한 정보는 Windows 2000의 Microsoft Platform SDK의 Data Access Services를 참조한다.
ADO 개체 모델
ADO는 DAO나 RDO처럼 계층적 구조를 가지고 있다. 하지만, 각각의 개체들이 독립적으로 존재할 수 있기 때문에 상위 개체인 Connection 개체가 존재하지 않더라도 Recordset 개체만으로도 데이터베이스에 접속해서 테이블의 레코드를 가져올 수 있다. 이런 이유로 인해서 ADO는 랜 환경의 개발자들 보다는 웹 환경의 개발자들에 의해서 먼저 사용되어져 왔다.
ADO의 개체 모델은 다음과 같다.
[그림] ADO 개체 모델
ADO 개체 모델은 개발자들이 데이터에 접근하기 위해서 사용하는 세 가지의 핵심 개체인 Connection, Command, Recordset과 Field, Property, Parameter 등의 개체들로 구성되어져 있으며, ADO 2.5에서 Record 개체와 Stream 개체가 추가되었다.
비주얼 베이직에서 ADO를 사용하기 위해서는 프로젝트 메뉴의 참조(References)에서 Microsoft ActiveX Data Object 2.5 Library (msado15.dll)을 선택해야 한다.
[그림] ADO를 참조하는 화면
비주얼 베이직 프로젝트 메뉴의 참조(References)에서 ADO를 추가했다면, 개체 찾아보기(Object Browser, F2)에서 ADO 개체에 관련된 정보를 볼 수 있을 것이다.
[그림] 개체 찾아보기(Object Browse)
Connection 개체는 ADO의 상위 레벨에 존재하는 개체로서 데이터와의 연결을 제공하는 개체이다.
[그림] Connection 개체
ADO는 DAO나 RDO와는 달리 Connection 개체가 없이 Recordset 개체를 생성할 수도 있지만, 여러 개의 Recordset 개체를 빈번히 사용할 경우에는 하나의 Connection 개체를 생성한 후에 재사용하는 것이 보다 효율적이다. 예를 들어, 웹 환경에서 ADO를 사용할 경우에는 Recordset 개체를 사용해서 직접 데이터베이스에 접속하는 것이 효율적이다. 이유는 Connection 개체를 사용해서 데이터베이스에 연결한 다음에 먼저 생성한 Connection 개체를 통해서 Recordset 개체를 생성하려면 인터넷을 통해서 데이터베이스에 두 번 접속해야 되기 때문이다. 인터넷이라는 환경 때문에 Recordset 개체로 직접 데이터베이스에 접속하는 것이 보다 효율적이다. 그런 반면에 랜 환경에서는 Connection 개체를 먼저 생성하고 생성한 Connection 개체를 통해서 Recordset 개체를 생성하는 것이 보다 더 효율적이다. 이유는 Recordset 개체로 직접 데이터베이스에 접속할 경우에 서버에서는 디폴트 Connection 개체를 자동으로 생성한 다음에 생성한 디폴트 Connection 개체를 통해서 Recordset 개체를 생성하고 디폴트 Connection 개체를 제거하는 작업을 수행한다. 그렇게 되면 서버 측에는 많은 부하가 걸리게 된다. 랜 환경에서는 이런 서버 측의 부하로 인해서 Connection 개체를 생성한 다음 생성한 Connection 개체를 전역 변수로 선언하고 응용 프로그램에서는 생성한 Connection 개체를 사용해서 Recordset 개체를 생성하는 것이 보다 더 효율적이게 된다.
[예제] Connection 개체 생성
새로운 표준 EXE 프로젝트를 시작하고 폼에 CommandButton을 추가한 다음에 다음 코드를 기술한다.
[그림] Connection 개체 생성 폼
|
Private Sub cmdConnection_Click() |
참고
|
위의 코드에서 ADO의 Connection 개체를 사용하기 위해서 변수의 데이터 형식을 ADODB.Connection 이라고 선언했다. 비주얼 베이직에서 ADO에 대한 참조를 프로젝트 메뉴의 참조에서 설정했기 때문에 선언문에서 ADODB를 제외하고 Connection 이라고 선언해도 무관하다. 만약 한 프로젝트 내에서 DAO(Data Access Object)와 ADO(ActiveX Data Object)를 함께 사용하고 있다면 DAO의 Recordset과 ADO의 Recordset의 구별이 모호하기 때문에 ADODB를 반드시 기술해야 하며, 그 외의 경우에는 Connection 만 기술해도 된다. |
위의 코드에서 Provider는 사용할 OLD EB Provider를 지정하는 것이며, Data Source는 데이터베이스가 설치된 서버를 지정하는 것이다. (local)은 현재 응용 프로그램이 실행되고 있는 컴퓨터를 가리키는 것이며, 일반적으로 다른 개발자와 공유를 해야 될 필요가 있는 소스는 컴퓨터의 이름보다는 (local)이라고 기술하는 것이 좋다. Initial Catalog는 사용할 데이터베이스를 지정하는 것이며, User ID는 데이터베이스에 접속 권한을 가진 데이터베이스의 사용자 계정을 지정하는 것이다. 마지막으로 Password는 사용자의 암호를 지정하는 것이며, 사용자 계정의 암호가 없다면 지정하지 않아도 무관하다.
Recordset 개체를 여러번 생성해야 될 경우에 Recordset 개체를 생성할 때마다 데이터베이스에 접속하는 것 보다는 하나의 Connection 개체를 생성한 다음에 Recordset 개체의 ActiveConnection 속성에 이미 생성된 Connection 개체를 지정하고 Recordset 개체를 생성하는 것이 보다 효율적이다.
Connection 개체의 속성
| 속성 | 설명 | 기본 값 | 데이터 형식 |
| Attributes | Connection 개체의 트랜잭션 속성을 읽기, 쓰기할 때 사용 (읽기/쓰기) | 0 | Long |
| CommandTimeout | 명령어가 결과를 반환할 때까지 대기하는 시간 (초 단위) (읽기/쓰기) | 30 초 | Long |
| ConnectionString (디폴트 속성) |
데이터 원본에 접속하기 위해서 사용하는 문자열 (읽기/쓰기) | 없음 | String |
| ConnectionTimeout | Connection 개체가 데이터에 접속할 때까지 대기하는 시간 (초 단위) (읽기/쓰기) | 15 초 | Long |
| CursorLocation | 서버 커서(Server-Side Cursor) 또는 클라이언트 커서(Client-Side Cursor)를 지정 (읽기/쓰기) | Provider에 따라 기본 값이 다름, 일반적으로 서버 커서(adUseServer) | CursorLocationEnum |
| DefaultDatabase | 현재 Connection의 기본 데이터베이스를 읽기, 쓰기할 때 사용 (읽기/쓰기) | 없음 | String |
| IsolationLevel | 현재 Connection에 대한 Isolation Level을 읽기, 쓰기할 때 사용 (읽기/쓰기) | adXactUnspecified | IsolationLevelEnum |
| Mode | 현재 Connection의 접근 권한에 대한 값을 읽기, 쓰기할 때 사용 (읽기/쓰기) | adModeUnknown | ConnectModeEnum |
| Properties | 데이터 Provider에 대한 프로퍼티 개체들의 컬렉션 (읽기 전용) | 없음 | Properties |
| Provider | 현재의 세션에 대한 OLE DB Provider를 읽기, 쓰기할 때 사용 (읽기/쓰기) | MSDASQL | String |
| State | 현재 Connection의 상태를 반환 (읽기 전용) | adStateClosed | Long |
| Version | ADO의 버전을 반환 (읽기 전용) | 없음 | String |
Attributes 속성
Attributes 속성은 개체의 트랜잭션 특성을 나타내는 속성이며, Long 타입의 값을 Read/Write 할 수 있다. 이 값은 하나 이상의 XactAttributeEnum(기본값 0)의 합을 가진다.
| 상수 | 설명 |
| adXactCommitRetaining | Commit 보류를 수행한다. CommitTrans 수행 후에 자동으로 새로운 트랜잭션이 시작됨을 보장한다. |
| adXactAbortRetaining | RollBack 보류를 수행한다. RollbackTrans 수행 후에 자동으로 새로운 트랜잭션이 시작됨을 보장한다. |
이 속성은 모든 Provider가 지원하는 것은 아니다. 두개의 값을 묶어서 사용할 수 있다.
adoCn.Attributes = adXactCommitRetaining And adXactAbortRetaining
[예제]
이 예제는 Connection 개체의 Attributes 속성 값을 나타낸다.
|
Private Sub cmdAttributes_Click() |
CommandTimeout 속성
CommandTimeout 속성은 명령(Command)을 실행하는 동안 실행이 제대로 되지 않으면 얼마나 오랫동안 기다렸다가 실행을 중지하고 오류를 발생시킬지를 설정하는 속성이다. 이 값은 Read/Write 가능하며 단위는 초이다. 디폴트 값은 30초 이다.
CommandTimeout 속성에 설정된 시간 동안 Execute 메서드의 결과가 반환되지 않으면, ADO는 명령의 실행을 중지시키고 오류를 발생시킨다. 만약 네트워크의 상태가 좋지 않거나 대량의 데이터를 처리하는 작업일 경우에는 이 값을 0으로 설정하면, 명령이 수행될 때까지 무한 대기하게 된다. 하지만, 부득이한 경우를 제외하고는 0으로 설정하는 것은 피하는 것이 좋다. 일반적인 경우에는 디폴트 값(30초)을 사용하는 것이 권장된다.
Connection 개체의 CommandTimeout 속성의 설정 값은 Command 개체의 CommandTimeout 속성 값에 영향을 미치지 못한다. 그 이유는 Connection 개체의 CommandTimeout 속성은 Command 개체의 CommandTimeout 속성에 상속되지 않기 때문이다.
CommandTimeout 속성은 데이터와의 연결이 이루어진 후에도 Read/Write가 가능하다.
[예제]
|
Private Sub cmdCommandTimeout_Click() |
위의 예제에서는 SQL 문장이 수행되는 시간이 15초 미만이기 때문에 별다른 현상을 볼 수 없을 것이다. 그러나 CommandTimeout 속성을 1로 설정하고 1초를 초과하는 작업을 수행하면 다음과 같은 오류 메시지를 볼 수 있다.
[그림] CommandTimeout 속성에 설정된 시간을 초과할 경우에 발생하는 오류 메시지
ConnectionString 속성
[그림] ADOX 참조 화면
ConnectionString은 데이터베이스에 접속하기 위한 정보들을 지정하는 속성이며, 이 값에 따라 ODBC 드라이버를 사용하게 될지, OLE DB Provider를 사용하게 될지를 결정하며, 접속할 데이터베이스와 서버, 그리고 접속 권한을 가진 사용자 ID와 암호를 지정할 수 있다.
[예제]
| 접속 대상 | ConnectionString |
| SQL 서버 Pubs 데이터베이스(ODBC 드라이버 사용) | "Driver={SQL Server};Server=(local);Database=Pubs;UID=sa;PWD=" |
| SQL 서버 Pubs 데이터베이스 (OLE DB Provider 사용) | "Provider=Sqloledb;Data Source=(local);Initial Catalog=Pubs;" & _"User ID=sa;Password=" |
| SQL 서버 Pubs 데이터베이스(OLE DB Provider 사용) | "Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;" & _"Initial Catalog=Pubs;Data Source=Chris" 여기에서 Chris는 SQL 서버가 설치된 컴퓨터의 이름이다. |
| 오라클 서버 Oracle73(OLE DB Provider 사용) | "Provider=MSDAORA.1;User ID=scott/tiger;" & _"Data Source=Oracle73;Persist Security Info=False" |
| 엑세스 Nwind.mdb(OLE DB Provider 사용) | "Provider=Microsoft.Jet.OLEDB.3.51;Data Source=C:\NWind.mdb" |
참고로 오라클 데이터베이스에 접속할 경우에는 오라클에서 제공하는 클라이언트 도구인 SQL*Net을 설치한 후에 Easy Configuration으로 데이터베이스의 Alias를 생성한 다음, 윈도우 제어판의 ODBC32에서 DSN을 생성하든지, OLE DB Provider를 통해서 데이터베이스에 접속하도록 한다. 오라클에서 제공되는 SQL*Net의 설정 방법에 대해서는 제 8장 이기종 데이터베이스 접속에서 자세히 다루고 있다.
[예제]
|
Private Sub cmdConnectionString_Click() |
위의 코드는 개체 변수를 생성할 때 Early Binding으로 처리했으며, Connection 개체의 Open 메서드의 매개변수로 사용자 ID와 암호를 지정하지 않고, ConnectionString 속성에 사용자 ID와 암호를 지정했다. 위의 코드에서 알 수 있듯이, 사용자 ID와 암호는 ConnectionString 속성에서 지정할 수도 있고, Open 메서드의 매개변수로도 지정할 수 있는 선택적인 사항이다.
DSN(Data Source Name)을 작성하는 방법에 대해서는 제 8장 이기종 데이터베이스 접속에서 다루고 있다.
ConnectionTimeout 속성
비주얼 베이직에서 ADO를 사용하기 위해서는 프로젝트 메뉴의 참조(References)에서 Microsoft ActiveX Data Object 2.5 Library (msado15.dll)을 선택해야 한다.
ConnectionTimeout 속성은 데이터베이스에 연결이 이루어지기를 얼마나 오랫동안 기다렸다가 실행을 중지하고 오류를 발생시킬지를 설정하는 속성이다. 이 값은 Read/Write 가능하며 단위는 초이다. 기본 값은 15초 이다.
ConnectionTimeout 속성을 설정한 후 이 시간 동안 데이터베이스와 연결이 이루어지지 않으면, ADO는 실행을 중지시키고 오류를 발생시킨다. 만약 네트워크의 상태가 좋지 않아서 이 값을 0으로 설정하면, 연결이 이루어질 때까지 무한 대기하게 된다. 하지만, 부득이한 경우를 제외하고는 0으로 설정하는 것은 피하는 것이 좋다.
ConnectionTimeout 속성은 데이터베이스와 연결되었거나 연결되지 않았거나, Read/Write 가능하다.
[예제]
|
Private Sub cmdConnectionTimeout_Click() |
위의 예제는 ConnectionTimeout 속성을 10으로 설정하는 예이다. 만약 네트워크의 상태가 좋지 않거나 서버 측에서 문제가 발생해서 10초 이내에 데이터베이스에 접속하지 못하면 다음과 같은 오류가 발생한다.
[그림]ConnectionTimeout 화면
CursorLocation 속성
CursorLocation 속성은 커서 엔진이 생성될 위치를 지정하거나 현재 CursorLocation 설정 값을 읽어 올 수 있는 속성이다.
| 상수 | 값 | 설 명 |
| adUseNone | 0 | 커서 서비스를 사용하지 않겠다는 설정으로 단지 이전 버전과의 호환성을 위해서 제공되는 값이다. |
| adUseServer | 2 | 디폴트 값이며, 데이터 Provider 또는 드라이버가 지원하는 커서이다. 서버 커서는 유연하고 다양한 기능을 제공하지만, 클라이언트 커서가 지원하는 Disconnected Recordset과 같은 몇몇 기능을 제공하지 못한다. |
| adUseClient | 3 | 로컬 커서 라이브러리에 의해서 제공되어지는 클라이언트 커서. 로컬 커서 엔진은 드라이버가 지원하지 않는 유용한 기능들을 지원하는 경우도 있다. |
CursorLocation 속성은 Connection 개체와 Recordset 개체가 가지고 있는 속성이며, Connection 개체와 Recordset 개체가 데이터 소스에 연결되기 전에는 읽기/쓰기가 모두 가능하며, 연결된 후에는 읽기 전용이다.
특별히, RDS(Remote Data Service)에서 클라이언트 측의 Recordset(ADOR) 개체나 Connection 개체를 사용하기 위해서는 adUserClient를 사용해야만 한다.
Recordset 개체의 CursorLocation 속성은 지정하지 않으면 Connection 개체의 CursorLocation 속성의 설정 값을 상속 받는다. 그리고 Recordset 개체는 ActiveConnection으로 지정된 Connection 개체의 CursorLocation 속성의 값과 다른 CursorLocation 값을 사용할 수도 있다. 그래서 Connection 개체는 서버 커서를 사용하고 Recordset 개체는 클라이언트 커서를 사용하도록 설정할 수 있다.
[예제]
|
Private Sub cmdCursorLocation_Click() |
위의 예제에서 Recordset 개체의 AbsolutePosition 속성은 현재 레코드의 물리적인 순서를 알려주는 속성으로 Recordset 개체의 CursorLocation 속성과 CursorType에 따라 사용 가능 여부가 달라진다. 이에 대한 자세한 내용은 제 8장 CursorLocation 속성과 제 9장 CursorType 속성에서 다루고 있다.
참고
|
위의 예제에서 Recordset 개체는 데이터베이스에 직접 연결된 것이 아니라, Connection 개체를 사용해서 데이터베이스에 접속한 후, 생성한 Connection 개체를 이용해서 Recordset 개체를 연결하고 Recordset 개체를 통해서 테이블의 레코드를 읽어 온다. 인터넷이 아닌 랜(LAN, Local Area Network) 환경이라면 위의 예제처럼 비주얼 베이직 프로젝트의 시작부분(Sub Main 함수)에서 Connection 개체를 생성하고, 이것을 프로젝트 내에서 사용하는 것이 보다 효율적이다. 이유는 Recordset 개체를 직접 데이터베이스에 연결할 경우에는 서버 측에서 디폴트 Connection 개체를 생성하고 생성한 Connection 개체를 통해서 Recordset 개체를 생성한 후, Connection 개체는 소멸되는 작업이 내부적으로 이루어지기 때문에 서버에는 많은 부하가 걸리게 된다. 웹 환경이라면 이런 서버 측의 부하보다 네트워크 상의 부하가 더 크기 때문에서 서버 측의 부하를 감수하고 Recordset 개체를 사용해서 직접 데이터베이스에 접속하는 방식이 사용된다. 하지만, 랜 환경이라면 전역 Connection 개체를 사용해서 필요한 Recordset 개체를 사용하는 것이 보다 더 효율적이다. |
DefaultDatabase 속성
DefaultDatabase 속성은 Connection 개체의 디폴트 데이터베이스를 지정하는 속성이다. DefaultDatabase 속성을 지정해서 작업을 수행하려면 Provider가 하나의 Connection 개체에 여러 개의 데이터베이스를 할당해서 사용할 수 있도록 지원해야만 한다. 몇몇 Provider는 하나의 Connection 개체에 오직 하나만의 데이터베이스를 할당할 수 있기 때문에 DefaultDatabase 속성을 변경할 수 없게 된다.
Provider가 이를 지원하지 않을 경우에는 오류가 발생하거나 빈 문자열을 반환한다.
이 속성은 CursorLocation이 클라이언트인 Connection 개체에서는 지원되지 않는다.
[예제]
다음 예제는 디폴트 데이터베이스를 지정하지 않고 Connection 개체를 데이터베이스에 연결한 후에 디폴트 데이터베이스를 지정하고 Connection 개체로부터 Recordset 개체를 생성하는 예이다.
|
Private Sub cmdDefaultDatabase_Click() |
IsolationLevel 속성
Connection 개체의 IsolationLevel을 지정하는 속성이다. 이 속성은 아래의 IsolationLevelEnum 값들을 지정할 수 있다.
| 상수 | 값 | 설명 |
| adXactUnspecified | -1 | Provider가 특별히 지정된 IsolationLevel을 사용하지 않을 경우, 즉 IsolationLevel을 명시하지 않을 때 사용하는 값이다. |
| adXactChaos | 16 | 디폴트 값이며, 분리된 트랜잭션으로부터 발생하는 Commit되지 않은 변경을 반영하지 않는 IsolationLevel을 지정하는 값이다. |
| adXactBrowse 또는 adXactReadUncommitted | 256 | 한 트랜잭션에서 다른 트랜잭션에서 Commit되지 않은 변경을 읽을 수 있는 IsolationLevel을 지정하는 값이다. |
| adXactCursorStability 또는 adXactReadCommitted | 4096 | 기본값, 한 트랜잭션에서 다른 트랜잭션에서 Commit된 변경에 대해서만 읽을 수 있는 IsolationLevel을 지정하는 값이다. |
| adXactRepeatableRead | 65536 | 한 트랜잭션에서 다른 트랜잭션에서 수행한 변경을 읽을 수는 없지만, 새로운 Recordset으로 생성할 수는 있는 값이다. |
| adXactIsolated 또는 adXactSerializable | 1048576 | 한 트랜잭션이 다른 트랜잭션으로부터 완전히 독립적임을 나타내는 값이다. |
IsolationLevel 속성은 Connection 개체의 Isolation Level을 지정하기 위해서 사용된다. IsolationLevel 속성은 Read/Write가 가능하며, 값이 설정되면 새로운 BeginTrans 메서드에서부터 반영된다. 만약 개발자가 지정한 Isolation Level이 부적절한 경우에는 Provider가 보다 높은 레벨의 Isolation Level로 자동으로 변경한다.
Remote Data Service를 사용할 때, 클라이언트 커서를 사용하게 되면, IsolationLevel 속성은 adXactUnspecified 값으로만 지정할 수 있다. 이유는 클라이언트 캐쉬에서 Disconnected Recordset 개체를 사용하게 되면 다중 사용자의 문제에 부딪히게 되기 때문이다. 예를 들어, 두 명의 사용자가 동시에 동일한 레코드를 수정하려고 시도한다면, Remote Data Service는 먼저 요청한 한 사용자의 수정만 받아 들이고, 두 번째 사용자의 요청은 오류로 처리하기 때문이다.
실제 개발에 있어서 SQL 서버의 Isolation Level을 Connection 개체로 조작하는 경우는 그리 많지 않으며, 부득이하게 Dirty Page를 읽어야만 하는 경우 이외에는 거의 사용하지 않는다고 볼 수 있다. 여기에서 Dirty Page는 다른 트랜잭션에서 아직 Commit하지 않은 상태에 있는 데이터의 변경된 부분을 말하는 것이다.
[예제]
다음 예제는 IsolationLevel 속성과 Mode 속성을 함께 사용하는 예이다. Connection 개체의 Mode 속성을 adModeShareExclusive로 설정하고 IsolationLevel 속성을 adXactIsolated로 설정한 다음, 트랜잭션을 시작해서 특정 필드의 값을 변경하고, 코드의 마지막 부분에서 모든 트랜잭션을 Rollback 하는 예이다.
|
Private Sub cmdIsolationLevel_Click() |
Mode 속성
Mode 속성은 Connection 개체 내에서 데이터를 수정할 권한에 대한 값이며, 다음과 같은 ConnectModeEnum 값 중 하나를 설정하거나 반환한다.
| 상수 | 값 | 설명 |
| adModeUnknown | 0 | 디폴트 값이며, 권한이 아직 설정되지 않은 상태를 나타낸다. |
| adModeRead | 1 | 읽기 전용 권한을 나타낸다. |
| adModeWrite | 2 | 쓰기 전용 권한을 나타낸다. |
| adModeReadWrite | 3 | 읽기/쓰기 권한을 나타낸다. |
| adModeShareDenyRead | 4 | 다른 사용자가 읽기 권한으로 Connection 개체를 연결하는 것을 막는다. |
| adModeShareDenyWrite | 8 | 다른 사용자가 쓰기 권한으로 Connection 개체를 연결하는 것을 방지한다. |
| adModeShareExclusive | 12 | 다른 사용자가 Connection 개체를 연결하지 못하도록 막는다. |
| adModeShareDenyNone | 16 | 다른 사용자가 어떤 권한으로도 Connection 개체를 연결하지 못하도록 막는다. |
Mode 프로퍼티는 Connection이 닫혀져 있을 때에만 수정할 수 있다.
RDS(Remote Data Service)를 사용할 때에는 클라이언트 커서와 함께 Mode 속성은 adModeUnknown 만을 지정할 수 있다.
Properties 속성
데이터 Provider에 대한 속성 개체들의 컬렉션으로 읽기 전용이다. 이 속성은 Provider에 대한 많은 정보를 제공하며, 개발자들은 Provider에 따라서 지원되는 기능이 다르기 때문에 개발에 필요한 기능이 Provider에 의해서 제공되는지를 사용하기 전에 먼저 확인해야 한다.
[예제]
다음 예제는 SQL Server ODBC Provider에 대한 정보를 직접 실행창에 보여주는 예이다.
|
Private Sub cmdProperties_Click() |
실행 결과는 다음과 같다.
Current Catalog : pubs
Active Sessions : 0
Asynchable Commit : False
Catalog Location : 1
Catalog Term : 데이터베이스
Catalog Usage : 7
Column Definition : 1
NULL Concatenation Behavior : 0
Data Source Name :
Read-Only Data Source : False
DBMS Name : Microsoft SQL Server
DBMS Version : 07.00.0699
GROUP BY Support : 2
Heterogeneous Table Support : 0
Identifier Case Sensitivity : 8
Maximum Index Size : 900
Maximum Row Size : 8060
Maximum Row Size Includes BLOB : False
Maximum Tables in SELECT : 32
Multiple Storage Objects : False
Multi-Table Update : False
NULL Collation Order : 4
OLE Object Support : 1
ORDER BY Columns in Select List : False
Prepare Abort Behavior : 2
Prepare Commit Behavior : 2
Procedure Term : 저장 프로시저
Provider Name : MSDASQL.DLL
OLE DB Version : 02.00
Provider Version : 2.50.3719.9
Quoted Identifier Sensitivity : 8
Schema Term : 소유자
Schema Usage : 31
SQL Support : 267
Structured Storage : 1
Subquery Support : 31
Isolation Levels : 1118464
Isolation Retention : 0
Table Term : 테이블
User Name : dbo
Pass By Ref Accessors : True
Transaction DDL : 8
Asynchable Abort : False
Data Source Object Threading Model : 1
Output Parameter Availability : 4
Persistent ID Type : 4
Multiple Parameter Sets : True
Rowset Conversions on Command : True
Multiple Results : 1
Provider Friendly Name : Microsoft OLE DB Provider for ODBC Drivers
Connection Status : 1
Server Name : CHRIS
Open Rowset Support : 0
Accessible Procedures : True
Accessible Tables : True
Integrity Enhancement Facility : True
Outer Join Capabilities : 127
Stored Procedures : True
Driver Name : SQLSRV32.DLL
Driver Version : 03.70.0690
Driver ODBC Version : 03.51
Like Escape Clause : Y
Special Characters : #$?걗깂뀊뇠뎷땶뜋룓몤뱮븭뿕솞썫씆윝、＄ⅵ㎤øガ??굉낫독렇뭔뻤슭오좌쳐탬픽?盖誥國喫戇倆厘描白繃嗇飡宸臆預隅膺狀穽增彩充坂沆樺詰?
Max Columns in Group By : 0
Max Columns in Index : 16
Max Columns in Order By : 0
Max Columns in Select : 4096
Max Columns in Table : 1024
Numeric Functions : 16777215
SQL Grammar Support : 1
Outer Joins : Y
String Functions : 5242879
System Functions : 7
Time/Date Functions : 2097151
File Usage : 0
Active Statements : 1
Password :
Persist Security Info :
User ID :
Data Source :
Window Handle :
Location :
Mode :
Prompt : 4
Connect Timeout : 15
Extended Properties : DRIVER=SQL Server;SERVER=(local);UID=sa;PWD=;APP=Visual
Basic;WSID=CHRIS;DATABASE=pubs
Locale Identifier : 1042
Initial Catalog :
OLE DB Services : -7
Autocommit Isolation Levels : 4096
Provider 속성
Provider 속성은 Connection 개체의 Provider의 이름을 지정하는 속성이다. 이 값은 ConnectionString 속성에서 지정할 수도 있으며, Open 메서드의 ConnectionString 매개변수에서 지정할 수도 있지만, Connection 개체의 Provider 속성을 이용해서 지정하는 것이 일일이 Open 메서드를 사용할 때 지정하는 것보다는 좀 더 명시적이라고 볼 수 있다. 이 값은 지정하지 않으면, 디폴트 값인 MSDASQL (Microsoft OLE DB Provider for ODBC)로 지정된다.
Provider 속성의 값은 데이터 소스에 연결이 이루어지기 전에는 Read/Write 가능하며, 연결이 이루어진 후에는 읽기 전용이다.
[예제]
다음 예제는 Provider를 지정하고 Connection 개체를 연결한 다음에 Provider 정보를 MsgBox로 보여주는 예이다.
|
Private Sub cmdProvider_Click() |
State 속성
State 속성은 Connection 개체가 데이터 소스에 연결된 상태인지, 연결이 되지 않은 상태인지를 나타내는 속성이다.
| 상수 | 설명 |
| adStateClosed | Connection 개체가 데이터 소스에 연결된 상태를 나타낸다. |
| adStateOpen | Connection 개체가 데이터 소스에 연결되지 않은 상태를 나타낸다 |
State 프로퍼티는 Connection 개체를 사용하고자 하는 특정한 때에 Connection 개체의 상태를 알고자 할 때 사용할 수 있으며, 이 값은 읽기 전용이다.
이 프로퍼티는 Command 개체와 Recordset개체에도 있다.
[예제]
다음 예제는 Connection 개체를 닫을 때, Connection 개체가 데이터 소스에 연결되어 있는지를 확인한 후 Connection 개체의 연결을 닫는 코드를 보여준다.
|
Private Sub cmdState_Click() |
Version 속성
Version 속성은 ADO의 버전 정보를 나타내는 속성이며, 읽기 전용이다.
[예제]
다음 예제는 ADO의 버전 정보 이외에 Connection 개체의 Properties 속성을 사용해서 DBMS 이름, DBMS 버전 등의 여러 정보도 함께 보여주고 있다.
|
Private Sub cmdVersion_Click() |
실행결과는 다음과 같다
[그림] ADO 버전 정보 화면
출처 : http://tong.nate.com/tjkim