>>Not sure how that would work... The problem is that with buffering, the records aren't actually in the table for the SQL to act on. Wouldn't you have to commit the changes for it to work? What does turning buffering off when there are uncommited changes do?
>
>Yes, of course, you do have to commit. Generally, I keep grids on separate non-editable pages/forms so that this isn't an issue, save/revert is already done before you get there...but for certain situations, you may need to commit changes prior to the SQL. We do all our saves automatically, so I just put a TABLEUPDATE() before removing buffering if need be. It's all invisible to user, and they know saves are automatic.
>
>If you have to have user confirm Save/Revert, you'll probably want a "diplomatic" message about saving needing to be done before running new query, similar to your regular save message. Or better, just plan the grids so that they're on non-editable pages/forms...

The grid isn't editable, but the user needs to be able to get rid of what's in the grid. It's complicated. I've got it working now, though.

Thanks,

Michelle