*** Get the actual data of any new record with Set Refresh to 0,0. ***

Go Bottom
Skip 1

*** Reccount() is actual now;
*** One would say this is enough, and yes, at one try it is. However, this
*** gets your hairs out if you try it twice. So, Append on the Writer, do
*** a Replace overthere, and the above subsequently performed -> 
*** the second time you think you don't see the data. However :
*** this second time you are at EOF() because somehow the second time works
*** relatively on the first time and I didn't even start to think on why.
*** There seems not any other command to get it right (f.e. Skip -1 
*** followed by Skip +1 etc.) but to Go to the record.
*** Note that a Go Reccount() does the trick, and which anticipates for
*** this example on getting the very last new record only. Thus, by 
*** comparing Reccount() with Recno() before the above was done, one can get
*** all the new records when needed. This is not in the example !

Go Reccount()

*** So now we are there ? No !!
*** This works only when the Writer didn't explicitly Rlock the record 
*** after the Append Blank. When he did and we perform the above 
*** right at the moment the record is locked, we will never get hold of
*** the data anymore. I mean, even not when the Writer Unlocks. This is
*** because the data is not given by the server due to the record being
*** Locked (so Locking is not a convention only !!), though we do receive
*** the record in it's last stage, which is being blank.
*** In order to get the actual data, we have to enforce the server to 
*** present the data again, and which is done by an Rlock of any record
*** in the table. However, since we have to know whether the record just
*** appended is locked or not, of course we Rlock the record itself.
*** Now note that this is exactly why proper locking-logic always gets
*** the right results.

= Rlock()

*** Pfff, we now have the actual data. Of course if the record is locked
*** we have to deal with this.
*** Now note that when we wish to have a speedy app, we have to adjust
*** the concerning params like Set Reprocess which is not allowed to let
*** us wait for any fraction of a second. In stead we have to use a 
*** proper error-routine.
*** I note that there is some unknown logic within VFP which I determined 
*** as follows :
*** Use Set Reprocess to 1 (no seconds !);
*** This one attempt takes 0.05 seconds which may be far too long, depending
*** on what you do. I mean, for any normal situation this will be okay, but
*** when you have to skip through a table of which all records are locked
*** and you know it (f.e. contains entries for active users), this will 
*** take too long. now note :
*** With an On Error in effect, the time decreases to 0.001 second, and
*** that's okay for all of us. I quote that with an On Error in effect,
*** the Set Reprocess is even overruled. I mean, we have it at 0 which
*** implies indefinite trying, but instead the Error-routine is invoked 
*** immmedeately !  The Help isn't quite clear about this and says something
*** about "when a function attempt to place the lock ..." which indeed 
*** influences things, so beware not to make things unnessecary slow;
*** Just note that the 0.001 is reachable. But :
*** This 0.001 was tested on local VFP-tasks, and will be slower on a 
*** real network. Now beware, 'cause the before-mentioned 0.05 will have
*** more attempts anyhow (though this is not promised by the "one attempt"
*** of the Help), this just consumes this time. I mean, on a slower network
*** the 0.05 will remain 0.05, but the 0.001 may increase towards the 0.05 too
*** because of a package sent to the server, the server's attempt, and the
*** package sent back to the PC with the result.
*** When an On Error is in effect, there is really only one attempt.
*** Note the difference on records locked and not locked, where the latter
*** always gives the 0.001 and the first the 0.05 (without On Error); this
*** can only be due to more attempts.
*** So test this properly and always have an On Error. Even if you don't need
*** it !