Skip to content

Connecting More Than One DDO to the Same File

It is expected that your applications will contain multiple views and that some of these views will need to use the same data file. Each view will have its own DDO(s) encapsulated inside it. Each of these DDOs has the same main file, the same data-dictionary subclass, and will probably even have the same 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 file 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 most of the data-dictionary messages 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 data-file buffers are correct during the refresh process.

There are times when the data-file buffers are not to be trusted. During data entry, it is possible that the file buffer will not contain the data you think it does. If a user switches 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 current_record property) is not the record that is in the 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. There are several easy ways to get around the fact that file buffers are not to be trusted.

  • Whenever possible, use the value of the object instead of the value of the database field to which the object is connected.

  • When you need to deal with a value that is not stored in an object, you will have to use the file buffer. Before you use the buffer, you must send a message to the DDO telling it to make sure that the buffer is correct. The message is Refind_Records.

The standard method of sending this message is:

Send Refind_Records of (Server(Self))

For example, we might have a field_entry_msg procedure that loads a form with a default credit-card number from a record to appear when the field is entered. The property setting and the entry procedure follow:

Set Field_Entry_Msg item 0 to msg_Dflt_cc

Procedure Dflt_cc Integer iItem
    // only change blank unchanged items
    If ( (Value(Self, iItem) = '') And (Item_Changed_State(Self, iItem) = 0) ) Begin
        // first make sure the file buffer is right
        Send Refind_Records of (Server(Self))
        Set Value iItem to Cust.CC_Num
        Set Item_Changed_State iItem to True
    End
End_Procedure