Thanks, but how's that going to help me? The user has made changes and is not interested in reverting them (I am using table buffering, of course). So that's just not an option.

I noticed that you've spent some time on this bug in other threads. Is there a fix for this coming in VFP 9? I'd hope so. VFP doesn't play as nicely with grids and views on forms as it should. There are some lingering bugs in this area that MS really should fix, but they seem to be ignoring them.

I just read another thread on this from about June of last year and am still unclear on a reliable and clear workaround for this 2072 error, but I need to re-read it a bit slower this time (I was looking for that quick and easy solution <g>).

Since you are with MS, I'll take a moment to mention a serious bug that I hope MS will fix in VFP 9. You can look at code that reproduces it under download ID 25282 - I don't know how to reference it with a link, sorry. You can search in the download section under my last name (Campbell) - I'm the only Campbell to submit anything so it will only list my file. In short, this is a situation where VFP just moves the record pointer for no apparent reason when a grid is refreshed. The sample form demonstrates it quite well.

So if that bug got fixed and this 2072 bug got fixed, that'd be a great thing. I look forward to VFP 9 - the new features look fabulous, but fixing bugs is an important thing, too!

Thanks,

Russell


>>The only workaround I have seen is that someone suggested saving prior to inserting records. Well, that's not workable. I need to be able to give my users the ability to save or cancel a tranaction as a whole and this "workaround" prevents that.
>>
>
>Hi Russell,
>
>Use table buffering and you will be able to revert the change later.
>
>Thanks,
>Aleksey.