A B C
\ / /
D E
\ /
F
/ \
G H
When a DDO receives a Request_Save message, it will attempt to save a record for its main table.
Saves propagate up.
This means that a save can affect the main table of its DDO and all of the DDOs above it in the updating chain.
For example:
If Request_Save is sent to Object A_DD, a record in table A will be saved.
If Request_Save is sent to Object D_DD, Tables D, A, and B will be saved.
If Request_Save is sent to Object F_DD, Tables F, D, E, A, B, and C will be saved.
What tables would be saved if Request_Save is sent to H_DD? If you answered all tables except G, you would be correct. This implies that you must have your parent-table DDOs properly connected if a Data Dictionary save is to be properly processed.
When saving via a DEO, it makes absolutely no difference what File.Field is defined by the Entry_Item command. The record that gets saved is determined by the DEO’s server DDO. If, for example, users press F2 when they are in a vendor field in a dbForm that is connected to a checks DDO, a checks record will get saved. This may also save its parent vendor record (assuming the Data Dictionary structure is correct). In this case, the Vendor dbForm would be treated as a Foreign-Field DEO.
Object oVendor_Name is a dbForm
// Because the DDO_Server is Checks, a save from here will
// save a checks record, even though the file.field value
// being displayed is Vendor which is presumably a parent
// of Checks.
Entry_Item Vendor.Name
Set DDO_Server to oChecks_DD
End_Object
If the dbForm were connected to a vendor DDO, the save would save the vendor record and not the checks record.
Object oVendor_Name is a dbForm
// Because the DDO_Server is Vendor, a save from here will
// save a vendor record.
Entry_Item Vendor.Name
Set DDO_Server to oVendor_DD
End_Object
Relates-to constraints have absolutely no effect on the save process.