CursorLocation 또는 adOpenDynamic 변경 중

Question

저는 adOpenDynamic을 사용하고 있으며 CursorLocation은 기본적으로 Server (V6)로 설정되어 있으며 프로그램은 acess와 SQL Server에서 모두 작동합니다. 이제 -1을 반환하는 recordCount에 문제가 있습니다. 클라이언트로의 CursorLocation을 유지하고 adOpenStatic 있습니다 또는 adOpenKeyset으로에 adOpenDynamic을 변경 클라이언트 또는 에 서버에서의 CursorLocation을 변경

: 나는 다음과 같은 해결책을 발견했다. Dynamic과 Keyset 사이의 유사성을 기반으로 adOpenKeySet을 사용하여 변경하는 것이 더 좋습니다.

지금 이것은 내 질문에 당신은이 adOpenDynamic을 유지하고 단지 클라이언트 또는 서버를 유지하고 adOpenDynamic가 키 집합하는 변화에의 CursorLocation을 변경하는 것이 더 나은 것을 생각입니까?

감사합니다.

Answer 1

대답은 예이며 아니오입니다.

이러한 다양한 옵션은 이유가 있기 때문에 존재하며 대부분 기능 및 성능에 있습니다.

커서 위치를 서버로 설정하면 모든 데이터를 한 번에 "가져올"수 없습니다. 일부는 다시 돌아올 것이고 나머지는 요청할 때까지 서버에 남아있을 것입니다. 이 요청은 레코드 세트의 다음 레코드로 이동할 때 수행됩니다. 앱이 네트워크를 통해 설정되기 전에 데이터를 사용하기 시작할 수 있기 때문에 일반적으로 매우 큰 레코드 세트를 사용하면 성능이 향상됩니다. 발생하는 왕복 '대화'가 많기 때문에 네트워크 사용에는 좋지 않습니다. 또한 레코드 세트를 닫을 때까지 서버 리소스를 소비하기 때문에 서버용으로 적합하지 않습니다.

클라이언트 커서를 사용하면 모든 데이터가 가능한 빨리 네트워크를 통해 전달되지만 앱이 모두 클라이언트에 전달되어야 데이터를 사용할 수 있습니다. 대용량 레코드 세트를 사용하면 시간이 오래 걸리고 결과적으로 앱이 지연 될 수 있습니다. 클라이언트 레코드 세트는 서버와 네트워크에 친숙하지만 지연으로 인해 클라이언트에서 더 어렵습니다.

이런 식으로 생각하십시오. 그리드에 표시하려는 많은 데이터가 있다고 가정 해보십시오. 서버 커서를 사용하면 데이터의 첫 번째 "페이지"를 표시 할 수 있습니다. 그런 다음 사용자가 그리드를 아래로 스크롤하면 다음 20 개의 행을 가져 와서 표시합니다. 따라서 사용자가 스크롤 할 때마다 약간의 지연이 있습니다 (눈에 띄지 않을 수도 있음). 클라이언트 커서를 사용하면 사용자가 모든 작업을 수행하기 전에 모든 데이터를 그리드에로드해야합니다.

내 응용 프로그램에서는 필자가 데이터베이스에서 필요한 데이터 만 반환하는 것에 대해 매우 신중합니다 (열과 행을 제한합니다). 거의 항상 adOpenStatic을 사용하는 클라이언트 측 커서입니다. 기본적으로 데이터베이스를 호출하고 데이터를 가져온 다음 가능한 빨리 레코드 집합을 닫습니다. 그런 다음 삽입, 업데이트 및 삭제를 위해 별도의 SQL 문을 실행합니다.

당신에게 최선의 조언은이 모든 옵션들이 무엇을하는지 배우고 올바른 것을 사용하는 것입니다. 즉, 필요한 기능에 따라 앱 전체에서 여러 가지 방법을 사용하게 될 것입니다.