스크롤 가능 커서Scrollable Cursors

최신 화면 기반 응용 프로그램에서는 사용자가 앞뒤로 스크롤하고 데이터를 전달 합니다.In modern screen-based applications, the user scrolls backward and forward through the data. 이러한 응용 프로그램의 경우 이전에 인출 된 행으로 돌아가는 것은 문제가 됩니다.For such applications, returning to a previously fetched row is a problem. 커서를 닫았다가 다시 연 다음 커서가 필요한 행에 도달할 때까지 행을 인출 하는 것이 한 가지 가능성은 있습니다.One possibility is to close and reopen the cursor and then fetch rows until the cursor reaches the required row. 또 다른 가능성은 결과 집합을 읽고, 로컬로 캐시 하 고, 응용 프로그램에서 스크롤을 구현 하는 것입니다.Another possibility is to read the result set, cache it locally, and implement scrolling in the application. 두 경우 모두 작은 결과 집합에 대해서만 작동 하며, 후자의 경우에는 구현 하기가 어렵습니다.Both possibilities work well only with small result sets, and the latter possibility is difficult to implement. 더 나은 방법은 스크롤 가능한 커서를 사용 하는 것입니다 .이 커서는 결과 집합에서 앞뒤로 이동할 수 있습니다.A better solution is to use a scrollable cursor, which can move backward and forward in the result set.

스크롤할 수 있는 커서 는 사용자가 데이터를 앞뒤로 스크롤 하는 최신 화면 기반 응용 프로그램에서 일반적으로 사용 됩니다.A scrollable cursor is commonly used in modern screen-based applications in which the user scrolls back and forth through the data. 그러나 스크롤 가능한 커서는 앞 으로만 이동 가능한 커서 보다 일반적으로 비용이 많이 들기 때문에 응용 프로그램은 전방 전용 커서에서 작업을 수행 하지 않는 경우에만 스크롤 가능 커서를 사용 해야 합니다.However, applications should use scrollable cursors only when forward-only cursors will not do the job, as scrollable cursors are generally more expensive than forward-only cursors.

뒤로 이동 하는 기능을 통해 전방 전용 커서에 적용할 수 없는 질문을 발생 시킬 수 있습니다. 스크롤할 수 있는 커서가 이전에 인출 된 행의 변경 내용을 검색 해야 하나요?The ability to move backward raises a question not applicable to forward-only cursors: Should a scrollable cursor detect changes made to rows previously fetched? 즉, 업데이트, 삭제 및 새로 삽입 된 행을 검색 해야 하나요?That is, should it detect updated, deleted, and newly inserted rows?

이 질문은 결과 집합의 정의 (특정 조건과 일치 하는 행 집합)가 행을 검사할 때 해당 기준과 일치 하는지 여부를 확인 하지 않고 행이 인출 될 때마다 동일한 데이터를 포함 해야 하는지 여부를 확인 하기 때문에 발생 합니다.This question arises because the definition of a result set - the set of rows that matches certain criteria - does not state when rows are checked to see whether they match that criteria, nor does it state whether rows must contain the same data each time they are fetched. 이전에 생략 된 커서를 사용 하 여 행이 삽입 또는 삭제 되었는지 여부를 검색할 수 있습니다. 반면 후자를 사용 하면 업데이트 된 데이터를 검색할 수 있습니다.The former omission makes it possible for scrollable cursors to detect whether rows have been inserted or deleted, while the latter makes it possible for them to detect updated data.

때로는 변경 사항을 검색 하는 기능이 유용 합니다.The ability to detect changes is sometimes useful, sometimes not. 예를 들어, 회계 응용 프로그램은 모든 변경 내용을 무시 하는 커서를 요구 합니다. 커서가 최신 변경 내용을 표시 하는 경우에는 책을 분산할 수 없습니다.For example, an accounting application needs a cursor that ignores all changes; balancing books is impossible if the cursor shows the latest changes. 반면에 항공 예약 시스템에는 데이터에 대 한 최신 변경 내용을 표시 하는 커서가 필요 합니다. 이러한 커서가 없으면 데이터베이스를 지속적으로 다시 쿼리하여 최신 비행 가용성을 표시 해야 합니다.On the other hand, an airline reservation system needs a cursor that shows the latest changes to the data; without such a cursor, it must continually requery the database to show the most up-to-date flight availability.

ODBC는 서로 다른 응용 프로그램의 요구 사항을 다루기 위해 스크롤 가능한 네 가지 커서 유형을 정의 합니다.To cover the needs of different applications, ODBC defines four different types of scrollable cursors. 이러한 커서는 비용 및 결과 집합에 대 한 변경 내용을 검색 하는 기능에 따라 달라 집니다.These cursors vary both in expense and in their ability to detect changes to the result set. 스크롤할 수 있는 커서가 행의 변경 내용을 검색할 수 있으면 해당 행을 다시 페치 할 때만 검색할 수 있습니다. 데이터 원본에서 현재 인출 된 행의 변경 내용을 커서에 알릴 수 있는 방법은 없습니다.Note that if a scrollable cursor can detect changes to rows, it can only detect them when it attempts to refetch those rows; there is no way for the data source to notify the cursor of changes to the currently fetched rows. 참고로, 변경 내용에 대 한 가시성도 트랜잭션 격리 수준에 의해 제어 됩니다. 자세한 내용은 트랜잭션 격리를 참조 하세요.Note as well that visibility of changes is also controlled by the transaction isolation level; for more information, see Transaction Isolation.

이 섹션에서는 다음 항목을 다룹니다.This section contains the following topics.