A Summary is an application that differs from all other application types because it does not display data on the screen, but rather writes the dataset back to the database in the form of a new table. Generally speaking, end users will never run a Summary, but instead Summaries will be scheduled to be run (hourly, nightly, monthly, etc.) so the data can be refreshed. Once the Summary has been run, it exists as a table like any other, available for use in Retrievals, Reports, or even Maintenance. While there are several uses for Summary applications, the three most common uses include:
Optimization of large data sets — Perhaps the data set spans across many tables, or is comprised of millions of records. Alternatively, maybe a data set has non-unique fields that need to be unique (such as needed when creating an Web 2.0 Option List). In these situations, using a Summary to first “optimize” the data set prior to creating the desired application can help immensly.
History tables — There may also be a business need within your company for audit trails of data, or storing volatile data that changes on a day to day basis. In these scenarios, creating a Summary can append to a single table in order to create a history, or audit view of your data.
Duplicate tables — There could be times where it is needed to join a table to itself, or to join out to the same table twice. This is not allowed in m-Power, however creating a Summary over this table essentially duplicates the table, which would allow for this behavior. Note: While this works, bear in mind that Summary files are not “live” in the sense that they will not be updated when the underlying data is, but rather remain as is until the Summary application is re-run.