Much of the data available to you can be used in a number of different ways. By choosing the appropriate table types for your applications, you can limit the number of objects that require modifications as your applications evolve.
A parameterized table is a table with one or more defined attributes that are used to partition the data in the table. These attributes can be specific to the actual data, the location of the data, or a combination of both the data and the location.
There are many employees submitting expenses to a company and it is important to know when individual expenses are processed. In a case such as this, you could define a parameterized expense table using employee number and processing date as the parameters, for example,
EXPENSES(empno, procdate).
When the data is accessed, you need to reference only the instance of the table that is specific to your requirements. For example, in a rule, to get the first expense for employee number 79912 for the date 2000-03-15, you would use the statement:
GET EXPENSES(77912, ’2000-03-15’);
A company stores data on one node and want access to the data from other nodes. For example, all the information regarding exchange rates is stored at a central location and employee expenses are stored at the location where each employee works. In this case, the location of a rates table and its data can be specified through the use of a location parameter and it is possible that the expenses table does not require a location parameter.
A minimal definition is a table definition that consists of only a table name and a location parameter. It is used in environments where the same data is accessed from a number of different nodes. The minimal definition points to the full definition and data located on a node remote to where the initial access is being made to the data.
Often, when building applications, a particular view of data is required that can be obtained from an already existing data source. Because the real data already exists, less maintenance and storage overhead is incurred if you can make use of non-persistent data in your applications.
Refer to Defining a Calculation (CLC) Table for information on defining calculation (CLC), parameter value (PRM), Execution Environment (EES), session (SES), and temporary (TEM) tables.
The data required for a parameter value (PRM) table, which holds the values of the data parameters of a parameterized table, can be obtained from the data already stored for the parameterized table. You do not need to add additional data to the data store to be able to use these values. However, it is possible that you require this specialized view of data to meet the requirements of your application.
A global field is a field defined by an application administrator to be used across applications. The definition of the field and the help associated with it are stored in the @GLOBALFIELDS table. A link to the table can be made when you are defining the fields of your tables. Your administrator determines your site’s global fields implementation. Refer to
Selecting Global Fields for more information.