Try OpenEdge Now
skip to main content
ProDataSets
Introducing the OpenEdge DataSet : Using ProDataSets : Data sources
 

Data sources

Each temp-table in a ProDataSet can be loaded from a different data source. Updates made to a ProDataSet also need to be applied back to the data source. In the simplest case, the data source is an OpenEdge database or another database type that you can access through an OpenEdge Data Server. To support this, there is a Data-Source object that you define independent of a particular ProDataSet, and then attach to the ProDataSet when you need to fill data from the Data-Source or apply updates back to it. This allows you to pass a ProDataSet from one session to another without any database-specific definitions or dependencies going along with it. Also, in some cases you might need the same ProDataSet to attach to different Data-Sources at run time.
When a ProDataSet buffer has a Data-Source, the ProDataSet can perform a fill operation for the buffer's temp-table in one of two ways. If the buffer is for a top-level temp-table in the ProDataSet, meaning that it is not the child in some Data-Relation, then you can define a query that is referred to in the Data-Source definition to tell the AVM what records to load. This might identify, for example, a single header record representing something like a Purchase Order, which has many related child records in other tables. Or it could be a set of records satisfying some condition. If there is no query, then the top-level table is loaded with all the records from the underlying database table. This might be appropriate when the table represents a list of coded values such as states or order status codes that are to be used as a lookup list within the ProDataSet.
If a buffer is for a child of a Data-Relation, then the AVM can fill the child temp-table without any explicit query definition simply by examining the Data-Relation between it and the parent, and retrieving all child records for each parent. This is the standard case for a child of a Data-Relation. You can still define a query for the child buffer if the default selection based on the relation is not sufficient to identify the right records to retrieve, or if the query involves a join to one or more other tables that contribute fields to the temp-table. Note that if you define your own fill queries, or add rows to the ProDataSet's temp-tables in any other way, the AVM does not enforce the field relationships defined by the Data-Relation for you. You will not get an error if you add rows to a child table that do not match a row in the parent table.
One of the important values of the ProDataSet is that the contents of its tables, and therefore the business logic that uses its records and the user interface logic that displays them, can be defined independent of the nature or structure of the actual data sources. In some cases this simply means that the ProDataSet's temp-tables allow you to define internal tables whose fields come from different database tables, or have different names, or represent expressions, or are different in some other way from the underlying database.
In addition, you can fill a ProDataSet without having a Data-Source for a member buffer at all. If this case, you must supply the code that fills that buffer's table. Whether there is a Data-Source or not, an event is triggered that can execute application-specific code to handle the fill (if there is no Data-Source) or to extend the default behavior (when there is a Data-Source). This is just one example of the usefulness of events that allow custom code to either augment or replace default behavior, or to provide behavior where there would be no default.
In addition, because each buffer in the ProDataSet has its own Data-Source, a single ProDataSet can be filled, in a single operation, from a variety of different data sources that represent different databases or in some cases non-database customized data sources. And data can be loaded from the disparate sources in a coordinated, interleaved fashion so that you can be sure that the integrity of the Data-Relation is maintained during the fill. These are capabilities that .NET does not provide for its DataSets.