The relates-to constraint is used constrain child records to a record in a parent table. Relates-to constraints change the way DDOs interact with each other. When a relate-to constraint exists, the DDO find and clear behaviors will change to operate properly within in a constrained parent-child environment. This requires that:
When constrained child record is found, only records that are related to the parent will be allowed.
When a constraining parent changes via a Find or Clear its record, the constrained child DDO, will be notified of the change. That child must make adhere to the constraint by either making sure that the child is within the constraint or it is cleared.
These two rules require that the propagation rules for clear and find change when a relates-to constraints is in place.
The next two samples will show the same DDO structure except that one will not have a relates-to constraints and the other will.
We have a Data Dictionary structure with no relates-to constraints as shown in the diagram. Our DEOs could connect to any of these objects. For example, if our DEO were using DDO D, all of the DEO’s data-file requests (save, clear, delete, find) will be handled by DDO D.
A B C
\ / /
D E
\ /
F
What will happen if Clear_All is sent to any of the DDOs?
All DDOs will be cleared.
What will happen if Clear is sent to A?
A is cleared.
What happens if Clear is sent to D?
D, A and B are cleared.
What happens if Clear is sent to F?
F, D, A, B, E and C are cleared.
What will happen if Request_Save is sent to A?
A is saved.
What happens if Request_Save is sent to D?
D, A and B are saved.
What happens if Request_Save is sent to F?
F, D, A, B, E and C are saved.
What will happen if Request_Delete is sent to A?
A is deleted.
A's children in D are deleted.
D's children in F are deleted.
B, E and C are updated.
What will happen if Request_Delete is sent to D?
D is deleted.
D's children in F are deleted.
A, B, E and C are updated.
What will happen if Request_Delete is sent to F?
F is deleted.
A, B, C, D, and E are updated.
What happens if a Find for table A is sent to A?
A is found.
What happens if Find for table D is sent to D?
D is found and related.
A and B are notified of the new related records.
What happens if Find for table F is sent to F?
F is found and related.
A, B, C, D and E are notified of the new related records.
We will give our Data Dictionary structure the following values:
A B C A = Customer
\ / / B = Terms
D E C = Vendor
c\ / D = Order Header
F E = Inventory
F = Order Detail
F has a relates-to constraint to D (set Constrain_File to D.File_Number).
DEO_Header_Entry uses D as its DDO server (set server to D).
DEO_Table_Entry uses F as its DDO server (set server to F).
We now have a standard order-file structure. We will hook two types of DEOs to this structure: a set of order-header-entry DEOs using D as its server and an order-detail grid using F as its server. This means that users will only be sending Data Dictionary requests to DDOs D and F. Without a relates to constraint between F and D, the data-entry behaviors will not be appropriate for our entry-form/grid setup. The save and delete behaviors are fine; the clear and find behaviors are not.
We must add a relates-to constraint in DDO F which will constrain F records at any given moment to only those relating to the current record of its Parent table D. Constraints have no impact on saving or deleting (which is good). They do change the clear and find behaviors (which is also good).
What happens if Clear is sent to D?
D, A, and B are cleared.
D will notify its constrained child, F, that it has a new blank record.
F will attempt to find a record that is related to the blank child. Hopefully it will fail, clearing F, E, and C.
The net result is that all tables are cleared.
What happens if Clear is sent to F?
F, E and C are cleared.
When F attempts to clear DDO D, it will “bump” into the relates-to constraint and halt the clear up that tree branch.
What happens if a Find for table A is sent to D or F?
A is found, nothing else is changed.
What happens if Find for table D is sent to D?
D is found and related.
A and B are notified of the new related records. In addition, D will notify its constrained child table F about the new parent record.
F will find the first (or last) valid record and tell the grid object about the record.
The grid object will fill in the grid with valid records.
Tables E and C are related and their DDOs are notified of the change. Therefore, when D is changed, the child grid record will change as well. This is good.
What happens if Find for table F is sent to F?
F is found only if F is a valid child for D. Therefore D, A, and B cannot change.
Tables E and C are related and their DDOs are notified of the change.
The header object will contain the fields allowing us to find the customer records (A). We did not choose to constrain the order header table to the customer table. For finding purposes, we do not want our search of orders to be limited to a single Customer. We did not create a separate DEO for the Customer fields. If we had done this (and that DEO was using the Customer DDO), we would have gotten undesired save and delete behaviors. Save would have only saved the Customer table. Deletes would have deleted the customer record and all of its children.