Do you use buffering?

With optimistic buffering, records will not be locked when the user looks at a record, or even when the user edits; only when the user tries to save will VFP check for conflicts.

You don't even need an "Edit" button; the user can start editing at any time.

OTOH, it should seldom happen that users actually edit the same record at the same time (except for processes that handle multiple records). If it does happen quite often, it may be an indication that you may to do some redesign. For instance, non-normalized tables might cause problems.

>I have a database application that is used by alot of people. Upto a while ago, I had no problems... However, I gained even more users(about 100) and then my troubles began... My users started to receive Update Conflict errors, as more and more users started to look at the same records.
>
>When a user pulls up a record, all controls on the screen are readonly. Only if the user clicks on the edit button will the controls allow editing.
>
>After all of these Update Conflict errors, I appended this code at the bottom of my SAVE code:
>
>FOR a = 1 TO FCOUNT('wrs')
> IF CURVAL(FIELD(a)) <> OLDVAL(FIELD(a))
> *-- someone has updated a field...
> cReturnString = cReturnString + FIELD(a) + " Changed from " + ;
> OLDVAL(FIELD (a)) + " to " + CURVAL(FIELD(a)) + CHR(13) + CHR(10)
> lchanges = .T.
> replace (FIELD(a)) WITH (CURVAL(FIELD(a)))
> ENDIF
>ENDFOR
>
>This got rid of all the Update Conflict errors. However, If two people sit on a record. And the first does an EDIT and SAVE, and the second person never does an edit; after the first person has moved on, then the second person moves on... The second person reverts the record back prior to the first persons' edits.
>
>How do I stop this?
>
>Thanx,
>
>Mike