[B]How to stop access from saving the record when the[/B]
- Thread starter Chipcom
- Start date
boblarson
Smeghead
- Local time
- Today, 00:42
- Joined
- Jan 12, 2001
- Messages
- 32,040
Do you mean, how do you stop the main form from saving the record when moving to the subform? If so, you can't. Unless you don't make any changes to the main form. The recordsets are separate so when moving to a different recordset the form will automatically save.
How to implement any of the two ways?
Here is the answer from other forum:
"If you mean that you want to keep the main form's record from being
saved when the subform gets the focus, the only ways you can do that
are:
1. Have the main form be unbound. In that case your own code has to do
the job of reading the record, assigning its field values to the
controls on the form, detecting whether the values in the controls have
changed, assigning them back from the controls to the fields in the
record, and saving the record when you think it is appropriate.
2. Have the main form be bound, but keep all the controls unbound. Your
code has to navigate the form's recordset and assign values from the
recordset to the controls on the form, and then back again when you're
ready to save the record. Since the changes to the controls don't
affect the form's recordset directly, those changes won't be saved when
the focus goes to the subform, only after your code assigns the values
from the controls to the underlying fields and then you navigate the
form to another record, or close the form, or otherwise force a save.
--
Dirk Goldgar, MS Access MVP
www.datagnostics.com
"
But I don't know how to implement any of the two ways- any Idea?
Here is the answer from other forum:
"If you mean that you want to keep the main form's record from being
saved when the subform gets the focus, the only ways you can do that
are:
1. Have the main form be unbound. In that case your own code has to do
the job of reading the record, assigning its field values to the
controls on the form, detecting whether the values in the controls have
changed, assigning them back from the controls to the fields in the
record, and saving the record when you think it is appropriate.
2. Have the main form be bound, but keep all the controls unbound. Your
code has to navigate the form's recordset and assign values from the
recordset to the controls on the form, and then back again when you're
ready to save the record. Since the changes to the controls don't
affect the form's recordset directly, those changes won't be saved when
the focus goes to the subform, only after your code assigns the values
from the controls to the underlying fields and then you navigate the
form to another record, or close the form, or otherwise force a save.
--
Dirk Goldgar, MS Access MVP
www.datagnostics.com
"
But I don't know how to implement any of the two ways- any Idea?
- Local time
- Today, 02:42
- Joined
- Feb 28, 2001
- Messages
- 30,566
If you are using bound forms, Access does a huge lot of things automatically for you. Like identifying changes to control values, taking updated data from bound controls, copying the values into the proper fields in the underlying recordset, saving the current record, moving the recordset to the next record, and populating the controls from the new record. It does this when you leave the form for something else (as signalled by a LostFocus event, e.g.) so that you don't have accidental data loss.
If you have a few controls, this is not that hard to manage manually. Just very tedious. When you have complex controls, it goes beyond tedious into mind-numbing.
If you don't want that automated processing to happen on a form, you have to do all of that stuff I listed earlier "by hand." You have to take over record management, which involves "breaking the bonds" between the form's bound controls and the underlying recordset.
I am not trying to be disrespectful here, but if you didn't understand what is involved in the very direct answer quoted from the other forum, you aren't ready to do this by hand yet.
To get to that point, study RECORDSET operations and form events so that you will learn HOW to do this by hand. Access Help exists for recordsets and form events. Read the sample databases.
If you have a few controls, this is not that hard to manage manually. Just very tedious. When you have complex controls, it goes beyond tedious into mind-numbing.
If you don't want that automated processing to happen on a form, you have to do all of that stuff I listed earlier "by hand." You have to take over record management, which involves "breaking the bonds" between the form's bound controls and the underlying recordset.
I am not trying to be disrespectful here, but if you didn't understand what is involved in the very direct answer quoted from the other forum, you aren't ready to do this by hand yet.
To get to that point, study RECORDSET operations and form events so that you will learn HOW to do this by hand. Access Help exists for recordsets and form events. Read the sample databases.
- Local time
- Today, 02:42
- Joined
- Feb 28, 2001
- Messages
- 30,566
You can lock the record. You'll start getting error messages saying "Cannot update; record locked." They will occur when the parent form loses focus.
If you change something through a parent form, Access updates it at the first chance it gets. The problem is that depending on what you changed, you might be causing all sorts of havoc. If there are child records and you change the parent, you are IMPLICITLY changing every child through the logical extension of its parent relationship.
Unless the sub-form is not linked to the parent form, that is... in which case I have no clue of what you are doing.
The factor that gives me heartburn is that if this is an adapation of a business model, it is not very precise. You should NEVER be able to change an existing parent record on the form that allows you to enter child records. A parent change should have its own form.
What you are doing just isn't safe programming. What if you only meant for the changes to apply to some of the child records? You can't do that without first splitting the parent record into two separate records that differ by whatever you just changed. Otherwise, you just propagated that change to a lot of places.
If you change something through a parent form, Access updates it at the first chance it gets. The problem is that depending on what you changed, you might be causing all sorts of havoc. If there are child records and you change the parent, you are IMPLICITLY changing every child through the logical extension of its parent relationship.
Unless the sub-form is not linked to the parent form, that is... in which case I have no clue of what you are doing.
The factor that gives me heartburn is that if this is an adapation of a business model, it is not very precise. You should NEVER be able to change an existing parent record on the form that allows you to enter child records. A parent change should have its own form.
What you are doing just isn't safe programming. What if you only meant for the changes to apply to some of the child records? You can't do that without first splitting the parent record into two separate records that differ by whatever you just changed. Otherwise, you just propagated that change to a lot of places.
Similar threads
