Tracking deletions to a continuous subform can be tricky.

The Delete Confirmation event does NOT fire for subforms. Only the OnDelete Event.

This allows you to Cancel the event, but does not allow you to leave the subform to run any code affecting the parent form and once you have finished the Delete Event, there is nothing else that fires to let the form know that a record has been deleted and the record is not actually deleted until after the Delete Event ends.

When a user right clicks on a record selector and chooses cut (which they can do with multiple records) was the situation I was trying to deal with and I was using a logging object to write updates to a log subform located on the parent form.

I added lots of code and pretty much got it working, but due to the difficulty of the solution, I ended up setting a flag to tell the Current event when it next fired that it had to do some cleanup actions due to the line now being gone.

Even after all this I was fighting little bugs with the process and timing issues causing various weird Access runtime error messages.

In the end, I gave up this approach, removed the ability for the user to delete anything using the subform / continuous form interface and replaced it with a command button I created for the purpose. I was then only every working with a single record at a time and could just undo any changes the user had made, delete the record using CurrentDb.Execute and Requery the subform. Whew. This made it much simpler to figure out which other lines have already been deleted (you weren’t supposed to delete the final valid line in this scenario). Whew! So when dealing with subform delete events, I recommend forcing the situation yourself using a command button. This will give you full control over the process, when the record actually gets deleted, and any cleanup tasks you may need to do with the rest of the form after deleting the record.