When a Virtual Table View Fetches Data Segments

This section describes optimization techniques used in DataObjects for .NET to make fetching data from the server transparent and largely imperceptible to the user. It has no effect on the formal functionality, so you can skip it if you are not interested in this description.

When the end user navigates through the current segment, they usually position on rows belonging to the current segment. In fact, it is impossible to position on any other row, except by using a C1DataTableSource that has special methods for navigating the whole virtual rowset, or by using the scrollbar of a bound grid control to position to the end or the beginning of the rowset, if it is not covered by the current segment.

When the user positions on a row that is out of bounds of the current segment (this can be done only with C1DataTableSource or with a bound grid going to the end of the rowset), DataObjects for .NET looks for the required segment in the cache and, if not found, fetches it from the server. After that, the new segment becomes current.

In order to optimize segment fetch performance, DataObjects for .NET also performs a "preemptive" asynchronous fetch when the user positions to a row that is inside the current segment but "dangerously" close to its boundary (the closeness threshold determined by the VirtualSyncThreshold and VirtualAsyncThreshold properties):

If it is "very close" to the current segment boundary (determined by the VirtualSyncThreshold property), DataObjects for .NET fetches the required segment (one that has the current row in the middle rather than near the end) immediately, suspending all other activities (synchronously). When the segment is fetched, it becomes current.
If it is "not so close" (determined by the VirtualAsyncThreshold property), DataObjects for .NET starts the fetch process in a separate thread, so it is performed in the background, without interrupting other activities (asynchronously). When the segment is fetched, it is placed in the cache, but not made current. The segment is prepared in case it will be needed when the user moves closer to the current segment boundary.
These techniques provide for the following transparency and optimization behaviors:
Database fetch and segmentation are transparent to the user. The rowset is presented to the user in its entirety, appears to contain all rows regardless of whether they belong to the current segment or not. Any part of it, including the end of the rowset and any given row specified by a primary key value (see C1DataTableSource Seek) is available to the user.
Database fetches are optimized with a heuristic "preemptive" background fetch technique. If the end user navigates through the rowset slowly enough to allow the optimization to work, segment changes occur without delays, as if the data were already on the client. A jump to a specified position in the rowset (for example, using the C1DataTableSource Seek method) occurs with a delay necessary to fetch the data from the server, but that delay only occurs if the specified position is far enough from any cached segment.