If the application service defines a DATASET (static ProDataSet) parameter, you must create a ProDataGraph that at least represents an empty ProDataSet and contains the meta data (ProDataGraphMetaData) that describes the temp-tables and data-relations defined for the ABL static ProDataSet. There must be one ProDataObjectMetaData object for each temp-table and one ProDataRelationMetaData object for each DATA-RELATION object defined by the static ProDataSet. So, the meta data in the ProDataGraph must match the schema of the static ProDataSet in every particular.
Note: While you must define a ProDataGraph with all the meta data required to map a static ProDataSet schema, you can tell OpenEdge not to send temp-table schema information to the AppServer in order to optimize data transfer over the network. For more information, see the setNoSchemaMarshal() method in ProDataObjectMetaData class.
If the application service defines a DATASET-HANDLE (dynamic ProDataSet), you can pass a ProDataGraph with any or no meta data, including any or no ProDataRelationMetaData objects. As a minimum, you can pass a ProDataGraph with empty meta data (an empty ProDataGraphMetaData object), which produces an Unknown value (?) in the input DATASET-HANDLE. However, in practice, you must pass a ProDataGraph with meta data that represents the ProDataSet schema expected by the application service. So, most of the time, the programming for a ProDataGraph that maps to static or dynamic ProDataSet is identical.
For more information on the differences between static and dynamic ProDataSets, see OpenEdge Development: ProDataSets.
For a typical application, the general procedure for preparing a ProDataGraph for input is a two step process.
To prepare a typical ProDataGraph for input:
1. Create and initialize a ProDataGraph object with its meta data.
2. Create and add ProDataObject instances to the ProDataGraph.
