View source for Using Data Dictionaries in Business Processes

==Why not direct file buffer access==
In many cases, direct file buffer access would be simpler. But, it goes around your carefully constucted validation rules etc. Surely you can duplicate these rules, but the whole idea of a Data Dictionary class is that the behaviour is inherited to all objects that initiate a record manipulation.

==Saving new records==
===Simple Example===
The simplest example is where we save new records in a table that does not have a parent file. 
<pre>
  Function CreateCustomer String sName String sEmail
      Handle hServer
      Boolean bNotOk
      Integer iError
      Move (Customer_DD) To hServer
      Send Clear of hServer
      Set Field_Changed_Value Of hServer FIELD Customer.Name To sName
      Set Field_Changed_Value Of hServer FIELD Customer.EMail_Address To sEmail
      Get Request_Validate of hoServer to bNotOk
      If (bNotOk) Move -1 To iError 
      Else Begin
          Send Request_Save Of hServer
          If (Err) Move -2 To iError
      End
      Function_Return iError
  End_Function
</pre>
This save takes all the Data Dictionary rules into account that are linked to the validation and save mechanisms. So is much better than direct file access (using clear, move and saverecord).<br>
But this simple example does not work if the record has a relationship to a parent table. It is also not using any field settings like capslock.
         
===Relationships===
When the record you wish to create has a relationship to a parent record, you have to first find the parent record, just like you do in a view, prior to issueing the save. Lets create inventory for an existing vendors.
<pre>
  Function CreateInventoryItem Integer iVendor_ID String sItem_ID String sDescription
      Boolean bNotOk
      Integer iError
      Send Clear of Invt_DD
      // Find the parent record. This will also prime the foreign key (Invt.Vendor_ID)
      Send Clear of Vendor_DD 
      Move iVendor_ID To Vendor.ID
      Send Find to Vendor_DD Eq 1
      // Set the other fields
      Set Field_Changed_Value Of Invt_DD FIELD Invt.Item_ID To sItem_ID
      Set Field_Changed_Value Of Invt_DD FIELD Invt.Description To sDescription
      Get Request_Validate of Invt_DD to bNotOk
      If (bNotOk) Move -1 To iError 
      Else Begin
          Send Request_Save Of Invt_DD
          If (Err) Move -2 To iError
      End
      Function_Return iError
  End_Function
</pre>
This works nicely by finding the parent Vendor record, then create the new item.
===Field Settings===
In the above example the Item_ID is not set to capslock. This is because the capslock is actually not part of the validation or save, it is a setting used by the dbForm and other visual objects. If we want to also apply these settings, we need to do some more.
  Example required, checking the following Data Dictionary field property, from the Request_Validate function.
  Set Field_Options field Customer.Id to DD_CapsLock

==Updating existing records==

==Deleting records==

[[Category:Data Dictionaries]]