Saves - Request_Save

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.

Example Scenarios

• 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. For example, if 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.

See Also

• Propagation of DDO Operations