음 오랜만에 글을 쓰게 되는군요...

엉엉엉 이 부분은 강의를 해야되는데 제가 시간이 없서서여...

제가 아는한 ADO 가 그렇게 느린 이유중에 하나는 데이터자체의 마샬링 과정을 --- ADO 도 엄연한

COM 객체입니다 --- 거치는 데다가 그걸 또다시 런타임이든 디자인 타임이든 vcl 라이브러리로

다시 랩핑시킨뒤 데이터를 얻어 표시하기 때문입니다.

음 정확한 용어와 설명인지 모르겟네요... =ㅅ=;;

실제로 이런과정을 BDE 나 ODBC 보다 더 거치기 때문에 느린것이라고 생각하고 있습니다.

업계에서도 대개 LAN 정도를 벗어나면 ADO 는 거의 안씁니다.

보통 원격지의 디비 서버에서 14만개의 레코드를 가져오는 작업은 장난이 아닙니다.

그리고 이런 자료는 대개 단순히 브라우징이나 서칭의 목적으로 사용되는데요... =ㅅ=;;

이럴때는 데이터셋의 3대속성을 가지고 적절히 잘 배합하여야 합니다.

일단 커서 위치가 중요하구요. 이때는 서버측 커서를 생성하여 사용합니다.

왜냐하면 클라이언트 측 커서는 쿼리문이든 어떤 테이블이든 간에 있는 자료를 무조건

클라이언트 쪽으로 가져옵니다..... 무식하죠~ =ㅅ=;;

대개 이 클라이언트 측 커서를 쓰는 경우는 가벼운 테이블이나 where ~ 어쩌고 저쩌고 시부리는

넘들을 위해 씁니다, 그러니 대략 기껏해야 경험상 통계적으로 5만건 정도 이하의 레코드를 처리하

는데 좋더군요. 그 이상이 넘어가면 BDE-Native 가 확실한 대안입니다. 물론 odbc 도 상관 없구요

단 성능은 BDE-Native 가 더 낫습니다. 오라클이던 사이베이스든 ms-sql 이든 이보다 더 좋은 것은

없습니다.

자 그럼 돌아가서 14만건 정도의 데이터라면 서버측 커서를 사용해야 합니다.

대개 서버측 커서는 대용량의 결과 셋을 얻을 때 사용됩니다.

이것 이외에 이넘이 있을 필요가 없습니다. 단 유연성은 엄청 떨어집니다.

커서의 위치라던지 커서의 포인터의 위치라던지 하는 내용은 나중에 강의를 할 것입니다.

설명이 길어지니까여.... =ㅅ=;;

자 그럼 커넥션 컴포넌트나 데이터셋 컴포넌트의 CursorLocation 속성은 clUseServer 가 되겠져...

그리고 그 다음은 커서 타입인데요 이넘도 설명을 할려면 한 참 걸립니다.

단순히 건당 일괄적인 조작을 하려고 한다면 ctOpenForwardOnly 가 탁월한 선택입니다.

말 그대로 전진전용 커서입니다 절대로 뒤로 못갑니다. 무적 디비 공구립니다.... =ㅅ=;;

앞 뒤로 와따가따 할려면 ctDynamic 정도를 사용하는게 낫겠네여. ctKeySet과의 차이점은 조작한 데

이터가 다른 디비 광부(^ㅅ^) 에게 보이냐 안보이느냐의 차입니다. 물론 다이나믹이니 보이겟져.

ctStatic은 클라이언트 커서를 위한 커서타입이구요. 서버측에 썻다간 딴 속성으로 저절로 바뀝니

다.

브라우징 <-> 서칭의 작업 사이에 동적인 코드로 커서 위치를 바꾸는 것도 괘아나요.

브라우징은 당근 서버측 커서를 쓰구요 서칭은 데이타가 별로 안되니 클라이언트 커서를 사용하는것

도 괜찮은 방법입니다.

참 그리고 클라이언트 측 커서를 사용했을때 데이터 조작을 한 후 서버로 보낼때 마샬링 옵션을

moMarshalModifiedOnly 로 하는 것도 성능향상에 도움이 됩니다.