Hi, Nadaya

Sorry to jump in..but i want to be no.4 to disagree with.
i've always used record buffering with same reason like you in my main class
form if not one-to-many situation and finished 4 small and medium project with
that but still suffered by unexpected update and error,very very weird and same
feeling to shoot my foot as Cetin said. Not very frequent but uncatchable error,
usaully opened with multi-instance and over-lapped with other forms,as you may
did, i had also codes to decide whether update has to be done or not at grid's
beforecolumn change event and this may cause unexpected one.
i've changed all recordsource into parameterised-updateble view with table-
buffering, and used TABLEUPDATE(.F.,.F.) to just think a record at a time with
ischanged() code at grid's beforecolumnchange.
And even though table buffered-view, it could be indexed easily at DE's init.
in the case of like you,(upper(ccode+town+street+str(stNum,4)+stNumExt+Unit),
pls refer followings.

DE's init
select myView
=cursorsetprop(.updatable',.f.)
=cursorsetprop('buffering',3)
INDEX ON upper(ccode+town+street+str(stNum,4)+stNumExt+Unit tag myTag
=cursorsetprop('buffering',5)
=cursorsetprop(.updatable',.T.)

Then, though user changed something, he/she still saw same record with already
indexed and changed location or next record if he/she clicks next button.
i've read all above from effective technique..and i've changed mine along
their adivice.
At first i followed Tastrade model and still don't know why they didn't show
more stable way like table buffering.
Really i'd like to say to you..don't waste time and don't be suffered like me.
Hope This Helps.

RGDS
HK.Lee