Hi!

See comments below...

>>>>>Hi Cetin,
>>>>>
>>>>>Actually, I think, I found couple of problems.
>>>>>
>>>>>First of all, I had some custom method for ForeColor and BackColor in the grid. I added LockScreen to prevent updating screen. I also found bunch of problems with our framework Add method (it serves double duity Add/Save depending on EditMode). Unfortunately, I'm not in charge of our classes code, so I reported this problem to my colleague, but she is leaving, so I don't know, how long I need to wait for resolution...
>>>>
>>>>The grid color methods should fire for each visible cell of the grid in the next Refresh, not for all the records you updated.
>>>>
>>>>For things like this, I'd rather open the table AGAIN, and do the replace for < filter expression > there, close that second instance, and get back to the grid once this is over, and just refresh it.
>>>
>>>This would not work, since I use tablebuffering.
>>
>>OK, reshake the buffering for the grid's table (set it to 1 and then back to what it was) before the refresh.
>>
>>The buffering of the second instance wouldn't matter, because its changes would be flushed anyway once it was closed.
>
>If I surround refresh and all other methods with thisform.lockscreen=.t., would it stop execution of myForeCOlor, when it's not needed?

I guess no. LockScreen has nothing to VFP events logic, and while grid is refreched, Denamic* expressions will be evaluated anyway, though you just will not see results (because screen is locked).
When you move the record pointer and certain things happen inside of teh VFP, grid is also refreshed (to change current row) and a bunch of events firing. In particular, this can happen with DOEVENTS and grid having focus. Try to set focus outside of the grid for duration of the process, call DoEvents before saving to make all events for grid finish, set _VFP.AutoYield to .F. and run updating process again.


>I don't like the idea of setting buffering to 1 and back to 5, it woyuld not work in our framework...
>

Setting buffering from 5-th bufferng to some another (1st) is not allowed until you will save all changes or revert them.

>Anyway, thanks. I'll try to investigate more on this problem on Monday.

One thing comed to mind: Are you sure updating process is optimized? I meant, for views usually key field is used and only key field is included in the updating "WHERE" clause, so updating of each record in alias looks like:
UPDATE MyTable SET field1=value1, ... WHERE KeyField=KeyValue
I guess when you use table buffering for table, it is definitely slow because default settings for UPDATE command is no key field and all fields are included in the WHERE condition. As a resul, updating is way too slow. In such case I would recoomend you to use the view with properly defined key field and WHERE clause setting.

HTH.