A critical part of the DataFlex Framework is the understanding of how Data Dictionary objects are used to access and maintain data. This section describes how the structuring and connection Data Dictionary object controls behavior. You can do everything that is discussed in this topic visually within the DataFlex Studio via the DDO Structure Editor. While the Studio will do much of this work for you, it is essential that you understand how it all works.
A Windows Application program usually contains many data-entry objects (DEOs). Some of these objects should act in a coordinated fashion with other objects. When a found record is displayed in one object, that record should be displayed in some other objects as well. Other DEOs should be independent. Changes made in one such DEO should not affect any other. The DDO is the object that coordinates activities among DEOs. All DEOs that are connected to the same DDO will act in a coordinated fashion.
DDOs also need to act in a coordinated manner with other DDOs. We accomplish this by connecting the DDOs. An interconnected group of DDOs is referred to as a Data Dictionary Object structure. Each DDO in a structure might have one or more DEOs connected to it. All of these DEOs will be coordinated. A save, delete, find, or clear operation in a DDO will affect all DEOs connected to the Data Dictionary structure in a coordinated and hopefully intelligent manner.
This leads us to the most-important rule of DDOs:
A DDO provides coordinated database services to every data-entry object that uses it, and to every other DDO in its Data Dictionary structure.
The above statement holds the secret to life in a DDO universe. If you want a DEO to act in coordination with another DEO, you should make sure that both DEOs use the same Data Dictionary structure. Just as important, if you do not want a DEO to act in coordination with another DEO, make sure that they are not using the same Data Dictionary structure.
A dbView is an object that contains a Data Dictionary structure together with all of the DEOs that use this structure. All of these DEOs will act in a coordinated fashion. This coordination does not come about as a result of the fact that these objects all reside in the same dbView. The coordination occurs if, and only if, the Data Dictionary structure is properly interconnected and each DEO is connected to the proper DDO. The dbView object simply hides this complexity from the outside world.
DDOs are also used outside of DEOs. For example, a BusinessProcess object may contain a DDO structure used to perform a batch update. When used in this mode, the DDOs structures are built the same way they are with DEO views. The difference will be in how the DDOs are used. Instead of having DEOs using the DDOs as their servers, methods will be created and code will be written to find, process and update data in your DDOs.
Set DDO_Server to oCustomer_DD
DDOs are connected within a DDO structure together with the DDO_Server message. This property, which is set in Child-Table DDOs, connects a Child-DDO to a Parent-DDO. If the child has multiple parents, it will send this message for each parent DDO. This property is set only for immediate parent DDOs. Ancestor DDOs, such as Grandparent-DDOs, should be set by their immediate child (i.e., the parent DDO sets DDO_Server of the grandparent DDO).
Object oCustomer_DD is a Customer_DataDictionary
End_Object
Object oSalesP_DD is a SalesP_DataDictionary
End_Object
Object oOrderHea_DD is a OrderHea_DataDictionary
Set DDO_Server to oCustomer_DD
Set DDO_Server to oSalesP_DD
End_Object
Object oOrderDtl_DD is a OrderDtl_DataDictionary
Set DDO_Server to oOrderHea_DD
End_Object
parent relationships you create in your Database Dictionary class using Add_Server_File and Add_Client_File. We will use the following table structure as an example:
A B C
\ / /
D E
\ /
F
/ \
G H
In this diagram, parent tables are above and child tables are below. Tables G and H relate to table F. table F relates to both tables D and E. Table D relates to A and B. Table E relates to table C. Tables A, B, and C have no parents.
Creating a Data Dictionary structure for these tables is quite simple.
Create the parent DDOs first.
Start at the top and work your way across from left to right.
All connections will be handled with a set DDO_Server updating link.
The following shows how this table diagram is rendered as a Data Dictionary structure. The first step was to create a Data Dictionary subclass for each table. These classes contain all the database rules needed for these tables.
Object A_DD is a A_DataDictionary
End_Object
Object B_DD is a B_DataDictionary
End_Object
Object C_DD is a C_DataDictionary
End_Object
Object D_DD is a D_DataDictionary
Set DDO_Server to A_DD
Set DDO_Server to B_DD
End_Object
Object E_DD is a E_DataDictionary
Set DDO_Server to C_DD
End_Object
Object F_DD is a F_DataDictionary
Set DDO_Server to D_DD
Set DDO_Server to E_DD
End_Object
Object G_DD is a G_DataDictionary
Set DDO_Server to F_DD
End_Object
Object H_DD is a H_DataDictionary
Set DDO_Server to F_DD
End_Object
Once your Data Dictionary structure is created, your DEOs must be connected to the proper DDOs. The server property of DEOs is used for this. In order to know where in a Data Dictionary structure a DEO should be connected, you must understand how DDOs and DEOs interact.
When a DEO is connected to a DDO, the DDO is referred to as the DEO's server. A DEO cannot perform any database activities itself. Instead, it will send a message to its server to perform the function. A DEO will ask a DDO to save, delete, clear, or find a record. When a DDO performs one of these operations, it will interact as needed with all other DDOs in its structure. These DDOs will interact in turn with all DEOs that are connected to them. A DDO sends two messages to a DEO. It will either ask the DEO to move data from the object to the table’s file-buffer (Entry_Update), or it will ask the DEO to move data from the file-buffer to the object (Refresh).
Creating Data Dictionary Object Structures