I have implemented your example and it is not writing either start or stop to the table.
I told you what events to use. You have NO code in ANY form level event. You have code in your button. That won't do it. I can't even figure out what the app is supposed to do. Something about undelivered mail so it sounds like this is the USPS and I'm paying for this app. I'd really like to help but you could not have made the design more cryptic if you tried. It is completely undecipherable to someone who doesn't know what the abbreviations mean. I have no point of reference. It must hurt even your head to remember what letter you used for each column name. There has to be some rational happy medium between a single letter and 32 letters with special characters and embedded spaces which is what we usually see.
Time() stores only the time. You really need to use Now() if you care about the date and you should.
DoCmd.Close acForm, Me.Name, acSavePrompt
This command does not save a record. It saves a form. Do you really allow users to change the design of a form? It is generally poor practice to save design changes made by users. Close the forms without saving.
Suggestions,
1. Do NOT prefix column names with the table. This is unnecessary and as you can see by the DS subforms, obfuscates the name since all you can see are the first few characters and they are all the same. You can fix this by opening the form in design view and changing the label caption so something more meaningful.
2. Standard abbreviations are OK but single letter abbreviations are meaningless. It is quite possible that I wouldn't know what the columns and tables are supposed to represent even if you spelled out their names but as it is, I have no clue and I've been doing this for a very long time so I'm pretty good at "interpreting" questions and database schemas.
3. When you make a relationship, enforce Referential Integrity. That is what relationships are for.
4. Relationships are easier to "see" if you give the FK the same name as the PK it relates to. So UNI in UN should be LocID and so should TDI in TD and RCI in RC, etc.. FTcat in FT should be FTCID. Loc is the only table with a decipherable name but the data contained doesn't relate to anything I would consider a location so Loc must not be location.
5. If you are going to sort the name comb on last name, reorder the columns to Last, First. rather than First Last. That will allow type and filter to work correctly.
6. You also seem to be storing name mushed as well as separated. This is not necessary and can lead to data anomalies if you are not careful with your name change process. And I can't be sure how it happens but it looks like you have copied the full name to multiple tables rather than relying on a join to bring the tables together.
7. You cannot rely on a control getting the focus to populate it because unless the user actually places focus in the field, your code in the GotFocus event will not ever run. If you want to populate fields with data from some other place, do it all in the Form's BeforeInsert event. That way as soon as someone starts typing in ANY field, the data can be copied but You should NOT be copying data fields unnecessarily. I see Me.UNDfd = Me.Parent.Text34 -- there are several things wrong with this starting with controls should always be given proper names so Text34 is unacceptable. But more importantly, if the value for all rows in the subform will be the same, then the data belongs in the parent table. FolderDT is unbound in the parent record? why is it there? Why are you copying it to the subform record? If you want to use a default for the subform, you need to find a better way to populate it or put some validation in the code to ensure there is a value.
I've given you a lot of advice but I don't think I've actually helped you. I can't follow the logic you are using for creating the time records and so I'm pretty sure that the mis-understanding is preventing you from properly applying my suggestions because they don't make sense to you. If you can rebuild the tables and forms with meaningful names we might be able to get someplace. I and the others helping you will have firmer ground on which to stand. Plus, you'd be doing yourself and anyone who has to maintain this app after you a huge favor.
This won't be as onerous as it could be. This is one case where I'm going to suggest that you turn the Name Auto Correct feature on. Experts refer to it as Name Auto Corrupt because it is actually quite dangerous. But this is a case where it will help you. But, be very careful to follow my directions or you'll end up cursing my name.
Start by making a backup and zipping it. It is safer that way since you can't accidentally change it. Then turn on the feature if you have it off. Make yourself a note to go back and turn it off IMMEDIATELY when you are done changing the names.
Then table by table rename the columns and save the table. Then rename the table name. If you have the patience, open every form, report, and query, the changes will be applied as you make them. You don't have to do this though, you can let them stack up just as long as you don't double up and change something twice before you propagated the first change. The "corrupt" part gets people because they don't understand when Access propagates the changes. The answer to that is - not until you next open an affected object. So if you make a change but fail to open an affected object, you may make a different change and Access gets lost. So just be patient and work through one table at a time. This "feature" does not modify code so you will then have to go into each form and compile it to find the compile errors generated by the name changes. I think what happens in forms is if the name of the bound field = the name of the control, NAC will change the name of the bound field and leave the name of the control alone. This means that your code will continue to work because Access will assume that you are referring to the control and in newer versions of Access, you can do this. It is also helpful to turn on the LOG feature since that will enable you to see the actual propagation as the objects are changed.
There are utilities out there that will do mass changes but they can also be dangerous although they do change more things for you all at once. If you get a utility that does mass changes, do ONE change at a time and be very careful. Don't take shortcuts. Spell out the entire name. If you change "UN" to "UNC" that will change undo to uncdo so, take care. Make a change. Then compile to make sure you didn't break anything. Save early. Save often because 10 changes in, you could break something that you can't fix. Access' NAC does the changes very differently and so doesn't have this particular problem. It has others. I will attach two documents you can read if you want to actually understand how NAC works. One is a document created by MS and the other is a ppt that I created when I gave a presentation to an Access User's group on the topic. Since it is a PPT it doesn't have a lot of words but it does summarize the actions if the doc is too dense. I also included a database to practice on.