Full Version: Preventing A "save" Until Save Button Clicked
UtterAccess Forums > Microsoft® Access > Access Forms
Hello, Experts.
I have a form for tblTrainingRecord that records what training, date trained, etc.
I have a subform that allows the user to choose which employees were trained.
I would like to prevent saving ANY training details to tblTrainingRecord unless a) an employee is chosen or b) the user clicks Save Record.
Is there an easy way to do this or am I approaching the problem incorrectly?
HAs always, thanks in advance.
Doug Steele
You saying you don't want a record saved from the parent form (i.e.: a record in tblTrainingRecord) unless something's saved in the subform? It's not possible. The subform cannot save its record until the parent form's record has been saved. That's because it needs to know the PK of the parent form's record so that it can store it as a FK.
Hi GG,
aving a form/subform setup complicates things a bit because Access will automatically save the main record as soon as the user moves the focus to the subform. The only way to avoid that is by using unbound forms, which would require some code to implement.
What you could do, as an alternative, is to run some code to check if there are missing information when the user tries to close the form or move to another record and then either tell the user to go back or delete the incomplete record.
Just my 2 cents...
ssuming that the main form is the one used to choose an employee and the subform is used to enter training details, another approach would be to -
a) Disable the subform control until an employee is chosen from the main form, effectively preventing any training records being entered beforehand
b) Bind the form that's being used as a subform to a temporary local table (which would be a copy of the actual tblTrainingRecord table). If the Save record button is clicked, use a query to add the records to the real tblTrainingRecord table, otherwise just delete any records from the temp table ready for the next temp records
here's no way to prevent a save when navigating from a mainform to a subform (or vice-versa). This has to happen because in order to enter child records in a subform, the mainform must first be saved so the Parent ID of the subform record can be referenced.
You may consider using a private level flag variable to indicate when a user starts a new record (on the mainform). Flag this is Saved when the user clicks your button - the records themselves will save as the user navigates between the parent and child, but if you must you can delete the main (and child) records later if that flag did not get set. The only inherent problem here is that the form doesn't provide a way to tell you when the user is done with that record in particular. Therefore, you need to check on the form's Close event for the flag, as well as on the Current event by checking (yet another) private variable that holds the last record's ID to see if it was saved. All in all, to do this correctly, it involves a small handful of flag variables private to the form's module, and a lot of event programming and logic to make sure all the cases are covered.
All in all, it's usually just easier to come to some solution that involves setting a status field in the record itself when the user clicks Save. Then base all subsequent queries off records with a "saved" status, and you will then only work with records where the user specifically saved, and while others may linger they don't generally bother anything (a similar concept to not deleting records and instead using an active/inactive status field, with "deleted" records being inactive).
HAs a startup/shutdown procedure for the database, you can always set up some housekeeping to delete records where the "saved" status isn't set.
(slowing down some Alan... you sure that's just tea now?? ohyeah.gif )
Yep - still just tea (sadly!!). All these young 'uns are just too quick f
Thanks, All, for your comments and ideas. It never dawned on me that the subform HAS to have the main form data saved before it can transfer and bind with the primary key. DUHmb of me!
Ok. Training details (main form) without employees trained (subform) is worthless.... so.... I suppose maybe I'll switch the underlying form to a temporary table, bind the suform to that, and append dirty records on close. Does that sound like a reasonable plan? I didn't want to have to make this any more elaborate than I absolutely have to... but it looks like I have to, right?
Doug Steele
Not sure I agree that training details without employees is worthless. For example, we look at details of courses and document those that we think we might be interested in. That way, we have a catalogue available. If nobody takes the course in a certain period of time, perhaps you picked a bad course. However, perhaps you don't need that.
Doug: The sole purpose of the database is to record employee training. If the employees weren't training, we don't care. :-)
Crud. What a pain in the bottom. Why can't freaking Access every be EASY!?!?!?
It can be, but this isn't one of those times. I generate training records where I don't know exactly who will attend (all-employee meeting, for instance), in which case I fill in the people later. That may not happen with you, but it could be that you want a little bit of wiggle room.
If you can construct a query that shows only the records you want to get rid of (maybe ones created more than a day ago, or something like that), you can set it up as a delete query that you run on the form's unload event. Other than that, the temporary table idea may be the best choice.
I think this whole thing would be easier to do if you put the employee records in the main form and the training records in the subform. Now when an employee is selected the subform would display his training records.
I would favor a Training Record table, an Employee table, and a junction table to record enrollment in a specific training session. That way the user could create a training record and assign employees, or view employee records and see which training sessions they have attended. I am working on the assumption that training may be for a one-time specific situation (e.g. maintenance of a new piece of equipment) rather than a specific course. With a course there may be individual sessions (fall 2011, spring 2012, etc.), but the general idea would remain the same.
With a course list or something of the sort it would be possible to start with an employee record and assign training, but either way it seems to me a Session record would need to be created before Employees could be assigned to it.
A little information on what is being called "training details" would be beneficial to the discussion.
My guess is that the data structure involved may not be completely thought through.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.