Hi Mike

>Hi Terry
>
>>OK. First of all, if more than one user is likely to edit the record then you could get contention. You should use record locking such as:
>>
>>

>>select showdate
>>locate
>>If RLOCK()
>>    replace dt1 with datetime()
>>    = TABLEUPDATE(.T.)
>>EndIf
>>locate
>>

>>
>
>Respectfully, sir, I believe you're mixing pessimistic and optimistic approaches. You've taken the pessimistic approach and locked the record while using optimistic buffering.

No, I'm taking the GP approach I've always taken. All my updatings are taken care of by a suite of methods in my base classes, so I rarely need look into them. I tend to use buffermode override level 5 if I'm likely to be updating several recs at one go, such as producing a series of link recs in a reln., or 3 when updating one at a time.

I lock the recs so that as one is changing them another can't nip in and change them under his nose.

One thing I did forget in my simplistic example was to unlock the record:

If RLOCK()
    replace dt1 with datetime()
    = TABLEUPDATE(.T.)
    UNLOCK
EndIf

I'm too tired today to get into a discussion about it :-)

>
>I also believe row buffering is seldom required. Table buffering is all I've ever needed.
>
>

>replace dt1 with datetime() record 1 in showdate
>IF NOT TABLEUPDATE(.T.,"showdate")
>  aerror(laError)
>  MESSAGEBOX(laError[1,2])
>ENDIF
>

>
>This way the last user to save is warned of conflicts. The optimist thinks they'll never get that warning. ;)
>
>A refresh of the form will show the current data and the current user can decide what to do with the current record.