DataDictionary

A data dictionary is defined as the business layer in-bewteen your table on disk, and the requested operation at runtime. It handles the find, clear, save, validate, and delete requests from either the programmer or the user. A data dictionary exists both as a class coded definition and as an instantiated object which uses full delegation and polymorphism in the form of a data dictionary object in a "tree" structure for the data set you wish to perform an operation on.

Editing a DataDictionary CLASS in Visual DataFlex involves at least 10 identifiable options:

-1. Create/edit/delete data table columns.
-2. Set parent relationships.
-3. Define indexes for finding data by.
-4. Set column based options for when the data table is used as the main data entry source. This involves setting system-wide standard behavior such as "capslock", "required", and "auto-find". An option also exists to set columns as "key fields" where the user may not change the value at runtime.
-5. Set column based options for when the data table is used as a "server" [parent] of the main data entry source. Options here include "find required" and "noput" [user changes cannot overwrite the data table column]. It should be noted that depending on which place in the data operation structure (parent, child or main file... a data dictionary exists, the place determines which business rules apply in a display of polymorphism which is defined as the ability to produce different behavior simply by the context of it's use.
-6. Define the immediate relational tree for the delete operation based on a record delete in the table. The child tables are defined so that two basic rules apply (one or the other): either the record cannot be deleted if child records exist, or the child files will all be deleted when the record is called for delete AND a data dictionary object in the module must be present to handle the delete operation. This is as much a validation for the programmer as it is for the user, since operations cannot be successful unless both follow the rules programmed in the class. It should be noted that business rule exceptions and customized rules can augment this programming or replace it completely. It should also be noted that when data dictionary objects are connected together in a module, that deletes travel downwards in the tree, and upon each delete, a save and validation is sent upwards in the tree.
-7. Define the immediate relationsl tree for the save operations based on a requested save of the data table record. The parent data tables are defined so that your programming team must always place a parent DDO (data dictionary object - instantiated on the classes we are building) for each parent data table that is connected relationally. Omissions and "sometimes required" parent tables can be defined in both the class code and object code programmaticallty. The advantage of making a parent table "required" is to be able to both code update/backout operations to another table (knowing that it must always be present to handle your code), and also for the Visual DataFlex Studio to automatically model your relational tree when you request a data server to handle your find, clear, save, validation, and delete operations.
-8. Define the externally updated tables to be bound in the transaction block of saves/deletes. When a save or delete occurs, all table attributes are set to readonly momentarily, the tables that will be affected by the operation are set to default mode, and then a reread/transaction block occurs to lock all the tables in the tree that are affected PLUS the ones listed in externally updated tables. This allows, for instance, a reread and update from the system table to assign the next available number to a key field.
-9. Programming of stored procedures that exist as called methods already. REF: DDO Save Cascade:[1]
10. Programming of customized stored procedure methods that you introduce to the class, stored in a central depository (the foundation of oops programming) class and can be attached to either the exiting of a control attached to a column of the data table, or the exiting, or simply the validation of such column.

All together, these 10 functional abilities to centrally define data table rules are dwarfed by the fact that they are "hitched up in tandem" like a team of "Budweiser Clydesdales" which work interconnectedly to enforce your entire data structure on any data operation which includes save, clear, find, delete, and validation.