abasysobjects (ap_sob)

This table supplements sysobjects with information about how the object was loaded and by whom. The purpose of the table is to serve as an audit table so that a DBA can see what AbaPerls thinks should be in the database. He can use the stored procedure ap_sob_report_suspects_sp to find deviations, for instance cases where someone has changed a stored procedure without using the AbaPerls tools. The table is also use when the environment is set to TEST or PROD to check version numbers.

In a perfectly maintained database, abasysobjects agrees completely with the objects listed by abasystablesview, save for object of the typ FIL which are object-less files (INSERT-files, INCLUDE-files, DLLs for assemblies.)

To load this table when you add the ABAPERLS subsystem in an existing database, use the stored procedure ap_zz_sob_load_sp.

The name of the object. The object name is the primary key. Since AbaPerls regards indexes as top-level objects, this means that names of indexes must be unique in the database, although this is not a requirement in SQL Server.

For object-less files, for instance INSERT-files, the object name is formed as subsystem!filename.xxx. This is because the same name can appear in several subsystems. There is one exception to this rule: for include-files the subsystem is not included in the object name.

Note: objects of the type FIL, will have their name truncated if their name exceed the length of sysname. From this follows that if two files are not unique within this limit, they will overwrite each other in abasysobjects.

Date and time when the object last was created or altered in the database. (Through AbaPerls, that is.)

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

Which subsystem the object belongs to. If NULL, this could be because the object was loaded with ABASQL without specification of the -subsystem switch, or beause the object was loaded into abasysobjects with ap_zz_sob_load_sp.

The version number in the version-control of the file from which the object was loaded. NULL if the object was loaded from disk, typically by ABASQL. If the value is NULL, but ss_label has a value this indicates that someone has forcefully set ss_version to NULL.

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 from which the file was loaded. This is the normalised path taken from abarepositorymappings. NULL if the file was loaded from disk.

The path to the directory in of the file from which the object was loaded. This can either be an path in the version-control system (in which case you can also expect a value in the column repository), or the path to a disk directory.

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.

The name of the update/patch script or the build tool that loaded the current version of the SQL object.

Name of the file from which 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 extenstion 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.

This column is copied from the column modify_date in the appropriate catalog view (e.g sys.objects) for the object when the object is written to abassobjects. Thus, if modify_date in the catalog view is different from abasysobjects.crdate, this indicates that the object has been loaded outside AbaPerls, and this is used by ap_report_suspects_sp. For tables, the value is copied from sys.objects.create_date, as modify_date for a table is also updated for operations like reindexing that happen outside AbaPerls.

For objects where SQL Server does not track modify_date/crdate, this column is NULL.

This is a legacy column that was used for SQL 2000 and earlier versions. It will be dropped some time in the future when a suitable occasion arises.

Parent object, for instance the table for an index or a constraint.

For files, the parent name is deduced from the filename if possible.

Parent relations are normally not recursive, but there is one case where an object can have a parent as well as children of its own: a history table for a temporal table will have the main table as its parent, and have indexes as children.

If this column is none-NULL, the object has been granted special permissions through the macros $DBPERM or $SERVERPERM. cert_id is the id in sys.certificates for the certificate with which the object was signed.

An MD5 hash of the text of the file, before stripping of comments or anything. The hash is used in the file-loading process to waive version-checks for DBBUILD and update scripts when the hash is the same. Note that 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.