FLUSH really means that the buffers are passed to the operating system and from FoxPro point of view the writing is finished. However, the data still may be in the buffers on the network server and not physically written to disk yet, which can cause various problems. For example, ones I I had to deal with FP DOS app which was generating the duplicate keys on NT network, where the typical scheme for key generation was used (lock the record, increment the next available key value, close the table, FLUSH)

>IMO, you should always use FLUSH in a multi-user setting. FLUSH will force the local file buffers to be written to the network. Therefore, the change the user made will be seen by the network.
>
>>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