Property Boolean pbUseDDRelates
|Read Access:||Get pbUseDDRelates to BooleanVariable|
|Write Access:||Set pbUseDDRelates to BooleanVariable/Value|
Determines if local DD (DataDictionary) relates or global table relates should be used. If False (the default), it will work using global table relates.
If True, it will use the relationship data set via Set Field_Related_FileField.
Relates can either be defined by a table or by the DD. pbUseDDRelates determines if relates are defined by the table (False) or the DD (True). By default, this is False, so relates are controlled by the table.
The False setting is the recommended value for most DD classes. You should only consider setting this to True if you have special requirements that cannot be handled by the normal global relationships.
If pbUseDDRelates is set True, then relationships defined by the table are ignored and you must set your own relationships within the DD class or object. If you do not set these, there will be no defined relationships. This is done with the Set Field_Related_FileField message.
pbUseDDRelate affects a single DDO structure (usually one DDO structure is set per view (dbView) or dialog (dbModalPanel) or web view (cWebView).
A DD relationship is only respected by DD operations - in particular, the Find operations (Request_Find, Request_Read, etc.). Any finds that are performed outside of the DD (e.g., a find/relate performed with the Find and Relate command) are global commands and therefore they use the table relationships and not the DD relationships.
A common use of local DD relates is to use an existing view that uses DataDictionary classes that are used with all existing local relationships and cancel just one or more specific relationships in a single view.
This involves multiple steps:
1. Set pbUseDDRelates to True -- this cancels all existing relationships from the current DDO
2. For each parent to unrelate, remove DDO_Server statements -- these establish another DDO object as a parent DDO and should be removed if the relationship is removed
3. For each parent to unrelate, remove the parent table from the server-table list by sending Remove_Server_File -- these establish another DDO object as a parent DDO and should be removed if the relationship is removed
4. For each parent table relationship you want to keep, manually re-establish the relationship using Set Field_Related_FileField
This sample code, if used in the Order.vw in the order sample workspace, turns on local relationships for the Order Header DDO, which then allows us to disable the relationships from Order Header to Customer and Sales Person.
Object OrderHea_DD is a OrderHea_DataDictionary Set DDO_Server to Customer_DD // remove this line to remove SalesP_DD as a parent DDO of OrderHea_DD // Set DDO_Server to SalesP_DD // define local relationships Set pbUseDDRelates to True // send this to cancel SalesP_DD as a required server as established in Salesp_DataDictionary superclass // by Set Add_Client_File to Orderhea.File_Number Send Remove_Server_File SalesP.File_Number // Setting pbUseDDRelates to True cancelled ALL relationships from OrderHea to parent tables // meaning that it cancelled the relationship to both SalesP and Customer // In this example, we only want to cancel the relationship to SalesP, // so we need to manually re-establish the relationship to Customer Set Field_Related_FileField Field OrderHea.Customer_Number to File_Field Customer.Customer_Number End_Object
At runtime, you are either using DD relationships or table relationships and this is controlled by the interface that you use and by pbUseDDRelates. You cannot mix these in a single DD class or object. For example, there is no automatic way to copy all of the table relationships to the DD at runtime. If you are managing your relates within the DD, you must manage them all yourself (which is actually good, because it gives you complete control over your environment).
You can, however, mix these in a DDO structure, where one DD in a structure uses local relationships and others use global table relationships. For example, in the Order view, you could turn on local relationships for just the Invt_DD object and still use global relationships for the other DDOs in that view.
So, you could disable existing relationships for a single DDO in a view, by setting pbUseDDRelates to True and cancelling relationships using Field_Related_FileField, yet leaving relationships for all other DDOs in the view to use global table relationships.
You can also use this for alias tables. If you have a child table which you want to relate to an alias of a parent table (in an accessory view, for example), in many cases you need to cancel any relationships of the alias parent. Since, in embedded database tables, table relationships are stored in the physical table header, alias tables have all the same relationships as their master tables. You can now cancel these in alias DD classes by setting pbUseDDRelates to True. Then, you may or may not establish new grandparent relationships.
Class cSpecialOrderDetailDataDictionary is a OrderDtl_DataDictionary Procedure Construct_Object Forward Send Construct_Object Set Alias_File to SpecialOrderDetail.File_Number Set pbForeignReadOnly to True // this cancels all relationships for the alias table that are brought in from the master table Set pbUseDDRelates to True Set pbNoCascadeDeleteStrict to True End_Procedure
The Get/Set Field_RelatedXxxx messages only apply to the local DD relationships. It does not matter what the value of pbUseDDRelates is, these message work the same and they only work with DDO relationships. If pbUseDDRelates is False, you inquire about relates using the API interface; if True, you use the DD interface.
Setting pbUseDDRelates to True means that you are assuming all responsibility for code regarding relationships in that DDO. This includes removing any code that was placed there by the Studio (e.g. via wizards or DDO Explorer) when it assumed you are using table relationships rather than local ones.
pbNoCascadeDeleteStrict | pbForeignReadOnly