The temp-table definitions that make up the ProDataSet allow developers to define, in a standard way, a level of indirection between the actual data configuration in a database, or other data source, and the data definition that the application uses. These table definitions can mask joins between tables in order to simplify data representation. They can rename fields to match names used in business logic or to standardize naming. They can combine data from one or more databases with data from other data sources. They can mask changes to the underlying data structure, for example, as database design work is done to gradually clean up a complex and inconsistent older design. Temp-tables allow all these things today, but the ProDataSet makes it more straightforward for developers to standardize their design on this view of data.

Developers can define ProDataSets statically or dynamically. The ProDataSet, whether static or dynamic, has a single handle that you can use to access its methods and attributes. You can pass the entire ProDataSet as a single parameter to a procedure within the same session, in another OpenEdge session, or to an application running on an entirely different platform such as Microsoft .NET.

The ProDataSet supports the parameter forms HANDLE, DATASET, and DATASET-HANDLE. Like the TABLE parameter form for an individual temp-table, the DATASET form passes the ProDataSet as a static parameter. Similarly, the DATASET-HANDLE form is like TABLE-HANDLE in that it passes a dynamic reference to the ProDataSet. When the procedure call is within a session, the ProDataSet is normally passed by reference for maximum efficiency. When the call is remote, the entire definition of the ProDataSet, with its temp-table buffers, relationships between buffers, and so on, is marshaled along with the data just as is done for temp-tables today.