>This concept is great. 'Trust the user' if he/she know's what they are doing, then the work is smooth and seemless. If they don't hmmm, there is always the cancel button. But I bet a user spends more time in the 'I know what I am doing' "State" than in the 'what am I doing' state, in the long run.

New user is mostly in "what am I to do now" mode, and experienced user will never admit he was in "I thought I knew what I was doing" when he blew it.

>You need a double buffered table. One table has the same information but no rules. The user fills out the form, on the unprotected table, at their leasure, then when thay want to commit, copy the record into the rules protected table. Report any errors back to the user. And for bounus points, focus the field with the problem. Here a Save button would work nicely. 'Save (for later)' 'Commit (Apply? to disk.)' 'Cancel (last changes)' and 'Abort (the whole thing)' The names need work, but the concept is there.

I've seen accounting apps done with this double buffering scheme. The records were added to a daily table, and once verified, they were copied to the master table, which was read only, and marked as untouchable. It worked, but set lots of new rules upon the user, which they didn't like. Needles to say, they still managed to pass the controls regularly, and commit unbelievable errors. Formal control is not omnipotent, so it's kind of equal whether it happens on-the-fly, or at some later stage. There will always be an user who will bypass it this way or other.

Another thing - these apps had great problems if they didn't develop a bulletproof method of copying the records. Once the copying didn't work (power surge, accidental reset), or it worked partially, they were in trouble, and had to call the programmer.

>Apply = Save ;)

Savings account = Appliances account :)