As you have learned, a ProDataSet is made up of objects that exist in earlier OpenEdge releases, namely buffers, queries, and temp-tables, along with the new objects Data-Relation and Data-Source. This topic reviews how these objects are related in terms of creating, scoping, and deleting.

As described earlier, a Data-Relation is an object that exists only within the context of a particular ProDataSet. It cannot be separately defined. It receives a handle when it is created as part of the instantiation of a ProDataSet with Data-Relation definitions, or when the relation is added dynamically to the ProDataSet. It has the same scope as the ProDataSet and is deleted when the ProDataSet is deleted.

You can define or create a Data-Source independent of a ProDataSet. This is important because Data-Source definitions cannot be passed with the ProDataSet to other sessions, where the database tables named in the Data-Source definition likely are not available. A Data-Source, whether static or dynamic, has a life independent of the ProDataSet. It is attached to and detached from a ProDataSet when it is needed. If it is dynamic, it must be independently deleted as an object if this is not done automatically when its procedure is deleted with a widget pool.

A Data-Source cannot be attached to more than one ProDataSet at a time. This is necessary to prevent conflicts between different ProDataSet buffers trying to use the same Data-Source. An attempt to attach a Data-Source to more than one ProDataSet buffer results in a run-time error.

A dynamic buffer must be created before it is used in a ProDataSet, and a static buffer must be defined before it is used in a ProDataSet. Dynamic buffers and temp-tables are deleted by default when the ProDataSet where they are used is deleted, and there is a logical AUTO-DELETE attribute for a dynamic buffer, which can be set to false to override this.

A temp-table is a separate object that is defined or created before it is used in a ProDataSet. When it becomes part of a ProDataSet, there are rules on the FILL operation, along with a FILL-MODE attribute, to control what happens to any data that might be in the temp-table when it is actively used as part of a ProDataSet. A dynamic temp-table is automatically deleted when the ProDataSet it is part of is deleted (unless you set the NO-AUTO-DELETE attribute to prevent this). A static temp-table simply goes back to being an ordinary temp-table. There are rules that are enforced in the implementation to prevent unacceptable behavior in ABL. The general intention is not to overly restrict the ability to use these objects flexibly and independently, just because of the possibility that a poorly written procedure might yield results the developer did not intend.

A temp-table can be part of multiple ProDataSets at the same time. If a ProDataSet is built up of tables in other, less complex ProDataSets, which is a very valuable feature, then it makes good sense to allow a temp-table to be simultaneously part of both ProDataSets. For example, a ttItem temp-table that is the only table in an Item ProDataSet, might be used as part of a more complex PO ProDataSet. It would be awkward and unnatural to force these two ProDataSets to use independent temp-table definitions when the whole purpose of building one from the other is to use the same underlying temp-table structure in both. It must be understood that multiple references to a temp-table within the scope of that temp-table are in fact using the same instance of the temp-table. There is only one set of records in the temp-table at any time, and if code manipulating the temp-table through its ProDataSets is at cross-purposes, then the result can be undesired behavior. But this is the developer's responsibility and entirely under the developer's control. There is no way to create multiple instances of a single temp-table definition within a procedure. Each ProDataSet must, however, use its own distinct buffer for the temp-table so that currency can be maintained independently in the ProDataSets.

If you require multiple instances of the same ProDataSet, or multiple instances of some of the components of a ProDataSet such as its temp-tables, you can accomplish this in several ways. If your definition is static, the best general design is to include the ProDataSet definition along with related definitions for objects such as its temp-tables, in a procedure that represents that ProDataSet as a business object. You can then create an API for that object procedure that has the necessary routines to fill the ProDataSet based on some set of parameters, to return it to the caller, to accept updates, to encapsulate business logic, and other requirements. If you need multiple instances of that ProDataSet as a complete business object, you run an instance of its procedure PERSISTENT for each one. Each procedure instance then holds the same definition and the same logic, but a distinct set of related data. Using ABL constructs such as super procedures, along with the callback mechanism for ProDataSet events, which is described in Event procedures for ProDataSets, you can share single business logic procedures among any number of instances of a ProDataSet procedure.