Jim,
I know exactly where you are, I was there several years ago. You are trying
to impose some expectations for visual and operational concepts that really
don't apply in an Access world.
First, by using unbound forms, you are giving up most of the power of
Access. There is a lot that is done for you that you don't have to code for
using bound forms; otherwise, you have to do all your own data loading,
validating, moving back to the recordset, and updating it. I know, the first
project I was involved in using Access was all done with unbound forms. It
took almost two years. Had we done it correctly, it should have taken about
six months.
Because of the power you have using bound forms and if you use your events
to validate and control the entry of data, you don't need to worry about the
user having to click a specific button to update the database. The control
level and form level Before Update events and form level Before Insert events
give you all the opportunity you need to cancel an update if the data is not
correct. This can even include presenting a Message Box to the user to warn
them they are about to update the record. Proper editing and validation is
much easier to do than it is to code to prevent an update without using a
button.
Going to a new record after every update is one way to always provide a
blank form to the user; however, continually adding and deleting unused
records does at least two things. It will contribute to database bloat - not
significantly, but to some degree. If you use Autonumer fields in any of
your tables, it will cause a lot of unused numbers. Not a real problem if
you use Autonumber fields correctly, but it is something to be aware of.
My suggestion would be that you use bound forms, include good validation,
and don't worry about the user seeing the current record on the form.
