Inserting the records on click of command button in MSAccess form

This is a bit of a strange question as the form will handle adding and changing records if the datasource is bound.
You can stop this in the form's Form_BeforeUpdate() event procedure if you want.
I'm not sure how you're getting the add to work behind your button. Perhaps you could post the code (remember to use the CODE tags).

The reponse you are describing can be achieved using an UNBOUND form but this is a BIG DEAL because you must then write your own code to write data into your controls in the first place, then seperate code to sequentially read the controls to save changes to the database. If you want navigation controls..you must write your own!

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 actually was wondering how to do the same thing. I am using a form to enter some data into a table, but instead of automatically being entered into the table I want it to be added upon clicking a button.

I am a complete newbie when it comes to Access, but I understand the difficulties in making the text boxes unbound and then having to write code to support the entering of the data.

So, is it possible to enter something in a form and not have it update the table until after you click an "update" button? And if you entered all the data in the form and then clicked exit, it wouldn't add the data to the table.

Thanks for the help.

As this is pretty much on topic - I'll leave it in this thread (Questions from different members should normally be in their own separate threads).
The way to do this is to have event procedures in all the places that could otherwise trigger an update, and set the Cancel parameter to False when you don't want the update to occur.

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_BeforeUpdate 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!

I think I had my fingers rapped by mentioning unbound forms!
...

Obviously you understood where I was coming from Sierra. I detect an experienced hand :)
In truth though, my intent was to warn the OP rather than have a dig at you per se. I look forward to coming across more of your posts :)

* Edit *
Rereading my post it does sound more personal than it should - My bad.