Historization of tables New from S 39.5.0

Information

• NEW Historization is enabled for all tables.

Details

• To enable historization,
  • the Historization parameter on the required data table in the Data Dictionary module and
  • the Historization parameter on the required data item(s) must be activated.

Details

• Envers generates a table with the _HIS suffix for each versionized table.
  • The history table of data table DT412 is named DT412_HIS, for instance.
• A history table contains all columns of the original table as well as the following columns:
  • REV = Revision
  • REVTYPE = specifies whether something is added (0), refreshed (1) or deleted (2)
• Each time something is added to, refreshed in, or deleted from the versionized tables, a new line with the respective field status is inserted.
• The initial object can be identified by its primary key.
• The change date is written in the Envers default data table REVINFO (REVTSTMP column).
• Via the REV field, the REVINFO table also links to all REV fields in the history tables.
• Each versionized table is identified by the same UUID field, independent of the actual main field of the database layer.
  • I.e. each _HIS table contains a UUID field with the help of which a specific line in a versionized table can be identified.
  • The UUID fields must exist in any versionized table in the database in order for the historization via Envers to work.

Note

• If, in the tables which are historized, new columns are inserted which are also historized, the same columns must be inserted in the historization tables.

Information

• The customizing files of Q1B and Q2B are historized.

Details

• Envers generates a table with the _HIS suffix for each versionized table (currently all tables of the Q1B and Q2B schemas).
  • The history table of data table DT412 is named DT412_HIS, for instance.
• A history table contains all columns of the original table as well as the following columns:
  • REV = Revision
  • REVTYPE = specifies whether something is added (0), refreshed (1) or deleted (2)
• Each time something is added to, refreshed in, or deleted from the versionized tables, a new line with the respective field status is inserted.
• The initial object can be identified by its primary key.
• The change date is written in the Envers default data table REVINFO (REVTSTMP column).
• Via the REV field, the REVINFO table also links to all REV fields in the history tables.
• Each versionized table is identified by the same UUID field, independent of the actual main field of the database layer.
  • I.e. each _HIS table contains a UUID field with the help of which a specific line in a versionized table can be identified.
  • The UUID fields must exist in any versionized table in the database in order for the historization via Envers to work.