A view called DDOSynchronization has been created to show global and local record buffers. The view contains three groups, Customer, Inventory and Vendors, that contain fields of tables with the same names.
The first field, “Customer Number,” is bound to Customer_Customer_Number, but its server is the oCustomerDataDictionary. That is the main Data Dictionary for the view.
The Vendor field’s server is set to oInventoryDataDictionary. oInventoryDataDictionary and its server oVendorDataDictionary are a separate DDO structure within the view.
Running the sample app, selecting the ‘Customer Number’ field, and clicking the ‘Find Next’ icon from the top menu properly finds the records as expected. Selecting the ‘Inventory Item’ field from the Inventory Group and clicking the ‘Find Next’ icon from the top works for finding the first record, but after that it fails to retrieve the following record. Clicking it three additional times will finally load the second record.
This is happening with the Inventory group because there are three processes in the pool. Each has a different current record because the Data Dictionary structure is not synchronized. By default, the Framework only synchronizes the main DDO structure of a view, which is the Customers group in this example.
For the Customer group, the new record ID is saved every time the Find Next operation is executed, so that the next request will use the new record ID. For the Inventory group, whatever happens to be in the local buffer is used for the Inventory Data Dictionary. Having three processes means that there are three buffers that cause three different results.
Running through the same steps with the Debugger running does not show the same results because the Debugger only uses a single process and session. Testing with the Debugger running does not accurately test process pooling.
Adding Send AddDDOStructure oInventoryDataDictionary to the code fixes the issue.
It is important to always test outside the Debugger to confirm that the Data Dictionaries are synchronized.
The ‘Vendors’ group is bound to a different DDO structure that consists of a single Data Dictionary. Testing the grid results an error.
A grid or list keeps track of the current record. The error shown states that the current record of the list does not match the current record of the Data Dictionary. This is the same problem that was happening with the Inventory group, but with lists, errors are shown.
Adding the same code for the specific DDO will fix the issue: Send AddDDOStructure oVendorTwoDataDictionary
Local record buffers are synchronized by the Web Framework. DDO synchronization happens on the main Data Dictionary of a view and its related Data Dictionaries. If there are DDO structures within a view that are not related to the main Data Dictionary, they can be marked as needing synchronization using the AddDDOStructure procedure.
Data Dictionary Objects outside of views are not synchronized. Therefore, they need to be initialized for each request or operation. The same needs to be done for global buffers because they are not initialized unless they are used through Data Dictionaries.
There are some instances where the DDO Synchronization does not work properly, such as when the DDO structures are very complex. Custom related logic and deleted records can also cause synchronization to fail.
Errors are not always shown in live apps, but during development it is important for all of the errors to present because it often points to an issue within the app. pbShowAllRefindErrors property can be set to ‘True’ on the WebApp object during development, so that issues with the DDO synchronization can more easily be identified. This causes all errors to be shown when a record is not found. It should be turned off when the app is deployed.
REFERENCE LIBRARY
