Request_Save - BaseData_Set

Saves all changes in DEOs attached to this object or to any DDO that is a server of this object directly or indirectly

Syntax

Procedure Request_Save

Call Example

Send Request_Save

Description

A DataDictionary object (DDO) save is normally a two-step process. First you send Request_Validate to the DDO to make sure that your data is ready for the save. If your data is valid, you then send Request_Save to the DDO to perform the save.

In some cases, you will use objects such as data-entry object (DEOs) to handle the entire save for you. In other cases, you will need to write custom code to perform the save. In all cases, the save process itself is the same.

If you are sending Request_Save in a normal view with visible DEOs (e.g. not a BusinessProcess Object), you may also want to consider sending Request_Save to a DEO with a Server property set. This will ensure that DEO-based augmentations and verifications occur and Request_Save is then sent on to the Server DDO to perform the save.

When the save operation is performed by a DDO, it saves records into its main table as well as the tables in its parent DDOs. This allows updates in total fields in related tables to be performed as each record in the main table is created or edited. This action can also cause the creation of new records in any of the tables. Any record buffer that was not pointing to an already-existing record will have a new record created.

Function SaveCustomer returns Boolean
    Boolean bErr

    Get Request_Validate of oCustomer_DD to bErr
    If Not bErr Begin
       Send Request_Save of oCustomer_DD
       Move (Err) to bErr
    End

    Function_Return bErr
End_Function

Request_Save will return the handled error 4527 - DFERR_CANT_REFIND_RECORD when records cannot be refound/reread. The intent is to notify the user that someone must have deleted this record since it was last found by the user and that this is not a bug, but normal multi-user behavior when one user deleted a record that another user has pulled up in a view, etc.

The Request_Save message is responsible for saving new or existing records. When Request_Save is sent to a DDO, it will: Verify that the DDO structure is valid for the save operation.Begin Transaction - From this point on tables are locked (if the database uses table locking) or records are locked as they are found (if the database uses record locking).Re-find all original records. Send Backout to all tables with existing records.If any parent records are switched (i.e., you selected a different parent), save the original records (with backed out data) and re-find the new records.Move all changed data from the DDO-Field buffers to the table file-buffers.Send Creating to all DDOs with new records.Send Update to all participating DDOs.Get Validate_Save of all participating DDOs. If any Validate_Save fails, cancel the operation.If all DDOs validate, attach, and save all records by sending Attach_Main_File and Save_Main_File to every table.End Transaction - either commit changes or roll back changes. Unlock tables.If save was successful, send Refresh all participating DEOs. Request_Save is not re-entrant. Once a major Data-Dictionary operation (save, find, delete, clear) has begun you cannot start another major operation. The reentrancy restriction applies within DDO structures and across DDO structures.