The Data Dictionary Inspector (DD_Debug.dg for Windows projects and WebDD_Debug.wo for Web projects) is a small package utility that can be used to aid in the debugging of Data Dictionaries. It was created to make it easier to inspect and change the state of any Data Dictionary object (DDO) and to test the efficiency of your find constraints.
To add the Web Data Dictionary Inspector to a Web Application:
Load your web application (WebApp.Src)
Adding the following line inside of your oWebApp object
Use WebDD_Debug.wo
Object oWebApp is a cWebApp
:
Use SessionManager.wo
Use WebResourceManager.wo
Use LoginDialog.wo
Use Order.wo
Use Customer.wo
Use Inventory.wo
Use Vendor.wo
Use SalesPerson.wo
Use WebDD_Debug.wo
:
End_Object
Compile your program
Run your program
The DataDictionary Inspector can be added a windows-application test component or application. To do this:
Load your component or program
Adding the following line to the top of your source file, right below all other Use statements
Use DD_Debug.dg
Compile your program or test component
Run your program
Once loaded this utility can be invoked from within any view by pressing the CTRL+D key.
You can select and view information from any DDO within the current DDO structure. This is done by selecting a DDO from the “Current DD” combo-form, which contains a list of all DDs within the structure.
Each DD’s Current_Record, Changed_State and Should_Save condition is displayed.
Current_Record shows which record is current (this is the record that will be saved or deleted). Note that this record is not always the same record that appears in your record buffer.
Changed_State tells you if the current DDO has data that has been changed directly within the DDO.
Should_Save looks at the DDO and its parent DDOs and indicates if there is any change anywhere within the structure.
For each Field you can see if data is changed, if the data is valid (as a regular and as a foreign field), and each field’s current data value.
An additional “Misc” page provides more information about a DDO such as required and attached Server and Client DDOs, attached DEOs, and other DDO properties.
There are a number of properties you can change within a DDO that will alter the way your application runs. This allows you to test out different property settings during development.
You can change the following:
You can dynamically change the Relates-to constraint settings within a DDO structure by selecting a table in the “Related To File” combo-form. This allows you to create and remove parent-child constraints in your structure. This changes the Constrain_File property.
You can set the Auto-Fill checkbox to see how this changes relates-to record finding. This changes the Auto_Fill_State property.
You can set the First-Rec Auto-Fill checkbox to determine if an auto-fill should fill from the first or last valid record. This changes the pbAutoFillFromFirst property.
You can set the Inherit Constraints checkbox that determines if a DDO should inherit constraints defined in parent DDOs. This changes the pbInheritConstraints property.
You can select the Ordering (index) to be used for any find. If the value is Best (-1), the DDO uses what index is requested for a find. When a specific number is selected, that index is always used for all finds. This changes the Ordering property. This can be useful in determining what indexes should be used for a specific constrained find operation.
Note that changing these settings will actually change the way your component being tested operates.
You can find records by entering a record number and pressing the "Find" button. This is used to find a particular record and all parents.
You find perform Next/Previous finds by any index by pressing one of the VCR style Find Buttons. This is most useful when you wish to test constrained record finding.
You can find out if your record finding is optimized or not. This is a very important feature. When records are found a counter is maintained that keeps track of how many records are read and how many of those records are valid. The closer these values are to each other, the better your find optimization. Here is a useful technique:
Press the “Clear Count” button.
Close the panel, run your application and find a few records.
Now re-invoke (ctrl+d) the Data Dictionary Inspector. Look at the Tests_Count and Found_Count values. You may be in for a surprise! If the values are very different, you may need to better optimize your find constraints.
The Data Dictionary Inspector presents this information by using two runtime global integers Constrain_Tests_Count and Constrain_Found_Count.
The Inspector provides an additional way to test for non-optimized finds by providing error messages when filtered records exceeds a threshold. Whenever a constrained find occurs, the DDO may need to find and test many records before it finds a valid record. Often this type of filtering is to be expected. However, at times you may have created a very inefficient filter that is going to create performance problems when deployed.
If you wish to enabled error reporting for inefficient constrained finds you need to check the “Report errors if more than N records are filtered” checkbox and setting an appropriate value for “N”. Every DDO find will now be tested. For any single find, if the number of records tested exceeds the limit you defined an error will be raised. This test occurs even if the Data Dictionary Inspector is not invoked allowing you to set your threshold and run your program. If too many records are being filtered, you will get a warning.
By default the Data Dictionary Inspector reports DDO reentrancy problems. Many DDO methods are not reentrant. The messages that are not reentrant are Clear, Clear_All, Request_Save, Request_Delete, Request_Assign, Request_Find, Request_Superfind, Find, FindByRowId, and Find_By_Recnum. For example, you cannot send the Find message in the middle of a Request_Save process (even if the message is being sent to another DDO).
When these types messages are sent in a reentrant state, the normal behavior of the DDO is to ignore them. This creates a problem for testing. If you are sending these messages, you are probably doing so in error. Rather than performing whatever action you are expecting, the message is being silently ignored.
When the Data Dictionary Inspector is used, these re-entrant messages are reported back to you as errors. This will make it easy for you to find and correct these problems. If during any DDO operation a reentrant operation is encountered, an error will be presented containing all of the required debug information.
To disable this error check, un-check the “Report DD Reentrancy Errors".
DDOs can provide information about their DataFlex constraints. These are the constraints that are built up in the OnConstrain event using the Constrain command. You can query information about all of the constraints for a DDO and you can query information about how the constraint engine uses these for a find by a particular index. Much of this information is technical and would only be used in advanced programming situations. It can also be used when debugging constraints.
Constraints are built when Rebuild_Constraints is sent to a DDO. The DDO calls OnConstrain, which executes all of the Constrain commands. Each constraint is added to an array of constraints. If the DDO inherits constraints from its parent DDOs (determined by pbInheritConstraints), it will send OnConstrain to the parents and continue to add these parent constraints to the original DDO's array of constraints. Upon completion, this array of constraints, which consists of this DDs constraints and possibly parent DD constraints is what, is used to filter all finds for this DDO.
If you are using an SQL back end database, you can add an SQL DD filter while debugging.
The DataDictionary Inspector cannot be used with Web Application components (it’s a Windows based application component).
Remember to remove the "use DD_Debug.dg" from your program when you are done testing it. If you leave it in place, your users might accidentally find it.
Note that this is a standard Studio dialog component. If you place DD_Debug.dg within a Workspace’s AppSrc area and register within the Studio you can load it, study it and edit it as a Studio dialog component.
If your application is already using the Ctrl+D key you will have to create an alternate On_Key command definition that sends the message “DebugDDs”. For example, to move this to Ctrl+F12 you would add this line of code to your application:
On_Key Key_Ctrl+Key_F12 Send DebugDDs