FlexFile Networking

   FlexFile typically requires no special network considerations
   beyond Clipper's RLOCK() and FLOCK().  That is to say, if you
   acquire an RLOCK() on a record in a DBF file that has a
   pointer-field, no other user will have write access to that
   record.  Because Clipper insists on an RLOCK() being acquired
   before a REPLACE when a file is used non-exclusively, this
   will suffice to protect the information to which the
   pointer-field is related.

   FlexFile's internal tables lock and unlock automatically, and
   require no programmer consideration.

   There is an additional network features which was incorporated
   into FlexFile in order to aid the programmer in implementing
   network compatible code.

   Every time a pointer is replaced with a new pointer, the new
   pointer is guaranteed to have a different value even though it
   may be pointing to the same position within the file.

   For example, if you have variable length data that is 30 bytes
   long, residing at offset 5000 in the DBV file, and you replace
   that data with new data that is also 30 bytes long, it is
   highly probable that FlexFile will put the new data exactly
   where the old data was (at offset 5000).  However, the
   pointer-field that the V_REPLACE() function returns will be
   different than the one that pointed to the data before the
   REPLACE.

   This feature was implemented so that the programmer can assign
   the pointer- field to a variable, then, without locking the
   DBF record in which the pointer- field is located, modify the
   pointer's data in memory.  Then when the user is ready to
   replace the old data with the modified data, the programmer
   can compare the pointer-field in memory with the DBF's
   pointer-field in order to ascertain whether the data was
   modified by another user while the current user was working on
   the copy of it in memory.  For example:

       // Open the DBF and its related DBV
       USE Shareit.dbf
       IF V_USE( 'Shareit.dbv' ) == -1
          ? "I could not open the Shareit.dbf file."
          ? "I encountered error: " + STR( V_ERROR() )
          QUIT
       ENDIF

       // Save the pointer <vlf> to a variable
       save_vlf = shareit->vlf

       // Retrieve the data from the DBV file into a memory var.
       // The DBF lock is momentary.
       DO WHILE !RLOCK()
       ENDDO
       memo_data = V_RETRIEVE( vlf )
       UNLOCK

       // Edit the data.
       memo_data = MEMOEDIT(memo_data...)

       // Lock the record and replace the data if the
       // data has not been modified since the pointer was
       // saved.  Again, the lock is momentary.
       DO WHILE !RLOCK()
       ENDDO

       IF save_vlf == shareit->vlf
          REPLACE vlf WITH V_REPLACE( memo_data, vlf )
       ELSE
          ? "Data has been modified by another user!"
          INKEY(0)
       ENDIF
       UNLOCK

   Although the Clipper locking technique shown is crude (at
   best), the comparison of the saved version of the pointer with
   the DBF pointer-field is a technique that many programmers
   prefer.  The advantage is, of course, that you only need to
   obtain two momentary locks rather than one long lock (during
   which your user invariably goes on a lunch break).  The
   disadvantage is that sometimes the user will have to retype an
   entry.

   FlexFile's internal locking uses the DOS 3.x locking
   mechanism.  Therefore, if you are using a lower version of DOS
   or do not have SHARE.EXE loaded, FlexFile will ignore any
   attempts to lock the file and proceed as if the lock was
   successful.