Preventing Autosave on form with multiple subforms

  • Thread starter Thread starter microb0x
  • Start date Start date
M

microb0x

I have an application with a master form with a tab control containing
nine tabs, each tab contains a subform. I have command buttons on my
main form including: Save , Cancel , Close.

My question is, how can I prevent Access from auto-saving changed or
entered data on both the main form and any subform?

The main goal is to force the user to use the 'Save' button to save any
data. I need the 'Cancel' button to just undo any changes since
opening the form or since last save. And I need the 'Close' button to
just close the form without saving any changes since last time 'Save'
button was clicked.

In previous applications without subforms I was able to accomplish a
similar scenerio with using me.undo in the unload event of the form
and/or on the click event of both the Cancel and Close buttons. This
doesnt work with the subforms, because the command buttons are on the
main form and not each subform, nor would I want that. It is also not
working all the time with the data on the master form, certain
scenerios are still saving data when closing the form. It is also
auto-saving data on the subforms as I move between the tabs, I would
like to prevent this as well

Is there anyway to accomplish this goal? Only thing I could think of
would be to make each subform and/or field unbound, and pass the data
to the tables only at the time of clicking Save. Are there any other
options as this would be a lot of code for 9 subforms, some with as
many as 20 or so fields to populate?

Any guidance is appreciated as I'm on a tight time schedule to finish
development and deploy this app.
 
I don't think there's any way to do what you want with Bound forms. I also
think that doing it with unbound forms is going to be very difficult.
 
Your the expert Doug, am I just SOL? Is there no way to do this? I
can't be the first person to ever have this issue..
 
While there may be ways around it, I wouldn't recommend them, as they're
going to be complex to code and therefore prone to error.

The problem is that a well-designed database has referential integrity in
it. That means, for instance, that you cannot add a child record if the
parent doesn't already exist, which means that the record from the main form
must be added before the record from the child form can be added.

Yes, you can use unbound forms, and go through all sorts of manipulations to
ensure that you do everything within a transaction that can be rolled back
if the user decides not to save the results, but is it worth it? What's
wrong with just deleting the relevant records if the user decides to abort?
 
The issue doesn't involve the creation of new records so much as users
pulling up existing records and modifying. So there wouldnt be any
record(s) to delete. They problem found during my UAT was that more
often than not users had existing records on their screen, made a few
changes, realized they didnt have enough information infront of them to
complete the changes they wanted and tried to back out their changes to
go do more research.

I do have referential integrity setup across all the related tables,
and I am forcing the user to create the record in the main form before
allowing imput into the subforms.

So without going unbound I can't think of any other way to ensure the
ability to roll back changes. Worth unfortuneatly isn't a factor I can
consider as those are the design specs I kind of have to adhere to.. :(
 
microb0x said:
The issue doesn't involve the creation of new records so much as users
pulling up existing records and modifying. So there wouldnt be any
record(s) to delete. They problem found during my UAT was that more
often than not users had existing records on their screen, made a few
changes, realized they didnt have enough information infront of them to
complete the changes they wanted and tried to back out their changes to
go do more research.

I do have referential integrity setup across all the related tables,
and I am forcing the user to create the record in the main form before
allowing imput into the subforms.

So without going unbound I can't think of any other way to ensure the
ability to roll back changes. Worth unfortuneatly isn't a factor I can
consider as those are the design specs I kind of have to adhere to.. :(
Click to expand...

Create a duplicate set of "archive" tables. Have your form locked down by
default and provide an [Edit] button that unlocks everything for editing. In
the code behind that button have the first thing it does be to copy the parent
and related child records into the archive tables.

You can then have a [Rollback] button that replaces the live data with the data
in the archive (after which the archive record is deleted). You can also have a
[Commit] button that simply deletes the archive record when the user is sure
that the new changes are correct and complete.
 
Back
Top