Sample procedures: use attributes and methods
- Last Updated: October 16, 2024
- 4 minute read
- OpenEdge
- Version 12.8
- Documentation
Syntax
This topic extends the example procedures from Dynamic ProDataSet Basics to make them more truly dynamic. It then shows small code examples to illustrate the use of each of the methods and attributes.
To
modify the example, create a copy of DynamicDataSet.p and
name the new procedure DynamicDataSet2.p. Modify
the parameter list to eliminate the pcBuffers parameter
and to reorder the others to base the ProDataSet definition on the
database tables it is filled from. For example:
|
Also, you need another handle variable to point to a series of dynamic temp-tables you will create for the database sources, as shown:
|
Modify the block of code that walks through
the buffer handle list in DynamicDataSet.p to
walk through the list of database source tables and create a dynamic
temp-table LIKE each in turn.
Prepare each
temp-table definition and then add the table's default buffer handle
to the ProDataSet. The following block of code replaces the code
beginning with DO iEntry = 1 TO NUM-ENTRIES(pcBuffers):
|
As with other parts of these procedures, you can use the same temp-table handle variable for each of the temp-tables because once it has been added to the ProDataSet, the ProDataSet structure keeps track of the handle's value and position within the ProDataSet. You are then free to reuse the same handle variable to create another new dynamic temp-table that will have its own value for that handle.
There is one more small change. The pcKeyValue parameter
used to retrieve data related to a single top-level table is changed
to accept an expression such as "= 1" or "< 10",
by removing the equal sign literal (" = ") from
the QUERY-PREPARE method. This lets you have one
or more top-level records in the ProDataSet.
This will help illustrate some of the object attributes as we go along. For example:
|
The rest of the procedure remains the same. Now the dependency on static temp-table definitions has been removed, and there is no need to pass any handles in the parameter list that would not survive being passed across the application server boundary.
Copy DynamicMain.p to a new variant called DynamicMain2.p. In this new procedure, you can delete the static temp-table definitions because you are making everything dynamic. This is why dynamicDataSet2.p now creates them as dynamic temp-tables instead of receiving their handles.
You will need several variables along the way to hold various attributes and other values, so define them at the top of the procedure, as shown:
|
Change the RUN statement to
run DynamicDataSet2.p, and rearrange the parameters
to match. Change the pcKeyValues parameter "1" to
be "= 1", as shown:
|
Create a dynamic query that you will use in several parts of the procedure:
|
Remove all the rest of the code (the DISPLAY blocks) except
for the final DELETE OBJECT statement.
At
this point, you can add a series of blocks of code following the CREATE
QUERY statement to illustrate how to access the ProDataSet
dynamically.
This first example is a block of code that retrieves
the number of buffers in the ProDataSet. For each one, it retrieves
its buffer handle and then does a dynamic FIND-FIRST method
on that handle to position to the first record in that temp-table.
(FIND-FIRST is, of course, a standard ABL dynamic
buffer method.) The MESSAGE statement shows the
first two fields in each buffer:
|
When you run this, you can confirm that the dynamic temp-tables have the same data as the static temp-tables did before, as shown:



A ProDataSet
buffer that is not the child of a relation is referred to as a top-level
buffer. There might be more than one top-level buffer in a ProDataSet. The NUM-TOP-BUFFERS attribute
gives you the number of those buffers, as shown in the following
syntax:
|
The GET-TOP-BUFFER method returns
the handle of one of those buffers using its index within the list
of top-level buffers, as shown with this syntax:
|
This example code for DynamicMain2.p shows
that ttCustomer and ttSalesRep are both
top-level buffers, because they do not participate in a relation:
|
This code output proves the point:

