Oh, and yes, I never really sorted out the difference between refresh, update, and save and I ended up just using save as a heavy hammer to get the grid back to where I needed it for the next user or action sequence operation. The documentation has not tended to provide detailed technical information as to how to choose among those actions.
Also, my suspicion is that some of those Grid actions were originally coded expecting a performance improvement if Saves are avoided. Refresh or Update may have done something within the context of the browser cache of the grid contents without going to the server and back. But, the Save action is so fast that I see no performance problem using Saves recursively in a grid edit session with a user interaction.
The more experience I have with screen design for user interaction the more I like frequent saves. Getting users to understand their changes are not committed until a save is performed harder to do than to allow them to change something after the save occurs and I tend to see some odd results when a full save isn't performed at key points. There are some values like Totals on Orders and Invoices that only come from Quickbooks. When a user enters a Quantity and a Price, the Amount is always a calculated value and the save must synch back to QB to get the result. This is a nice feature as QB is holding onto some data integrity for certain financial calculations.
Anyway, for what it's worth, I think full saves are good and folks shouldn't be afraid to use them liberally.
Cheers,
James