Me looking at your database isn't going to help you to understand how it needs to change but I do have a better idea of exactly what is causing the problem with the code you are using. You are very new here. Welcome, by the way
So I have no idea what you know or how to explain things to you. Let me try again and be more specific as to what you are changing
I did look at the database. The problem with me looking at the database is that although I can see what you are trying to do, I have no way of knowing what your business rules are and that is critical in most cases so me just fixing the code so it works isn't going to help you because I can't tell if you've thought through the business rules in detail. As I explained in my reply. If only the initial Estimator's Initials are relevant, then they belong ONLY in the main record. They do not need to be duplicated in the detail records if the values will always all be the same.
You have a combo box on the main form where the user picks his initials out of the list. I see now that the combo is unbound so there is no record kept in the mainform of who changed/added what. Think about the logic of that. If person A adds the main form and a few child records and we use your plan, the logic works if he has remembered to pick his initials and he didn't pick someone else's by accident or on purpose.
Now person B comes along and changes something. Does he change the Estimator Initials? Should that change the initials of the entries made by the other person or just on new records that he adds? What if you wanted to record his initials in the records he changed? How would you do that if he didn't change the SSOW field? The code would need to be in a different event. The subform's BeforeUpdate event would be the proper event.
The crux of the problem is a new "feature" that has recently appeared in Access. This "feature" used to exist only for reports. Now the disease has spread to forms also. The "feature" is that you need to bind a control to any column you want to reference in VBA. The control doesn't need to be visible and you can make it very tiny but it has to be on the subform. So if you add SEsIni to the subform, your problem should disappear.
Me.SEsIni = Me.Parent.Combo51
You did understand what I said about proper naming of controls, right?
So, adding the hidden control in the subform will "fix" the problem as long as you move the code to the subform's BeforeUpdate event so it will update changed records as well as new records. Keep in mind that there is no validation of any kind on either form. Therefore, there is no requirement for the user to choose his initials. There is no requirement in the subform to enter a value in SSOW. There is no validation in the subform to ensure that a parent record has been added before the user attempts to add a child record. The ProjIdxID is not defined as required on the tbl_SOW so it is possible to add orphan records, and the list goes on.
However, rather than relying on the user to remember to change the initials, it would be far better for you to automatically populate using UserID (if it is unique) or SecurityID based on information gathered from the log in.
In the vast majority of tables in my applications, I include three fields
CreateDT
UpdateDT
UpdateBy
The CreateDT is set to default to Now(). The other two fields are populated in each form's BeforeUpdate event as the last two lines of code in the procedure. I hide the log in form rather than closing it so I can refer to it throughout the application. It also allows me to run code when the application shuts down since the hidden login form will be the last form to close. This technique is by no means a change log. That is a different animal. This is just a simple way to identify when a record was last changed and who changed it.
Me.UpdateDT = Now()
Me.UpdateBy = Forms!frmLogin!txtUserID