abahistsysobjects (ap_hso)

This table holds the history of abasysobjects. All objects that appear, or have appeared, in abasysojects will have one or more entries here, so you can retrieve the entire history of an object.

By the time, the table can become quite large. You can use the utility procedure ap_hso_purge_old_sp to clean it up.

Date and time when the object last was created or altered in the database.

What kind of object. See abaobjecttypes for a list of the object types that AbaPerls handles.

Whether this entry in abahistsysobjects corresponds to a deletion of the object. That is, the object was dropped, but not recreated, and thus the row for the object was deleted from abasysobjects.

Which subsystem the object belongs to. NULL if the object was loaded with ABASQL without the -subsystem switch, or beause the object was loaded into abasysobjects with ap_zz_sob_load_sp. There is no FK on this column to abasubsystems to permit for historic subystems that may have been flushed out with DBBUILD -restruct.

The version number in the version-control system of the file from which the object was loaded. NULL if the object was loaded from disk, typically by ABASQL. If the colunm is NULL, but ss_label has a value, this indicates that someone forcefully set ss_version to NULL, probably to be able to circumvent the checks for production or test databases.

The argument specifed with the -label switch with the load tool (ABASQL, DBBUILD or an update script generated by DBUPDGEN). Most of the time it will be an AbaPerls labels on the form LetterMajor.Middle.Minor, but it does have to be.

Path to the VC repository (e.g. SourceSafe or TFS database) the object was loaded from. NULL if object was loaded from disk. The path normally starts with a designator for the version-control system, but this may be missing for legacy data from the days when AbaPerls supported SourceSafe and nothing else.

The path to the directory in which the file from which the object was loaded resided. This can either be a path in the VC repository or a the path on disk.

In most cases path is the top directory to an AbaPerls directory structure, and the actual directory from which the file was loaded is implied by the file extension.

The value is the text "From database" when object was entered in abasysobejcts by means of ap_zz_sob_load_sp.

Name of the update/patch script or the build tool that performed this load of the SQL object.

Name of the file from which the the object was loaded. This is a name within the AbaPerls directory structure, for instance SUB/SOME_SP.SP.

"Unkown" for objects entered by ap_zz_sob_load_sp.

The file-extension part of filename, extracted to a column of its own to permit filtering, sorting etc. Is XXX for entries loaded by ap_zz_sob_load_sp.

An MD5 hash of the text of the file, before stripping of comments or anything. You can use the hash to see that two different version numbers actually had exactly the same contents. However, note that different hashes does not necessary imply that contents were differnt. For instance, the hash is likely to be different depending on the file was loaded directly from version-control or was bounced over disk with -noexec -get.

The column is nullable, but the column is only NULL for objects loaded before the column was added.