I don't think flush really is the answer. I think in essence your code should be doing a ...

IF <find a slot> AND (RLOCK() or RetryLock())
   REPLACE.....
   UNLOCK
ELSE
   * other code to create a slot
ENDIF
* Retrylock is a UDF of mine which retries a lock attempt after RLOCK fails.

I believe in avoiding FLUSH and particularly FLOCK(). RLOCK() and UNLOCK do an implicit flush. Your existing code made it possible for update attempts on the same record.

Here's the Retrylock code if you want to use it...

FUNCTION RetryLock
PARAMETER cAlias, msg
* Attempt to lock a record and return .T. if successful.
* NOTE: The calling program MUST already have attempted an RLOCK()
* IF RLOCK() OR RetryLock()
*		<replace etc>
* ENDIIF
*
* msg is optional

IF EMPTY(m.cAlias)
	* lock current work area
	cAlias= ALIAS()
ENDIF
IF TYPE('m.msg') # 'C'
	msg= 'The program is currently unable to access a record or file.' ;
		+ 'You can retry now, or cancel and try again later.'
ENDIF

DO WHILE MsgBox(m.msg, 'File/Record in use by another.', 69) = 4
	* User is being persistant!
	IF RLOCK(m.cAlias)
		RETURN .T.
	ENDIF
ENDDO
* User has given up hope!
RETURN .F.

>Earlier today I was troubleshooting a foxpro 2.6 application. There seemed to be a multi-user issue which really threw me for a loop.
>
>Basically, the code is looking for an empty slot that it can use to store an item. It searches a master slot table for an empty record, and when it finds one, it writes the current item into that empty slot, and writes an inventory record in another table. This has worked fine until we started using it in a multiple user environment. For some reason, no computer seems to recognize entries made on any other system when looking for the empty record. This resulted in massive amounts of double assignments.
>
>For some reason, adding a FLUSH after writing the record to the slots table seemed to fix it. This is strange because FLUSH doesn't really seem to do much in a network environment.
>
>Here is the code that is working:
>

>MSLOT = 0
>MSLOTCATG = SPACE(10)
>IF .NOT. EMPTY(PRODUCT.DEPARTMENT)
>  SELECT DEPTTYPE
>  SEEK PRODUCT.DEPARTMENT
>  IF (.NOT. EMPTY(DEPTTYPE.SLOTCATG))  && Should this product get a slot
>    MSLOTCATG = DEPTTYPE.SLOTCATG
>    SELECT SLOTS
>    DIDITLOCK = FLOCK()
>
>    LOCATE FOR EMPTY(SLOTS.PRODUCT_ID) .AND. SLOTS.SLOTCATG = DEPTTYPE.SLOTCATG
>    IF (FOUND())
>      MSLOT = SLOTS.SLOT
>      REPLACE SLOTS.PRODUCT_ID WITH MPRODUCTID,;
>              SLOTS.ARTIST     WITH MARTIST2,;
>              SLOTS.TITLE      WITH MTITLE2,;
>              SLOTS.DEMO       WITH SPACE(1)
>    ELSE
>

>... code to execute if there aren't any more slots. ...
>

>    ENDIF
>  ENDIF
>ENDIF
>FLUSH
>UNLOCK IN SLOTS
>

>
>If you just take out the flush command, it fails. The really interesting thing is that subsequently browsing the database shows what appears to be a corrupt index showing two records with the same slot number, one of which you can't cursor into.
>
>Anyway, I'm just wondering if anyone can explain this behaviour and verify that a FLUSH is indeed the appropriate command to prevent this problem. We've done lots of multi-user applications, and this is the first time we have seen behaviour like this.
>
>Thanks,
>
>Paul R. Moon