This topic describes the layout of the Logs section of the Data Model and the information it provides.
From the Logs home page you can review various information about actions performed on the Data Model, obtained from the standard Data Model logs.
After clicking on the "Logs" tile in the "Data model" section of the desired Data Model, you will be taken to the Logs page, which is divided into the following four sections that you can access via the tabbed menu at the top.
Operations. Here you can see a table containing each action performed on the Data Model, either manually or by some Procedure steps.

The table is sortable and searchable using the interactive header fields.It is divided into the following columns, which contain information about the action performed:
The same information is contained in the Log files that are generated in the following path: Board\Dataset\Log\
The log files have the following name format: HBMP_DatamodelName_YYYYMM.log (for example, "HBMP_MyDatamodel_202302.log").
The Log file is rolled at the end of each month.
Please note that the log is generated only if the "Database Log Events" option is enabled in the "Log settings" section of System Administration.
Action Code: Each action has a specific action code made up of two letters, which usually are the initials of the action found in the Operation-Title column (i.e. the code for the action "Entity Modified" is "EM"). Note that this is not always the case, for example, the action code for a Data Reader action is "FR".
Date: The date on which the action was performed, displayed in the following format: YYYYMMDD (i.e. an action performed on the 23rd of January 2023 will be logged with the date "20230123").
Time: The time at which the action was performed, displayed in the following format: HH:MM (i.e. 10:15).
Username: The user name of the Board user who performed the action.
Operation title: The name of the action performed (i.e. if an Entity has been modified, the name of that action will be “Entity Modified”). Note that this is not always the case, for example, the Operation title for a Data Reader action is the name of the Data Reader protocol.
D.Flow Mode: The name of the Dataflow execution mode (i.e. the Dataflow algorithm used for the calculations). This column contains information only about Dataflow actions.
Target: The name of the target of the action. Depending on the type of action, this field can contain different information, such as the name of a target Cube of a Dataflow action, the name of an ASCII file imported by a Data Reader protocol, etc.
Elapsed: The time it took to perform the action, displayed in the following format: HHhMMmSSs (i.e. "00h01m23s").
File: Name of the resource on which the action has been performed. Depending on the type of action, this field can contain the names of different resources, such as the name of an Entity, the name of a Cube, the path and name of a Data Model backup or restore file, etc.
Record no.: Number of records read by a Data Reader protocol.
Validated: Number of records validated by a Data Reader protocol.
Rejected: Number of records rejected by a Data Reader protocol.
RAM: Information about the quantity of RAM used by an action, displayed in the following format: [UsedRAM/TotalRAM]Mb (i.e. "[4050/28000]Mb").
Status: Status of the action performed.
Error code: The error code in case the action fails.
Depending on the size of your browser window, not all the columns might show. By clicking the three dots at the end of the row, the rest of the operations info will appear below the row.
Saturation. This tab shows information about Entity saturation and Cube combination space allocation. It is intended for expert Data Model Developers who need to assess whether the Cube design, sizing, and limits are appropriate for the expected use of the application.
A Cube can run out of available combination space based on:
The number of sparse Entities in the Cube.
The "Max Item number" of those sparse Entities, whether fixed or set to "Auto".
In this context, running out of space means that the number of possible combinations for a specific Cube could exceed the current Cube index allocation. As a result, data may not be saved or accessed correctly.
For Cubes with more than two sparse Entities, this log helps identify the Entities that drive growth and could cause the Cube to exceed the number of possible combinations that can be stored in its indexes.
When reading the table, pay particular attention to the "Ratio" value. For Cubes that require new combinations to be created, a Ratio close to 1 means that there is little remaining space for new combinations. In these cases, review:
The Cube structure, for example to determine whether combinations should be moved from sparse to dense.
The current "Max Item number", for example when it is set to a very large number but the Saturation information indicates that the Entity is not highly populated.

Diagnostics. Here you can see various diagnostic details of the Data Model in XML format.

Data model list. Here you can see a full list of the Data Models that are currently active, i.e. loaded in the Platform memory (RAM).
Along the list of active Data Models, here you can also find other miscellaneous information about the Data Model, such as the number of active users, tasks, and the Layout response time.
