D
david epsom dot com dot au
tables for entering/updating data. That way they can accept
In our case, the data goes to an action table, a movement table,
an audit table, and a history table. Data comes from user entry,
the history table, or an action table. The data source tables have
slightly different formats from each other, and sometimes it is
necessary to bring back data from the movement table as well.
It is possible to reduce the number of forms, and easier to optimise
the data load process, when using unbound data, and it simplifies
the transaction process when saving data. We could just use an
unbound form, but bound forms and table data offer a number of
advantages in Access, so we bind to a local table.
We think that people doing New Records don't need undo very much,
but that people doing Modifications should be able to undo.
Unfortunately, Access sometimes wants us to commit, before doing
some lookup and calculation queries that need the data, or changing
focus to another form. For us, the easy way to commit temporary
(uncommitted) data, is to commit it to a local table. There are
other ways, but this works for us, and it matches our needs as
outlined above.
It is not something we do on all, or even most of our forms. We have
20-25 of these forms out of the hundreds in our primary application.
Most of our forms are bound to only one table, and the data is
automatically committed if the user closes the form or changes records.
Historically, most of the system (all those simple forms) used
separate data entry and data modification forms. We have moved
away from that for aesthetic reasons, but it still seems to me that
it is tricky to get good control of commit/undo on a bound form
where the data may be either 'new' or 'dirty'
(david)
In our case, the data goes to an action table, a movement table,
an audit table, and a history table. Data comes from user entry,
the history table, or an action table. The data source tables have
slightly different formats from each other, and sometimes it is
necessary to bring back data from the movement table as well.
It is possible to reduce the number of forms, and easier to optimise
the data load process, when using unbound data, and it simplifies
the transaction process when saving data. We could just use an
unbound form, but bound forms and table data offer a number of
advantages in Access, so we bind to a local table.
We think that people doing New Records don't need undo very much,
but that people doing Modifications should be able to undo.
Unfortunately, Access sometimes wants us to commit, before doing
some lookup and calculation queries that need the data, or changing
focus to another form. For us, the easy way to commit temporary
(uncommitted) data, is to commit it to a local table. There are
other ways, but this works for us, and it matches our needs as
outlined above.
It is not something we do on all, or even most of our forms. We have
20-25 of these forms out of the hundreds in our primary application.
Most of our forms are bound to only one table, and the data is
automatically committed if the user closes the form or changes records.
Historically, most of the system (all those simple forms) used
separate data entry and data modification forms. We have moved
away from that for aesthetic reasons, but it still seems to me that
it is tricky to get good control of commit/undo on a bound form
where the data may be either 'new' or 'dirty'
(david)