>>Hi everyone,
>>
>>I noticed, that if we use Table Buffering (BTW, we decided today to switch to record buffering, because it's dangerous, that user may hit revert button and revert all changes made),
>
>FWIW, you can code so that the effect is the same as record buffering w/o using record buffering. (Thanks to Jim Booth for this idea.) His point was that record updates happen at unexpected times with record buffering that interfers with an application. If you _code_ to save changes on the record level, _you_ are in control.
>
>An example I can think of is a grid that has a field that affects a calculated total. You have to change the record pointer (perhaps) to recalc, but you don't really want to force the user to save the change yet.
>
>JMO.

Right. However, for this particular application I don't have any calculations and unexpected record moves.

>> when we try to move scroll button on scroll bar, it doesn't move and stays unchanged. I'm wondering, if somebody else experienced this behavior and does it have a cure?
>
>Is this related to record vs. table buffering? I'm wondering if there's something else going on here. I don't see how it's related.

It seems to me, yes. Here is the simple test, I just made. I ran the form, made couple of changes and then moved scroll button to the upper position. Now I'm trying to move this button, but it resists. Once I revert/or TableUpdate, I'm able to move this button again. I showed my code in answer to Marcia, though I don't see, how code in AfterRowColChange may influence on scroll event...

Could somebody else replicate this problem? The file has just 1406 records...

Thanks in advance.