When running applications with data-entry views, it is expected that your applications will contain multiple views and that some of these views will need to use the same table. Each view will have its own DDO structure encapsulated inside it. Very often these DDO structures use the same table, the same Data Dictionary subclass, and will probably even have the same object name. Further, all of these objects will share the same, single file-buffer. As long as you don’t try to put two DDOs based on the table in the same view, you will not have any problems.
The critical database operations are save and delete. These operations are safe. A DDO will make sure that it has the correct data in its file-buffer before it proceeds. This is all automatic. This means that the buffers are correct when the Data Dictionary events are processed (update, backout, deleting, Validate_Save, Validate_Delete, etc.). The DDOs notify DEOs that they need to display data by sending the DEOs the refresh message. The table’s file-buffers are correct during the refresh process.
There are times when the file buffers will not contain the same record as your DDO. During a multi-view, data entry application, it is possible that the file-buffer will not contain the data you think it does. If a user switched views in the middle of a process, it is possible that the record that the DDO thinks it is working with (which is identified in the DDO’s CurrentRowId property and the DDO-Field-Buffer) is not the record that is in the file-buffer. This doesn’t bother the DDO, but it may get you in trouble if you have DEO code that is based on the contents of a file-buffer.
The best way to deal with this is to always use the DDO-Field-Buffer value (Field_Current_Value).
If you want to make sure your File-Buffer is synchronized with the DDO-Field-Buffer you can send the message Refind_Records. This checks to see if the record in the File-Buffer is the same as the record in the DDO-Field-Buffer. If it is not, it will re-find the record. This updates the File-Buffer ensuring that the File-Buffer and DDO-Field-Buffer are synchronized. This performs this check for the DDO’s Table and all ancestor (parent, grandparent, etc.) DDOs.
The standard method of sending this message is:
Send Refind_Records {of DDO-Object}
For example, you may have a report that runs a batch process in the report’s body section which may switch records (the batch process may contain a DDO structure based on the same table). By sending Refind_Records after the process, you can be sure your File-Buffer contains the data for the record in your DDO.
Procedure Body
string sFont
integer iFontSize iStyle
Handle hoDD
Get Server to hoDD // the DDO currently handling the report
Send Update_Status (String(Customer.Customer_number))
// this runs a batch process which may find a different customer
Send CheckForDuplicateCustomers Customer.Customer_number
// this makes sure that the customer data is correct.
Send Refind_Records of hoDD
Move "arial" to sFont
Move 8 to iFontSize
Move (font_default) to iStyle
DfWritePos Customer.Customer_Number 0.8 (iStyle + Font_Right) 0
DfWritePos Customer.Name 2 iStyle -1 4.98
DfWritePos Customer.Address 7 iStyle -1 4.98
DfWritePos Customer.City 12 iStyle -1 3.98
DfWritePos Customer.State 15 iStyle -1 0.98
DfWritePos Customer.Zip 17 iStyle -1 1.98
End_Procedure // Body
This example is somewhat contrived - you should rarely need to use Refind_Records.
Understanding File Buffers and DDO Field Buffers