Hi Paul,

I frequently encountered problems with multiuser updates in FPW 2.6. There seems to be a bug in FPW 2.6 causing it. In some circumstances I needed a flush to commit the changes.

I have not seen this behaviour in VFP.

Hi Craig,

In general it is a very bad idea to use FLUSH in mutli user apps. It might slow down your applications performance as you don't allow VFP to efficiently handle buffered updates. Especially when you're the only user in this multi-user application. Besides troubleshooting problems like this, you won't need a FLUSH. The OSs exclusive oplocking mechanism should take care of this.

Walter,


>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