abainstallhistory (ap_inh)

This table provides a history of all builds, update scripts and patches that have been executed in the database. After a successful run for a subsystem there are two entires: one START and one STOP (or a REMOVE). Thus, if there is a START without a STOP, this indicates an installation in progress - or one that never was completed.

Note that executions of ABASQL are not logged in this table.

The purpose of this table is to provide auditing information for the DBA. AbaPerls itself does currently not use the information in this table.

ckt_ap_inh_vccols (vc_repository IS NULL AND vc_path IS NULL OR
vc_repository IS NOT NULL AND vc_path IS NOT NULL)


Name of the script/tool that installed something in the database. This is DBBUILD in the case you add a subsystem, else it is an update/patch script generated by DBUPDGEN. When you run DBBUILD with -rebuild, the value in this column is "DBUILD -rebuild".

The action for the entry, usually START or STOP. REMOVE is added in place of STOP by an update script that completely removes a subsystem.

The affected subsystem. This column is normally non-NULL, but is in NULL if the ABAPERLS subsystem was added when one or more subsystems already was present, and the existing information in abainstallinfo was converted to abainstallhistory. It could also be NULL, if the ABAPERLS subsystem was updated to L1.0.0020 and there was entries in abainstallhistory without entries in abasubsystems, as previous versions did not enforces referential integreity between the two tables.

But these exceptions aside, if the first subsystem you install is ABAPERLS, this column is never NULL.

Which label that was used if any. This column is always NULL for a patch, because patches do not affect the subsystem label.

In most cases, this will be a label that exists in abasslabels. However, in the case where the ABAPERLS subsytstem was added to existing databases, you may see non-standard labels coming from abainstallinfo. You will also see a non-standard label, if DBBUILD or DBUPDGEN was run for a date.

The version-control repository (e.g. TFS database) from which the files in the script were taken.

Path in the repository from which the installation originated..