>>technical nitpick: in 1:1 inner join relations of multi-category lookup tables the other option is to have a "newest" TS field in the table and add a record for "deleted/not available" for that category/key combination.
>
>Thomas: not getting what you mean by "TS field"?

Timestamp - which is not a datetime, it's a binary format, always readonly to you, sortable but never updatable. It's set to current system time (check docs for precision of that) whenever the record changes. So you keep a copy of the data cached in your cursor and from time to time just check whether the max(timestamp) for the records you have has changed on the server. If you get a larger (i.e. later) one than what you have, requery, else don't bother. I guess it's also used in replication - the last one wins, i.e. if you have two records in tables you need to synchronize, both updated _after_ the last synchronization, the one which was changed later (as per timestamp field) should either be taken as truth or the situation should raise a possible colision alert.