Hi Frank,
Based on your original attachment (equip service.zip), I am assuming that you will have one piece of equipment and it will need servicing many times..
IF this assumption is correct, then there is a one-to-many relationship between tblequip and tblservice and the following needs to be corrected:
1. in the 'database tables', the relationship is removed from the 'one' table (tblequip) and added to the 'many' table (tblservice).
2. the relationship needs to be flagged for 'cascade delete'
3. on form frmequip, you should not have combobox cboservice - this would only ever allow you to have one service record rather than many service records.
4. on frmservice, you need a combox to select the piece of equipment that the service is to be carried out on.
Just because you have specified a relationship in the 'database tables' schema doesn't mean that it simply happens - the program doesn't know which specific piece of equipment in tblequip and which service record in tblservice you want to link - the program needs to be told.
Now, when you do things the 'standard' MVD way, you would start with a tablegrid that lists your equipment. That would then call a form where you can maintain the equipment details and also shows a tablegrid listing the service records for that piece of equipment. That in turn would call a form where you can maintain the service details. And when you follow this 'standard' way, then all of the keys that link a specific record in tblequip and specific records in tblservice are automatically being picked up by MVD and maintained for you.
However, in your project, you are not following this 'standard' approach (which is absolutely fine) but you need to understand that you therefore have to do more of the work yourself (hence the need for the combobox on 'frmservice' to select a piece of equipment - you are manually telling your program which specific record in tblequip links to the record in tblservice you are working on ).
If you follow all of the above, then 'cascade / delete' works as it's designed to.
In the attachment is your original project, your original project fixed and also an option for how you could approach it but it's just a suggestion (and probably not the way I would actually do it, but then I don't know the business logic nor the volumetrics behind your project).
But no matter how you present the information to your users, if the underlying data structure is incorrect, it's never going to work.
Regards,
Derek.
Post's attachments fc.zip 1014.4 kb, 179 downloads since 2021-08-09