I will stand with KitaYama that - as KY clearly stated - some things are possible even when done the wrong way. But I will also stand with the others who point out that doing things the wrong way is a path fraught with peril leading to disasters. You CAN do things the wrong way. Murphy's Law DOES DEFINITELY apply to programming. And with some ingenuity, you might even make it seem like it is working. But doing things the wrong way often come back to bite you, which is why we advise against doing anything the wrong way. Some of us will tell people "Don't Do That" with such authority that we seem to be denigrating their abilities. That happens because we don't always have the time or energy to fully explain WHY their suggested method isn't going to work.
Among other things, the timing becomes tricky if you work backwards since Access will do things behind the scenes each time you do an EXIT SUB from an event routine. Approaching from the wrong direction, you will surely end up doing more work than you might wish to do. I.e. you add extra steps which, in software engineering terms, means you add extra points of failure, thus increasing your overall risk of failure. You negate the benefits of actions that Access would normally do for you silently behind the scenes. You run the risk of breaking or mis-directing the relationships. The last two factors are actually a lot more critical than the others, since you are dealing with a relational database and are bypassing the database's built-in management of relationships.
@AHMEDRASHED - as you have seen from all this controversy in your thread, the consensus is that doing it the way you originally suggested is a choice we would not advise. You do better to rethink your process in a way that lets Access work with you, not against you. But it isn't actually Access that is causing any issues. It is the inherent nature and the requirements of relational databases in general. Access isn't the only database tool that imposes limits on how you approach relationships.
