This is exactly why I didn't suggest that approach myself but asked for more clear information. Heading off in that direction if it's not necessary is definitely something to avoid.
A response to my earlier post may help to find a more "Access" based approach.
I think I had my fingers rapped by mentioning unbound forms! but I totally agree with NeoPa not to go down that route unless absolutely essential. As soon as you do, you lose lots of "Access" features and are effectively writing VB with Access tables.
With ref to Gibbo, the way "Access" wants to work is to click to add a BLANK record and then update it. You can verify each field as it is entered so why would a user want to abandon data? If interrupted, the job can be completed later rather than restarted. The default (including clicking Exit) is to automatically save the data rather than relying on the user to press a 'Save Data' key.
The Form_BeforeUpda te event is a good place to check to confirm or escape saving the data if a user felt it was incorrect or incomplete but any Autonumber fields will already have been incremented (and may have been incremented further by other users). This could result in a gap in Order numbers and the like. If this was important you could consider writing the missing numbers to an audit trail, as even this would be less hassle than an unbound form.
In 'older' systems you used to see separate screens for Add, Edit, Browse etc and this is possibly where the urge to 'click to add' has come from. This is another route not to go down on a whim!