>1.) Edit on demand
>2.) Confirm save message with checkbox(ala Netscape) "Show this box next time". This flag would need to be reset each time the app is fired up but would be retained for the duration of the current session. (I've also considered disabling the checkbox for new users)
>3.) Revert Edits button with messagebox confirm.
>
>This approach allows power user speed and gives some protection from doing thing accidentally.
>
>For vital information that wouldn't be changed on a regular basis, it might be worthwhile to put some field-level controls either in the DBC or in the field control.

Thanks for the input...we have power users also.
1.) We're doing this too...it's another user obstacle removed.
2.) We're seriously considering, but are concerned that it will cause a variable "standard" among users. If we get serious about it, we'll add it to a user settings table or ini (on our non-core list right now).
3.) We have this, but are considering doing away with it on all but app Exit, and even there we're not sure.

What we're focusing on is obviating Save/Revert situations (except Exit)... Stocking a separate user table of transaction/audit trail, which is available to each user in a grid to revert any edits they've ever made in a certain allowable timeframe (for us, that will be a month, probably). A little work, but we all like the idea here...then we can go to automatic Saves (if no integrity errors, etc.), but field reverts will be available for quite some time...

My thinking on Exit, I guess, is that although DB apps are different in nature from apps like MS Word, when exiting they are similar, that unresolved edits should probably be prompted...