As we have discussed in earlier chapters, in most cases your ProDataSet and temp-table definitions on the server-side of the application (at least) will be statically defined, because they represent specific sets of data with their own distinct structure and characteristics. Therefore the first element in a typical Data Access object will be the temp-table and ProDataSet definitions for the data it retrieves from the data sources.
There is no reason why some Data Access objects could not be based on dynamic ProDataSets, especially if they represent a collection of tables or sets of table in the database that all have a similar structure and are all processed in the same way. As always, if you support these kinds of variant objects, you should make sure you structure them in such a way that other objects that communicate with them do not need to know whether their data comes from static or dynamic objects. Since the AVM supports freely interchanging static and dynamic temp-tables and ProDataSets when you pass them as parameters, this should not be difficult.
Here are the include file references from the earlier example procedure OrderSource.p, which is really an example of a Data Access object:
{dsOrderTT.i}
/* …where the include file has these definitions:
DEFINE TEMP-TABLE ttOrder NO-UNDO LIKE Order
FIELD OrderTotal AS DECIMAL
FIELD CustName LIKE Customer.NAME
FIELD RepName LIKE SalesRep.RepName.
DEFINE TEMP-TABLE ttOline NO-UNDO LIKE OrderLine
BEFORE-TABLE ttOlineBefore.
DEFINE TEMP-TABLE ttItem NO-UNDO LIKE ITEM
INDEX ItemNum IS UNIQUE ItemNum.
*/
{dsOrder.i}
/* … where the include file has this definition:
DEFINE DATASET dsOrder FOR ttOrder, ttOline, ttItem
DATA-RELATION OrderLine FOR ttOrder, ttOline
RELATION-FIELDS (OrderNum, OrderNum)
DATA-RELATION LineItem FOR ttOline, ttItem
RELATION-FIELDS (ItemNum, ItemNum) REPOSITION.
*/
These are defined as two separate include files just to make it possible to include them independently in a procedure where you do not need or want both.
How are these definitions used in the Data Access object? If you remember the interaction from the sample procedure OrderSource.p and its Business Entity, OrderEntity.p, the definitions are used for compilation only, so that the AVM can understand references to temp-tables and their fields in the internal procedures inside the Data Access procedure.
Why is this? The Business Entity object, described later, "owns" the data for its instance of the ProDataSet, whether that is all the data for an Order or summary information for all of a SalesRep's Orders or whatever else it may be. Every running instance of the Business Entity represents a distinct instance of its ProDataSet and a distinct set of data rows.
By contrast, the Data Access object only serves to populate the Business Entity's ProDataSet with data, and where necessary to assist in getting updates back to the data source. In any call, the actual ProDataSet instance will be passed in from the Business Entity or other requesting procedure BY-REFERENCE, so that it replaces the locally defined instance that is used to compile the Data Access procedure. Since each call to the Data Access object passes in a ProDataSet instance, there should be no reason why a single running instance of the Data Access procedure should not be able to serve all requests. It needs to be designed to make sure that there is no context kept from call to call that would prevent this, or else context needs to be managed in some way if this is necessary.
The local temp-table and ProDataSet definitions also cause an instance of the ProDataSet and its temp-tables to be instantiated in the data access procedure. Since this instance is not actually used at run time, it is important to observe the guideline discussed in earlier chapters concerning ProDataSets passed BY-REFERENCE, namely that you should not use the handle or any other references to this ProDataSet instance from the procedure's main block in code located within one of the procedure's internal procedures that receives the ProDataSet as a parameter.
