|
<< Click to Display Table of Contents >> Live caching |
![]() ![]()
|
Live caching provides fuller BDE support than dead caching. It can be fast or slow, depending on other factors. Live caching is used by default if an index or row ID exists, but only for tables, not queries. With DbiOpenTable, iIndexId can be set to NODEFAULTINDEX to force dead caching even though an index or row ID exists.
The following general rules apply to live caching:
| Data tends to be fresh. The fastest index is chosen automatically if none is specified during table open. |
| A partial cache is kept, ordered by index. The cache contains the current cursor row, plus the last several rows fetched. |
| Live caching allows cache refresh. Refresh can be done manually via DbiForceReread and is done automatically if the cursor moves around. |
| Live caching allows key-oriented operations, such as DbiSetRange and DbiSetToKey. |
Record caching example: live
A Customer table with unique or non-unique index on ID field.
ID |
Name |
10000 |
John |
11001 |
Mary |
12321 |
Harry |
12345 |
Beth |
12666 |
Joe |
The SQL driver finds some basic information about the table structure, but no data is retrieved:
DbiOpenTable (
| hDb, |
| "Customer", |
| NULL, |
| "IdIndex", |
| ..., |
| &hCursor ...); |
The SQL driver sets up for data retrieval:
UINT16 myKey = 12321;
| DbiPutField (hCursor, |
| 1, |
| &myRecBuff, |
| &myKey); |
| DbiSetToKey (hCursor, |
| keySEARCHGEQ, |
| FALSE, |
| 1, |
| 0, |
| &myRecBuff); |
The SQL driver query:
SELECT Id, Name
FROM Customer
WHERE Id >= 12321
ORDER BY Id
DbiGetNextRecord (...)
The SQL driver caches a row:
ID |
Name |
12321 |
Harry |
DbiGetNextRecord (...)
DbiGetNextRecord (...)
The SQL driver caches more rows:
ID |
Name |
12321 |
Harry |
12345 |
Beth |
12666 |
Joe |
DbiGetPriorRecord (...)
The SQL driver uses a cache, rather than the server:
DbiSetToBegin (...)
The SQL driver terminates the query and clears the cache:
ID |
Name |
No data in the cache |