Hi Phil,

No ;-)

Assuming that your "you select a table" must be read as "you USE a table", this would be right when it is about a Remote View you make active, and the table bebind the View (cursor) implying a "download" to the PC indeed (of (part of) the Index at least).

The only thing you'd have to do, is ensuring that you obtain the latest version of the record(s) concerned, which is -in your case- also about ensuring that you obtain all the records at the end of the table (my means of the before explanation).

I can add to this, that I assume that applying an FLock won't help you in obtaining the latest version of records. You will obtain a before selected record in its latest version or my means of the elapse of the Set Refresh timer (nothing to depend on), or by means of issueing an RLock to the record concerned. Note that the latter is good for VFP's internal logic opposed to you, the user, since it perfectly fits the awaitening of your (possible) upcoming Replace : you have the fresh copy of the record, no one can touch it, so you can change it - and write is back (by means of ULock in general).
But I say again (hmmm, don't know anymore where I said it) : VFP7 allows for a Set Refresh setting that should imply having the latest versions of records always because it implies the timer to fire immediately always (but I won't believe that until I checked this myself, which I did not yet).

Now please note my remarks in the other thread about on the issueing an Unlock in order to release the changed record, freeing the table from FLock in between. VFP's logic is wrong here. Combine this with my assumed necessity of the RLock, THUS needing an Unlock later, and all cannot work around the FLock logic. IMO this implies that you just as well skip the whole FLock thing, and use proper logic around RLock only.

Concluded : For you applies one thing only : obtain the latest version of a record by means of RLock which implicitly allows you to change the record without interfering of others. This is about your NextRef table if it would contain one record only per table the NextKey is about. Not 100 % foolproof, because I assume when the app receives a new table, there is no entry for it in NextRef yet, which comes to the Append Blank situation again to solve properly (see earlier message).

Regards,
Peter


>Hi,
>Am I correct in thinking that when you select a table Foxpro reads it and writes it into temporary memory space (or something like that). Which would mean that I need to select it again after calling flock() to be sure that it didn't change again in the mean time.
>
>Phil.