Hi Jill,

This is a nasty one. The problem is caused by the SEEK() command that is not searching through the most recent data. It is caused by the internal buffering VFP uses. IOW the changes made by other users on the network do not inmediately reflect in your instance of that table.

You can reduce (but not eliminate) the problem by adjusting the SET REFRESH setting to a lower value.

You can eliminate the issue by placing a file lock on the table before you seek(), so:

SELECT ReserveGroup
IF FLOCK()
   IF !SEEK( nGroupToLock )
      INSERT INTO ReserveGroup VALUES ( nGroupToLock )
   ENDIF
ELSE
   ** Handle the FLOCK() error
ENDIF

Walter,



>I have a "semaphore" file, ReserveGroup.DBF; it has one integer field,
>GROUP, which is also it's primary index, GROUP.
>
>While reservations are being changed in a group, the function LockGroup is
>called; a record in this table is created (if none exists) with the group
>number and the record is locked. Once the reservation changes have been
>completed, the record is unlocked.
>
>Sometimes, the system generates the error "Uniqueness of index GROUP is
>violated" (the error shows in ther error log - 11 times in June, 5 times so
>far in July; different users, different computers). I can't reproduce this
>problem.
>
>ReserveGroup is opened in the Data Environment of the form, w/buffer mode of
>0, and it's order set to GROUP.
>
>This is a peer-to-peer Windows network.
>
>The error occurs at line 10 in the following function...does anyone have any
>suggestions about how to avoid the error?
>
>TIA, J
>
>

** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** ** **
>** lock GROUP while updating or DELETing
>FUNCTION LockGroup
>
>LPARAMETER nGroupToLock
>
>LOCAL cTheAlias, lLocked
>
>cTheAlias = ALIAS()
>
>SELECT ReserveGroup
>IF !SEEK( nGroupToLock )
> INSERT INTO ReserveGroup VALUES ( nGroupToLock )
>ENDIF
>IF LOCK()  && lock the record
> lLocked = .T.
>ELSE
> lLocked = .F.
> WAIT WINDOW RecBusyMsg
>ENDIF
>SELECT ( cTheAlias )
>RETURN lLocked
>** End LockGroup