I definitely would NOT expect a quote to be formed.
And it wouldn't be because they use validation. They still save the incomplete form though. But, you can be pretty sure they know you started filling out the quote and will send you an email asking you to finish. Look at the way this forum works. Start typing a reply. Then go to some other thread. When you come back to the first one, your partial reply will still be there.
We are talking about an opinion. However, you should not confuse the newbies into thinking that they can't control whether or not a record gets saved. I personally don't care if you use Me.Undo whenever a user makes a data entry mistake as some developers do. Your user might complain though
Agree with what you are saying, but sometimes there aren't really good options.
But there is an excellent option. Use the form's BeforeUpdate event to validate the data. If it is invalid, cancel the save. If you want more control over how a user saves, then give him a Save button. If he doesn't press the save button, you can assume he didn't intend to save and prompt him. That is minimal extra work. But you still need validation code in the Form's BeforeUpdate event.
YOU, the developer, need to protect the user from making a mistake as best you can. That means, you always include validation code in the form's BeforeUpdate event and if you also want the user to only save "consciously", then add the Save button and the code that goes with it.
A developer before me came up with an Undo and a Save button and called it good, but he didn't realize that the data was still saved automatically first. i.e. if you clicked the save button you saved the data. If you clicked Undo, you went back to how the record originally was. If you didn't click Undo and also didn't click Save, the record was saved.
I wonder if he was the developer who wrote more than 5,000!!!!!! lines of code to validate the data but never managed to get any into the form's BeforeUpdate event.
If you want to complain about Access' methodology, you might want to complain about the lack of useful help over views.
Some fields can't be easily validated. We have a Notes field and it will just contain text. The computer can't logically tell if the text makes sense. If someone changes the field contents to YYYYYYY - there isn't much you can do other than saying "Did you intend to change this field?" which is more annoying than asking "Do you want to save this record?"
Of course you can't always ensure that data is correct. But, it is your job to do what little you can do. Don't just throw your arms up and not bother to validate anything. For example, for text fields that are required, you ALWAYS set Allow Zero Length String to No. The user may enter gibberish, but he has to enter something. You always check dates for rationality. It makes no sense for a DOB or DOD to be in the future. You can enter future sales orders but usually, there is a limit to how far in the future would make sense. In other people's databases, I frequently see dates like 1/1/202. As far as Access is concerned, that is a valid date. But, unless you are writing about something that took place in the Roman era, you probably want to flag that as invalid. You can't stop a user from entering Blue when he should have entered Red but you can stop him from ent3ring Green if Green isn't a valid value.
There are SOME things you can do. Many databases have a Lock/Unlock button before you can edit a record.
That is one of those feel good but unnecessary things unless your users are real klutzes or like me, have a cat that jumps up on the keyboard. But changing colors and enabling buttons helps to keep the klutzes from doing real damage.
The reason I say that the lock/unlock is unnecessary is because it still doesn't keep the user from being a klutz. They just have fewer accidents. Using a specific Save button can stand in for this code. If the user doesn't press the Save button, you prompt him rather than just accepting the entry if it is valid.
