My problem with all of this is that this is not reproducible by Microsoft or anyone else, as far as I know. Aleksey has not offered repro code, I haven't been able to come up with any (though I have a few things left to try), and another poster on this same error said he could not reproduce it. Aleksey has said that it won't happen all the time and has suggested that it should be fairly uncommon, but that the grid could become "confused" and this error could result. Well, that kind of sounds like an error, not the "by design" issue that he claims it is. Plus, this is definitely not just happening on the view associated with a child grid. It also happens when performing a REPLACE on the main table in the form that has nothing to do with the child view or the grid that displays it. Personally, I think MS has a bug here that they are simply not able to reproduce (and we all know those bugs are hard to fix). So for now it's getting ignored.

Russell

>Hi Aleksey,
>
>I understood the reasons for erroring out modifications to be the table specified as datasource modified via code while in the grid's "buffer" still other changes are pending. For instance a replace originating from a valid would throw the error.
>
>Would a
>
>this.value = m.lcChangeCausedByValid
>
>called form the .valid or a method called from there add the changes to the "grid buffer" or directly modify the table as well ? At the moment I have only a dim recollection of a change *after* finding an error in the release candidate [when burning midnight oil...] for a client some time ago. But perhaps you know these "nagging feelings" when some "quick fix" worked and you have no idea why and no budget to really verify...
>
>thx
>
>thomas