Detail Tables

Detail tables are transactional data that is created when an Extract Step is located within a Repeat Step.

In the most basic of transactional systems, a single detail table is used. However, it is possible to create multiple detail tables, as well as nested tables.

When detail and nested tables are present in the record, they are displayed as separate levels in the Data Model Pane.

Multiple detail tables

Multiple detail tables are useful when more than one type of transactional data is necessary, for instance if two different type of fields are used for different types of data. One example of this would be invoice data containing purchases (items with a set price, quantity, item number) as well as services (service with a price, frequency, contract end date, etc).

Creating more than one detail table is simple: in the Extract Step, change the name of the table from record.details to something else. In the example above, there could be two tables called record.purchases and record.services.

Nested Tables

Nested detail tables are used to create transactional data that is relative to other data. An example of this would be an invoice for a multi-service provider. In this example, a first table contains services (Internet, Cable, Home Phone, Mobile), while one or more nested tables giving details for charges and rebates on each of those services.

 

Nested tables are created in a similar fashion to multiple detail tables, with the difference that the dot notation contains multiple levels. In the example above, tables could be called record.services , record.services.charges, record.services.details , where "charges" includes all service prices and rebates, and "details" includes extra items such as movie rentals or long distance calls.

 

For the tables to be actually nested, the Repeat and its Extract step that extract the "charges" and "details" information must be located within the Repeat Step that extracts data to "record.services". In such a setup, "record.services.charges" is a child table of "record.services", and one "charges" table is created for each row in the "services" table.

Creating nested tables is currently an advanced feature, and using these nested tables in the Designer module requires some amount of coding.

Table of Contents

Index

Glossary

-Search-

Back