DataDictionary

Definition

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 Data Dictionary

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
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.

How to use Data Dictionaries

The Database Builder tool helps you defining the class with visual aid for:

• Field settings like Capslock
• Table settings like calculations on save or save/delete validations
• Relationship settings like Cascade Delete.

The Datadictionary class can also contain and business rules required when records are created, edited or deleted.

How to create a new Data Dictionary from scratch

1. Open Database Builder.
2. Create a new table
3. Enter some columns (input name, type and width)
4. Choose Maintenance and Create Empty DataDictionary.

How to create Relationships

Before creating relationships, make sure that both tables should have an index.

• use 'the relationship wizard' in the database builder.

Use Data Dictionaries in Batch Processes

When using the studio, the usage of Data Dictionaries are very naturally integrated into your project. But when doing a save without dbForm objects eg in a batch process or so, a lot of developers are going back to the file buffer way. This way it bypasses the class structure you carefully put in place for saves, deletes, updates etc. Please check Using Data Dictionaries in Business Processes for help and sample code.

Supported backends

It is possible to reach several databases through the Data Access DataFlex Connectivity Kit or using third party drivers from Mertech Data [1]

• Native DataFlex database
• Oracle [2]
• Microsoft SQL Server [3]
• Pervasive SQL [4]
• ODBC
• MySQL
• IBM DB2