What then should go into a procedure that handles the data access layer of your application? In order to keep the layers of your application architecture as cleanly separated as possible, you want to think of the data access layer as having all the knowledge about the specific database structure or other data sources. References to database tables and fields and to other external data sources should be avoided everywhere else in your application if at all possible. At the same time, the data access layer should not be tied to the internal data representation more than it has to be. Here are a few basic guidelines:
Put your Data-Source definitions into the data access support procedure for the ProDataSet. These identify the specifics of the relationship between the internal and external data representations.
Put your FILL logic into this procedure as well. Your FILL logic can supplement the default loading of data into the ProDataSet's tables, or it can replace it entirely where there is no standard Data-Source.
Attach the internal procedures that contain the FILL logic to the ProDataSet. You can do this by passing the ProDataSet handle into a specific FILL procedure handler as an input parameter, as shown in the .
If you can code your FILL logic and other supporting logic without the static ProDataSet and temp-table definitions, leave them out of the data access procedures. This way you do not even have to recompile these procedures or check them for consistency with upper layers of the application when it is not necessary. In the example procedure, the temp-table and ProDataSet include files are left out and the few references to specific database fields that are needed are made dynamic, so that there are no dependencies on any fields other than the ones that need to be specifically mapped or transformed. If your data transformation is such that you would need many dynamic references, then go ahead and include the static temp-table definitions. Just consider omitting them when you can.
Put your Data-Source definitions into the data access support procedure for the ProDataSet. These identify the specifics of the relationship between the internal and external data representations.