Appendix C: Longview Database Tables
This topic contains information about the Longview database tables and objects. A database object is one of the elements of a database.
Database objects
There are four types of database objects:
The most important type of database objects are database tables.
Database tables
The application resides on a Relational Database Management System (RDBMS). An RDBMS generally functions on the same principle as a simple two-dimensional spreadsheet, in which the Longview database consists of tables with rows and columns.
Each table performs one of two functions:
- A metadata table is a table used to describe the meaning and structure of business data.
- A data table contains the actual data stored in the database.
Indexes
An index takes data stored in a table and sorts it, based on the order of the columns specified for the index. The actual space used by an index depends on the number of columns listed in the index and the amount of data stored in the corresponding table.
Temporary tables
A temporary table is a table used by the application to temporarily store batches of data before transfer to a data table. The temporary tables are created automatically when you start up the servers and deletes them when you shut the servers down.
When a server needs to send data to a data table, it first uses the temp table to store the data. When the temp table fills up or has the number of rows specified for the writer batch size, or the process finishes, the data in the temp table moves to the data table. This procedure helps to minimize processing bottlenecks and allows for faster handling of data.
The number of temporary tables depends on the number of servers in the Submission and Writer Server Pools.
Views
A view is the result set of a stored query against actual Longview tables or views. A view contains rows and columns, just like a real table, but can be used to join or display data in a different layout.
Database tables
Database tables fall into one of the following categories:
- Attribute tables
- Batch tables
- File attachment tables
- Elimination tables
- Journal entry tables
- Mappings tables
- Modeling tables
- Schedule tables
- User and group tables
- Workflow tables
- Metatables
- App tables
- Data tables
Attribute tables
An attribute is data used to describe the characteristics of an object in the application.
Attributes are stored in database tables and managed by the Management Server. They are cached on the user’s computer for faster access. Because the System Administrator performs most work on attributes in your system, you, as Database Administrator (DBA), need to perform fewer configuration tasks.
There are three attribute classes:
| Attribute classes | Description |
|---|---|
SYSTEM |
Describes the entire system at the highest level. Attributes of this class specify system-wide characteristics. There is only one object in the SYSTEM attribute class — the application itself. |
USER |
Describes the attributes of a particular user. Each user is an object in the USER attribute class. |
SYMBOL |
Describes the characteristics of individual symbols. Each symbol is an object in the SYMBOL attribute class. |
The application stores information related to attributes in the following tables:
| Table name | Description |
|---|---|
KLX_ATTR_DEFS |
The attribute definitions table provides details on the attributes that can be used in your system |
KLX_ATTRIBUTES |
The attributes table identifies the attributes in your system. |
KLX_SYMATTR_NUMVAL |
The symbol attribute numeric values table stores numeric values for SYMBOL class attributes. |
KLX_SYMATTR_STRVAL |
The symbol attribute string values table stores string values for SYMBOL class attributes. |
KLX_SYSATTR_NUMVAL |
The system attribute numeric values table stores numeric values for SYSTEM class attributes. It is identical in structure to the symbol attribute numeric values table (KLX_SYMATTR_NUMVAL). |
KLX_SYSATTR_STRVAL |
The system attribute string values table stores string values for SYSTEM class attributes. It is identical in structure to the symbol attribute string values table (KLX_SYMATTR_STRVAL). |
KLX_USRATTR_NUMVAL |
The user attribute numeric values table stores numeric values for USER class attributes. It is identical in structure to the symbol attribute numeric values table (KLX_SYMATTR_NUMVAL). |
KLX_USRATTR_STRVAL |
The user attribute string values table stores string values for USER class attributes. It is identical in structure to the symbol attribute string values table (KLX_SYMATTR_STRVAL). |
Batch tables
When a user submits data for any reason, the submission moves through the appropriate servers until it is complete. Each submission and process caused by the submission is logged in the batch tables.
Users can use the batch monitoring feature to track the data submission through the various servers.
The data server database stores information related to batches of server submissions in the following tables:
| Table name | Description |
|---|---|
KLX_BATCH |
The batch control table stores information on the batch in progress. |
KLX_BATCH_DETAIL |
The batch detail table stores information on completed batches. Since this table stores information on every completed batch, it can eventually grow quite large. Longview recommends that you truncate the batch detail table from time to time, to keep it to a manageable size. |
KLX_BATCH_QUEINFO |
The batch queue information table stores information on the status of batches in progress and in the server queues. This table is used so that the queues can be recovered in case of server failure. |
File attachment tables
File attachment tables store the contents and structure of the Longview Document Repository.
| Table name | Description |
|---|---|
LV_FILE_DATA |
This table stores the contents of files in the Longview Document Repository, including uploaded files. |
LV_FILE_DESC |
This table stores identity information for all files in the Longview Document Repository. |
LV_FILE_DIR |
This table stores the directory structure of the Longview Document Repository. |
Elimination tables
If your company contains several divisions that share the same corporate parent, it is possible that they do business with each other. To ensure that intercompany transactions are handled correctly, you need to identify each entity that does business with its siblings, and then perform an intercompany elimination on each of those transactions.
These tables store information related to intercompany eliminations in the following tables:
| Table name | Description |
|---|---|
KLX_IC_HEADER |
The intercompany headers table stores information on intercompany headers for each journal entry (JE). |
KLX_IC_OBJECT |
The intercompany objects table stores data on intercompany objects. |
KLX_IC_OWN_PCT |
The intercompany owner percentage table stores data on ownership percentage. |
KLX_IC_STOCK |
The intercompany stock table stores data on intercompany stocks. |
KLX_IC_TRANS_ELIM |
The intercompany transaction elimination table stores data on elimination transactions. |
KLX_ICC_TXN |
The intercompany calculated data transaction table stores calculated data on intercompany transactions |
KLX_ICL_TXN |
The intercompany leaf data transaction table stores leaf data on intercompany transactions. It is identical in structure to the intercompany calculated data transaction table (KLX_ICC_TXN). |
KLX_ICT_TXN |
The intercompany translated transaction table stores translated data on intercompany transactions. It is identical in structure to the intercompany calculated data transaction table (KLX_ICC_TXN). |
Journal entry tables
In many organizations, staff members at the divisional level take care of most of the routine financial data entry, which Corporate Head Office then organizes into a consolidated set of financial information. Each record is known as a journal entry (JE).
These tables store information related to journal entries in the following tables:
| Table name | Description |
|---|---|
KLX_JE_FILE_ATTACHMENT |
The journal entry file attachment table stores information on the file attachments of journal entries |
KLX_JE_GROUPS |
The journal entry groups table stores structure information on journal entry groups. |
KLX_JE_HEADER |
The journal entry header table stores structure information on journal entry headers, including the type and the name of the creator. |
KLX_JE_HEADER_BAK000 |
During journal entry restatement, the journal entry tables are truncated and then republished. Since journal entry tables contain source data, the tables are backed up in the _BAK000 tables in case the restatement fails. The KLX_JE_HEADER_BAK000 table is a backup of the KLX_JE_HEADER table. |
KLX_JE_SUBCATEGORIES |
The journal entry subcategories table stores structure information on journal entry subcategories. |
KLX_JEC_DETAIL |
The journal entry calculated detail table stores structure information on journal entries for calculated data, including dimension information. |
KLX_JEC_DETAIL_BAK000 |
During a journal entry restatement, the journal entry tables are truncated and then republished. Since journal entry tables contain source data, the tables are backed up in the _BAK000 tables in case the restatement fails. This table is a backup of the KLX_JEC_DETAIL table. |
KLX_JEL_DETAIL |
The journal entry leaf detail table stores structure information on journal entries for leaf data, including dimension information. It is identical in structure to the journal entry calculated detail table (KLX_JEC_DETAIL). |
KLX_JEL_DETAIL_BAK000 |
During a journal entry restatement, the journal entry tables are truncated and then republished. Since journal entry tables contain source data, the tables are backed up in the _BAK000 tables in case the restatement fails. This table is a backup of the KLX_JEL_DETAIL table. |
KLX_JESL_DETAIL |
The journal entry schedule leaf detail table stores structure information on journal entries for schedule leaf data, including dimension information. |
KLX_JET_DETAIL |
The journal entry translated detail table stores structure information on journal entries for translated data, including dimension information. It is identical in structure to the journal entry calculated detail table (KLX_JEC_DETAIL). |
KLX_JET_DETAIL_BAK000 |
During a journal entry restatement, the journal entry tables are truncated and then republished. Since journal entry tables contain source data, the tables are backed up in the _BAK000 tables in case the restatement fails. This table is a backup of the KLX_JET_DETAIL table. |
Mappings tables
Mappings tables store mapping data for maps and mappings created using the Mappings editor.
The application stores mapping information in the following tables:
| Table name | Description |
|---|---|
LV_SYM_MAPPINGS |
This table stores mapping indexes, methods, and expressions for mappings created using the Mappings editor. |
LV_SYM_MAPS |
This table stores information for maps created using the Mappings editor. |
Modeling tables
A modeling table is a table that stores parameters related to server-side modeling.
The application stores information related to rules and events in the following tables:
| Table name | Description |
|---|---|
KLX_BATCH_FROM_EVENT |
This table stores relational information for events that submit data and the resulting batches. |
KLX_MODEL |
This table stores the list of server rules used by your system for models, validations, rollups, event rules, and query rules. |
LV_EVENT |
This table stores all events triggered by batches. |
LV_EVENT_ACTIONS |
This table stores the triggered actions created in server rules that cause the system to perform certain designated functions when data in specific parts of the database changes or matches set criteria. |
LV_EVENT_FROM_BATCH |
This table stores relational information for events and the batches that triggered them. |
Schedule tables
In the application, a schedule is the concept of one or more extra dimensions, designed to store additional information on a particular cell in the application database.
The application stores information related to schedules in the following tables:
| Table name | Description |
|---|---|
KLX_SCHED_DIMS |
The schedule dimensions table stores the list of extra dimensions used by schedules. |
KLX_SCHEDLOCKS |
The schedule locks table stores information on schedule data currently locked, because it is in use by a user, or because the session ended abnormally before a lock was released. |
KLX_SCHEDULES |
The schedules table stores information on the schedules used in this system. |
User and group tables
A user group is a group of users with similar needs and responsibilities. The System Administrator can use a group to specify access settings for multiple users. These tables are also used to provide preconfigured User Reporting views. For more information, see the Longview Server Manager Guide.
The application stores information related to user groups in the following tables:
| Table name | Description |
|---|---|
KLX_USER_GRP_ACC |
The user group object access table stores the list of symbols that can be accessed by users in a particular user group. |
LV_GROUP_MAIN |
The group main table defines each user group. |
LV_GROUP_OPERATIONS |
The group operations table defines the operations that each user group is permitted to perform. |
LV_OPERATIONS |
The operations table contains identifiers for operations that have User Access Control applied to them. |
LV_ROLE |
The role table stores Data Server role information. |
LV_ROLE_ACC |
The role access table stores symbol access assigned to Data Server roles. |
LV_USER_DETAILS |
The user detail table contains basic information about each user. |
LV_USER_GROUP |
The user group table defines the membership of user groups. |
LV_USER_MAIN |
The user main table contains authentication related information for each user. |
| LV_USER_LICENSES | This user table contains the user's license(s). This table is only used when Longview is configured to be on the platform. |
LV_USER_OPERATIONS |
The user operations table defines the operations that each user is permitted to perform. |
LV_USER_PASSWORD |
The user password table contains the current password and password status for each user. |
LV_USER_PASSWORD_HISTORY |
The user password history table contains a history of passwords for each user. |
Workflow tables
The application can be used to create multi-step approval processes to populate the system with new data (for example, planning, forecasting, month-end Actuals consolidations). Each approval process reflects the steps that the data must go through, from submission by contributors, to approval by multiple levels of management.
The application stores workflow information in the following tables:
| Table name | Description |
|---|---|
KLX_WF_EMAIL |
The workflow email table stores information on the circumstances under which automated email templates are triggered in the application. |
KLX_WFAREA_LOG |
The workflow area log table stores log information on a DataArea in the application. |
KLX_WFAREA_STATE |
The workflow area state table stores information on the status of a DataArea in the application. |
KLX_WFTASK |
The workflow task table stores information on tasks performed in the application |
KLX_WFTASK_DATA |
The workflow task table stores data on tasks in the application. |
KLX_WFTASK_HIERMAP |
The workflow task hierarchy map table stores information on tasks in the application. |
KLX_WFTASK_LOCK |
The workflow task lock table stores database locks on tasks performed in the application. |
KLX_WFTASK_LOG |
The workflow task log table stores the results of a log query in the application. |
KLX_WFTASK_STATE |
The workflow task state table stores information on the status of tasks in the application. |
KLX_WFTASK_USER |
The workflow task user table stores information on the users who perform tasks in the application. |
Metatables
A metatable is a table used to describe the meaning and structure of business data. With two exceptions, each metatable has a fixed structure, no matter how many dimensions are in the application database. The two exceptions are the Partitions and Datalocks tables, which are dimension dependent.
The application stores metatable information in the following tables:
| Table name | Description |
|---|---|
KLX_CATEGORIES |
This table stores the name and ID associated with the category for Longview Analysis and Reporting templates. |
KLX_DATALOCKS |
This table stores information on data currently locked because it is in use by a user or because the session ended abnormally before a lock was released. |
KLX_DESC |
This table stores all descriptions for all languages (except for symbol descriptions). |
KLX_FILE_CAT_ASSIGNMENT |
This table stores information on which Longview Analysis and Reporting templates belong to which categories. |
KLX_MASTER_DIM |
The master dimension table stores information on the names of the dimensions used in your system. For example, if your system contains four dimensions, the master dimension table contains definitions for four entries, with the rest marked as unused. |
KLX_MASTER_SYMBOL |
The master symbol table stores information on the names of the symbols used in your system. |
KLX_OBJ_STAMPS |
The object stamps table stores time stamp information used for caching. |
KLX_PARENT_CHILD |
The parent/child relationships table stores a list of hierarchical symbol relationships in all dimensions. For example, the symbol relationship that Quarter 1 is a parent of January is stored here. |
KLX_PARTITIONS |
The partitions table stores information on the server partitions used in the database. The application uses this table for the partition recalculation process. The values stored in the dim_n_part columns determine the unique identifier of the intermediate file names used in the partition recalculation process. |
KLX_SHARED_FILES |
The shared files table contains the shared file information (file type and name) for a specific group. |
KLX_STATUS |
The status table stores information used by the application database servers. This table contains many parameters, many of which cannot be changed, and too numerous to list in this guide. However, you should be aware of some of the parameters you can adjust if necessary. The Server_Mode parameter is particularly useful and can have the following values:
|
KLX_SYM_DESC |
This table stores symbol descriptions for all languages. |
KLX_SYMBOL_STATS |
The symbol statistics table stores statistics collected by the COLLECT STATISTICS command. You can view collected statistics either in line mode or in a graphic interface. |
KLX_USER_SYM_ACC |
The user symbol access table stores the symbol access restrictions for all application users. The application determines symbol access according to symbol position in hierarchy classes. For example, a user may have read rights to entities in one division, but no access to any other divisions. |
LV_APPTABLES |
This system table lists the App tables and views in the database. For more information, see Understanding metatables related to App tables. |
LV_APPTABLE_COLUMNS |
This system table stores information about the structure of the App tables and views in your database. For more information, see Understanding metatables related to App tables |
LV_AUDIT_METADATA |
This table stores metadata changes in the system, such as user and group maintenance, symbol maintenance and attribute maintenance. The USE_METADATA_AUDIT_TRAIL application switch must be TRUE to enable this feature. |
Understanding metatables related to App tables
The LV_APPTABLES and LV_APPTABLE_COLUMNS metatables are specifically related to App tables and views. These tables are empty until you specify the required information; if you are creating your own App tables or if you plan to use views, you must use these tables as part of the configuration process.
Note: If your company uses Longview Tax your system contains preconfigured App tables. Consequently, the LV_APPTABLES and LV_APPTABLE_COLUMNS are populated with entries from these preconfigured tables. Deleting preconfigured columns may impact system functionality.
The LV_APPTABLES metatable should list the App tables that have been added to the database, and any views you would like to access via App tables. The metastable includes the following columns:
| Column name | Description | Valid values |
|---|---|---|
TABLEID |
Specify a unique numeric ID for the App table or view that you wish to register. |
integer |
TABLENAME |
Specify the name of the App table or view that you wish to register. This name must be identical to the SQL/Oracle table or view name. |
string |
USERCOLUMNSECURITY |
Specify whether this table enforces security through the user column. |
0 |
The LV_APPTABLE_COLUMNS table should describe the structure of App tables and views that have been added to the database and includes the following columns:
| Column name | Description | Valid values |
|---|---|---|
COLUMNID |
Specify a numeric ID for the column. |
integer |
TABLEID |
Specify the numeric ID for the App table or view that contains the column that you are registering. The Table ID was created using the LV_APPTABLES table. |
integer |
COLUMNNAME |
Specify the column header to display in the Table. This value must match the column name in the SQL/Oracle table or the view. For Oracle, this name should be in uppercase unless the column was explicitly created as case sensitive using quotes. |
Any string. This value can contain a maximum of 30 characters. |
DATATYPE |
Specify the Longview data type for the column. |
See Longview data types in App tables |
DATAVALUES |
If the column DATATYPE is symbol or autointeger, you can use this column to restrict the values. If the column DATATYPE is autointeger, you can use this column to specify the starting number for autointeger increments. |
For symbol data types: DimensionName or DimensionColumn: DimensionColumnName For autointeger data types: The number to start incrementing from. For all other types, you must use an empty string. For example, for SQL, ''. |
App tables
Your company can create and use App tables to input and store data for records that do not require hierarchical structure. Based on your company’s implementation, you may have custom App tables in your database that include the records that you want to display in a simplified format. For example, it may be more appropriate to access certain records, such as a task list, in a flat list rather than in a hierarchical format. App tables display in a Longview Table.
If you create an App table, you must manually add it to the LV_APPTABLES metatable, which registers the table as an App table, before you can display it in a Longview Table. Additionally, you must register column information for the App table in the LV_APPTABLE_COLUMNS metatable. You may also register views as App tables in the LV_APPTABLES metatable. However, you must register column information in the LV_APPTABLE_COLUMNS metatable as well. Ensure that the SQL or Oracle data type used for the App table column is valid for the Longview data type. For more information on Longview data types, see Longview data types.
Note: Longview recommends that you use all uppercase letters for App table names and view names, and that names do not contain more than 19 characters. In addition, Longview reserves the LV prefix for system App tables and system views, and therefore recommends that you avoid using this prefix for custom App tables and custom views. If your company uses Task Management, your system contains preconfigured App tables.
Adding columns
You can manually add custom columns to your App table. When you add columns to your App table, ensure that the database data type is appropriate for the Longview cell control that you want to use for the column. For information on cell controls, see Longview data types. For information on the corresponding SQL and Oracle data types, see Longview Table security.
Note: Longview recommends that you use all uppercase letters for column names.
If you use column names that are reserved keywords for either SQL or Oracle, WHERE statements in the DataTable definition (.lvdtd) must use quotes. These quotes will then have to be escaped. For example, WHERE "\"number\" > 500". In Oracle, when specifying the column names in the CREATE TABLE command, any column names not explicitly enclosed in double quotes are automatically created in upper-case. You should take this into account when adding column names to the LV_APPTABLE_COLUMNS table.
Longview data types
The type of column you create in SQL or Oracle will depend on the cell control you plan to use for that column and its related Longview data type. You must specify the appropriate Longview data type in the LV_APPTABLE_COLUMNS table. For more information on the DATATYPE column, see Understanding metatables related to App tables.
The following table lists the cell controls along with the valid Longview, SQL, and Oracle data types for Tables.
| Cell Control | Object Type | SQL data type | Oracle data type |
|---|---|---|---|
check box |
boolean |
int |
number(10) |
calendar control |
date |
datetime |
date |
text box (valid numbers only) |
number |
float |
number |
text box, drop-down list, or a combo box |
string |
Varchar |
varchar2 |
drop-down list populated with users in the system |
user |
int |
number(10) |
multiple-selection list box populated with users in the system |
userlist |
varchar |
varchar2 |
drop-down list populated with the dimensions in the system |
dimension |
int |
number(10) |
Longview Symbol Selector for the dimension or linked dimension column specified by DATAVALUES (for more information on DATAVALUES syntax, see Understanding metatables related to App tables. |
symbol |
int |
number(10) |
button that opens the Longview File Attachments dialog |
file |
varchar |
varchar2 |
read-only text box that the system automatically increments by 1 starting at the number specified for the DATAVALUES (for more information on DATAVALUES syntax, see Understanding metatables related to App tables. |
autointeger |
int |
number(10) |
read-only text box with the username of the currently connected user |
autouser |
int |
number(10) |
Longview Table security
Columns in an App Table that use the symbol data type enforce access through symbol access. A user must have access to the symbol specified in each column to retrieve a record. In addition, the user’s read/write access to the symbol determines whether the user can edit the record.
Data tables
Certain tables in a database system store data. A data table specifies the values in specific cells in the database. Each record in a data table contains the coordinates of a cell (one symbol from each dimension) and the value in that cell. Therefore, a data table contains one column for each dimension in the database, plus one column for the value stored in that cell. For example, the data tables for a four-dimensional database have five columns, and the data tables for a five-dimensional database have six columns.
To conserve disk space, the application uses a technique called sparsity. This means that symbol intersections containing a value of zero are not stored in the application database. If a symbol intersection is not found in the data tables, then it must have a value of zero. When a symbol intersection is assigned a value other than zero, it is added to the application database.
To make it easier to identify the purpose of a database data table from its name, Longview uses the following naming convention:
KLX_FTD_PNNN_CELLS
where:
- F is the family of data contained in the table. Select one of the following:
Table letter Description A
Tables containing adjusting data.
J
Tables containing adjusting schedule data (but not for leaf schedules).
S
Tables containing schedule data.
U
Tables containing unadjusted data.
- T is the type of data contained in the table. It can be one of the following:
Table letter Description C
Calculated data.
L
Leaf data.
P
Parent data.
T
Cumulative Translation Adjustment (CTA) data.
V
Validation data.
- D is the data type. It can be one of the following:
Table letter Description N
Numeric data.
S
String data.
The application stores data in the following tables:
Note: NNN below = 000-999
| Table name | Description |
|---|---|
KLX_ACN_PNNN_CELLS |
The adjusting calculated numeric data table stores the effect of posted journal entry data after running through server-side math logic. As Database Administrator (DBA), it is your responsibility to create this table during installation. |
KLX_ALN_PNNN_CELLS |
The adjusting leaf numeric data table stores data information on each journal entry. It is identical in structure to the Adjusting calculated numeric data table (KLX_ACN_PNNN_CELLS). |
KLX_APN_PNNN_CELLS |
The adjusting parent data table stores data information on details of each posted journal entry being rolled up. It is identical in structure to the Adjusting calculated numeric data table (KLX_ACN_PNNN_CELLS). |
KLX_ATN_PNNN_CELLS |
The adjusting CTA data table stores information on Cumulative translation adjustment (CTA) on adjusting data from each journal entry. It is identical in structure to the adjusting calculated numeric data table (KLX_ACN_PNNN_CELLS). |
KLX_AVN_PNNN_CELLS |
The adjusting validation data table stores adjusting data on validations. It is almost identical in structure to the adjusting calculated numeric data table (KLX_ACN_PNNN_CELLS). |
KLX_JCN_PNNN_CELLS |
The adjusting schedule calculated data table stores adjusting calculated data for schedules. |
KLX_JLN_PNNN_CELLS |
The adjusting schedule leaf numeric data table stores adjusting leaf data for schedules. It is identical in structure to the adjusting schedule calculated data table (KLX_JCN_PNNN_CELLS). |
KLX_JPN_PNNN_CELLS |
The adjusting schedule parent data table stores adjusting parent data for schedules. It is identical in structure to the adjusting schedule calculated data table (KLX_JCN_PNNN_CELLS). |
KLX_JTN_PNNN_CELLS |
The Adjusting schedule CTA data table stores information on Cumulative Translation Adjustment (CTA) on adjusting schedule data from each journal entry. It is identical in structure to the Adjusting schedule calculated data table (KLX_JCN_PNNN_CELLS). |
KLX_JVN_PNNN_CELLS |
The Adjusting schedule validation data table stores adjusting validation data on schedules. |
KLX_SCN_PNNN_CELLS |
The schedule calculated data table stores calculated data for schedules. |
KLX_SLN_PNNN_AUDIT |
The schedule leaf data audit table stores the changes in schedule leaf data for data audit functionality. It is identical in structure to the schedule leaf numeric data table (KLX_SLN_PNNN_CELLS) with the extra BATCH_ID column. This extra column is used to store the batch ID of a submission that triggers a data change. |
KLX_SLN_PNNN_CELLS |
The schedule leaf data table stores numeric leaf data for schedules. It is identical in structure to the schedule calculated data table (KLX_SCN_PNNN_CELLS). |
KLX_SLS_PNNN_CELLS |
The schedule leaf string data table stores string leaf data for schedules. It is identical in structure to the schedule calculated data table (KLX_SCN_PNNN_CELLS). |
KLX_SPN_PNNN_CELLS |
The schedule parent data table stores parent data for schedules. It is identical in structure to the schedule calculated data table (KLX_SCN_PNNN_CELLS). |
KLX_STN_PNNN_CELLS |
The schedule CTA data table stores information on cumulative translation adjustment on schedule data. It is almost identical in structure to the schedule calculated data table (KLX_SCN_PNNN_CELLS). |
KLX_SVN_PNNN_CELLS |
The schedule validation data table stores validation data on schedules. It is almost identical in structure to the adjusting schedule validation data table (KLX_JVN_PNNN_CELLS). |
KLX_UCN_PNNN_CELLS |
The unadjusted calculated numeric data table contains all the distributed unadjusted numeric data in your system. It is not necessary to back it up, as it is recreated by performing an enterprise restatement. |
KLX_ULN_PNNN_AUDIT |
The unadjusted leaf numeric data audit table stores the changes in unadjusted leaf data for data audit functionality. It is identical in structure to the unadjusted leaf numeric data table (KLX_ULN_PNNN_CELLS) with the extra BATCH_ID column. This extra column is used to store the batch ID of a submission that triggers the data change. |
KLX_ULN_PNNN_CELLS |
The unadjusted leaf numeric data table contains unadjusted numeric data corresponding to leaf or source level data, as well as other static data — essentially, all non-calculated numeric data. It is identical in structure to the unadjusted calculated numeric data table (KLX_UCN_PNNN_CELLS). |
KLX_ULS_PNNN_CELLS |
The unadjusted leaf string data table contains character string data corresponding to leaf or source level data, as well as other static data — essentially, all non-calculated string data. It is identical in structure to the unadjusted calculated numeric data table (KLX_UCN_PNNN_CELLS), except that it contains character strings instead of numeric values. |
KLX_UPN_PNNN_CELLS |
The Unadjusted parent data tables contain all the rolled-up data in your system, populated through the Writer Servers, with values calculated by the Math Server. It is identical in structure to the Unadjusted calculated numeric data table (KLX_UCN_PNNN_CELLS). The number of Unadjusted parent data tables in your system depends on the configuration of the logical partitioning. |
KLX_UTN_PNNN_CELLS |
The unadjusted CTA data table stores information on Cumulative Translation Adjustment on unadjusted data. It is almost identical in structure to the unadjusted calculated numeric data table (KLX_UCN_PNNN_CELLS). |
KLX_UVN_PNNN_CELLS |
The Unadjusted validation data table stores unadjusted data on validations. It is almost identical in structure to the adjusting schedule validation data table (KLX_JVN_PNNN_CELLS). |
Web Tables
The application stores information related to the web interface in the following tables:
| Table letter | Description |
|---|---|
KLX_WEB_PAGES |
The web pages table stores information on web pages |
KLX_WEB_PANEL_ITMS |
The web panel items table stores information on list items in web panels. |
KLX_WEB_PANELS |
The web panels table stores information on web panels. |
KLX_WEB_PG_GROUPS |
The web page groups table stores information on the user groups assigned to various web pages. |
KLX_WEB_PG_PANELS |
The web page panels table stores information on the location of web panels in various regions. |