Release 10.1A: OpenEdge Development:
ProDataSets

> ## Controlling the filling of each table

> You can issue a `FILL` on a ProDataSet or a buffer any number of times. You might do this to load data from multiple Data-Sources into a single ProDataSet, for example, which you could do by successively attaching different Data-Sources to the ProDataSet member buffer. Or you could modify the Data-Source query if you needed multiple successive sets of selection criteria to be used to populate all the data needed. Whether this could result in duplicate rows or other problems is determined by setting an attribute called `FILL-MODE`.

> A ProDataSet buffer has a `FILL-MODE` attribute that can be set to one of several character values:

> - `EMPTY` — If there is any data in the table it is emptied before the fill begins.

> - `NO-FILL` — This means that the table should not be filled at all on a `FILL` method because it has already been filled on a previous operation, or it will be filled separately. This might typically be used when one or more data tables are filled once with static or relatively static data that does not change when other data changes; for example, a list of codes that remains constant even as the rest of the ProDataSet is being reused and refilled for different `Orders` and their related records. If a `NO-FILL` data table is encountered in the course of a fill that is initiated at a higher level, then that table is not touched, and any relations to child buffers are not traversed, so the `FILL` effectively stops on that branch of the relation hierarchy. If you issue a `FILL` directly on a buffer marked `NO-FILL`, no error results, and no data is loaded into that buffer’s temp-table, beyond what might already be there.

> - `APPEND` — A `FILL` on a buffer whose `FILL-MODE` is `APPEND` adds records in addition to anything that’s already there, without doing any record comparisons. If this creates duplicate records that violate a unique index constraint on the temp-table, errors will result and the developer must cope with them. This mode is appropriate when you are implementing some form of batching, when a number of rows are added to a table on one `FILL` and then the following set on another `FILL`. However, keep in mind that `MERGE` mode is nearly as efficient as `APPEND` mode, so generally you should use the `APPEND` mode only when you want to be notified with a message about duplicates that occur rather than having them skipped without notification.

> - `MERGE` — `MERGE` is the default `FILL-MODE`. This mode tells Progress to check for records that are already in the temp-table, based on the table’s unique index, and otherwise add new records to the table. This assures that there are no duplicates. Note that `MERGE` mode requires that there is a unique primary index using the `KEYS` fields on the buffer’s temp-table. Progress simply allows the standard database support code to attempt to add each new record to the temp-table. If this fails because of a duplicate key violation in a unique index for the temp-table, that error is suppressed. The cost to this is minimal. Also, in `MERGE` mode, if a record with the same key is found, it is not replaced. Thus, `MERGE` cannot be used to refresh records already in a ProDataSet, but only to make it possible to fill a ProDataSet in such a way that the same record might be encountered twice without error or duplication. If you need to refresh records in a ProDataSet table, you can set the table’s `FILL-MODE` to `EMPTY`, or you can delete all records or selected records you need to refresh before doing the `FILL`.

> - `REPLACE` — If `REPLACE` is set, Progress checks each row being filled to see if it is already in the ProDataSet temp-table, based on the temp-table’s unique primary index. If a row with the same key values is already present, its field values are replaced by the field values from the database. If it is not already there, it is created in the temp-table. This `FILL-MODE` can be useful in situations where a row coming from the database may or may not be a duplicate of a row already in the ProDataSet. If the application cannot know which rows may have different values from the current values, it is not feasible to pre-delete the old row(s) reliably before doing a `FILL` that brings in new values. Keep in mind that this option is significantly more expensive than using `APPEND` or `MERGE` modes, and therefore you should use it only in situations where it is needed.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095