Data access procedure example
- Last Updated: February 11, 2026
- 2 minute read
- OpenEdge
- Version 13.0
- Documentation
Data access procedure example
Let us write a very simple support procedure to handle the data access for one new ProDataSet. You will use this ProDataSet in other examples in this set of topics.
To show something different from Orders and
OrderLines, and to provide a basis for data caching and
data sharing between procedures, the sample ProDataSet is a set of independent tables that
have coded values of one kind or another. Likely candidates are the State table, the Department table, and the
SalesRep table. These are all limited enough in scope that
the tables can be completely populated when the ProDataSet is first filled.
Here is the dsCodeTT.i include file, with the temp-table definitions:
|
You can see that the ttSalesRep table
is different from the database table it is derived from. It maps
some database fields to different names in the temp-table and generates
two calculated fields as well.
Here is the dsCode.i include file with the ProDataSet definition:
|
This could not be any simpler. There are no relationships between the tables, so the ProDataSet definition only needs to list them.
Now let us start to build the data access
support procedure that defines the Data-Sources and handles the FILL logic.
First, it defines the Data-Sources, which are also quite simple,
as each one names just a single database table the ProDataSet temp-table
is derived from. Thus, there is no need for query definitions. The
AVM can generate the queries it needs for loading data automatically,
as shown:
|
The other thing to note about the top of the procedure is that it does not include the temp-table or ProDataSet definitions. The ProDataSet is always referenced by its handle alone, which means that anything about the ProDataSet definition can change without requiring even a recompile of this procedure. The only dependencies are the specific fields that the procedures must map or reference for calculations. Even in those cases, the code that maps or references them could be made conditional so that it would not fail if the fields were removed from the ProDataSet, or this procedure was used with a version of the ProDataSet that did not have them.