Erik,

YES! it works! thank you, thank you.

>This should be no problem. But before we go any further you should be clear on the difference between Table and Row Buffering. Row buffering buffers ONE row at a time. IOW, if you have a row buffered view open, and you make changes to the first row, and then click on the next row in the grid, VFP does a TABLEUPDATE() for you. This is why I NEVER use row buffering. You have no control over when, and cannot read the return value from a TABLEUPDATE. IMHO, Row Buffering usually does nothing but make things a horrible mess. If one of the tableupdates fails, you don't know it (or you get an error), and you are left with a dirty buffer that should be reverted. What I just said above is basically what the Hacker's Guide was trying to tell you.
>
>With Table Buffering, no changes are sent until you explicitly call TABLEUPDATE().

That is clear and concise and has helped my understanding greatly (I'd always thought table buffering was mainly for when you wanted to change more than one row at a time). Or MAYBE just hearing/reading something for the nth time helps it sink into my thick head. You've won a convert to table buffering.


>And this is where I think you were being thrown off. You were reverting changes to one record, and leaving a dirty buffer in another (it was still dirty because VFP's TABLEUPDATE() failed and didn't tell you)

Repeating what you wrote above: "IMHO, Row Buffering usually does nothing but make things a horrible mess."
It sure does...I didn't know WHAT was going on.


My problem now, however, is creating an index on my view...kind of related, but off this subject...will start another thread.

J