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.

For SQL 2005, 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.

On SQL 2000 SQL Server does not track modification date, only creation date, and this is what AbaPerls copies. Since sysobjects.crdate does not change on ALTER, this column alone cannot reveal if the object has been manipulated outside AbaPerls, but you also have to look at the column schema_ver, see this column.

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

This column is always set to NULL on SQL 2005.

On SQL 2000 copied from sysobjects. If schema_ver in abasysobjects is different from sysobjects, this indicates that the object has been altered in the database without the use of AbaPerls, with one exception: tables. (Because schema_ver in sysobjects is updated when foreigns keys are added or dropped, and AbaPerls is too lazy to update its schema_ver in this case.)

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

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

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.