Rick should update the template if it's still downloading erroring, did adding the line of code not fix it for you though?

No, it's crashing in multiple procedures for a new customer.
I assume it will have the same problem when adding new in all the other tables.

In the procedures that generate the error check the ID field for Null.

If IsNull(CustomerID) Then Exit Sub

I'm not sure if that's what's needed for new records.
Once the ID is known, should new records show as locked too?
This is somewhat tied to the problem of Access (stupidly I think) assigning an ID before a new record is actually updated.

Why would new records need to be locked? They haven't been saved to the table yet so there is no possibility of someone else editing them.

So a query doesn't start running until after the record is saved?
Isn't that part of all this?

Walk me thru step by step what's happening.

Richard when you use navigation bar to go to new record and try to type, just needs to check if it's a new record exit sub

You have to do it in at least two places for each form in the template.
The timer code get's an error too.
Then you have to think well, how do I want to handle new records and locking?
If we are stopping queries from running, then we need to do it here too for all the same reasons we're doing it in already exiting records.
Then there's the opposite of locking records. Maybe if we are about to run an update query, we want to set-record locking so that no updates can happen in forms at the same time? So, we aren't locking one record, rather the whole table(s) that then forms can see as every record is locked.

There's no reason you would need to lock a record that is new, nobody else would even be able to access that record until it had been saved. Likewise there would be no effect on queries during the "New record" state. You could try to dlookup it even but if it doesn't exist as a saved record in the table, it won't find it. Likewise if you try to run an update query that includes it, it wouldn't do anything to that record until it had been saved at least once to write the record.

@ Adam, there are situations where I think you wouldn't want the new record to write to the table while an update query supposedly has the table locked. Once we get the problem with null IDs fixed, then we can test if the new record is prohibited from going dirty like the existing records.