Skip to content

Save and Deletion Protection

Read Only State

Set Read_Only_State to True

Read_Only_State is used to specify that the Data Dictionary cannot be directly used to save or delete records. This means that the messages Request_Save and Request_Delete sent to this DDO will generate an error and not perform an update.

Note that records in a read-only Data Dictionary can be indirectly changed by a save or delete sent to another Data Dictionary within the object structure. For example, if the parent Customer DDO is set to read-only and the main Order Header DDO is not set to read-only, then saves and deletes in the Order Header DDO will be allowed to change this Customer data. This is required to maintain database integrity. If you want an entire DDO structure to be read-only, you should set all DDOs in the structure to read-only.

Read_Only_State is more likely to be set in a Data Dictionary object and not the class.

No Delete State

Set No_Delete_State to True

No_Delete_State disables direct deletes of records. This means that the message Request_Delete sent to this DDO will generate an error and not perform any action.

This message does not affect deletions of records that are part of a cascade delete.

Cascade Delete State

Set Cascade_Delete_State to True

Cascade_Delete_State specifies how a delete should be affected by the existence of child-file records that relate to the record being deleted.

  • If Cascade_Delete_State is true, then the child records and all descendant records will be deleted.
  • If the property is false, the delete will only be allowed if no child records exist.

Both methods ensure that child-file records will never become orphan records.

Validate Foreign File State

Set Validate_Foreign_File_State to False

Before a save occurs, you will want to validate all fields by sending the Request_Validate message to the DDO performing the save. Normally, all fields in all tables that participate in a save will be validated. This includes fields that have no visual representation in the current view and all fields in all ancestor tables. In almost all cases, this level of data protection is desired and is a powerful feature of the data dictionary. In rare cases, you may wish to select lower levels of validation protection.

The property Validate_Foreign_File_State determines if field validation should be applied to foreign (parent) tables. Normally, you want this level of validation, so its default value is true. Setting its value to false will skip field validation when the table is used as a parent table in your DDO structure. It will also suppress validation in all additional ancestor tables.

Setting this property away from its default essentially defeats full field validation and potentially compromises data integrity. It should only be used under carefully controlled circumstances.

Do not use this property as a shortcut solution to bad database design. Special conditional validation rules can be programmed directly into your validation routines. For example, you could build a validation routine that only applies field validation to new records (check the record’s status with the HasRecord property) or create validation routines that selectively skip certain fields when they are foreign (the Operation_Origin global integer tells you which DDO started the save). Rather than breaking a rule, attempt to define this rule change as part of your rule set. In the end, you will have a better, more robust application.

See Also