abasysobjects (ap_sob)

Name

abasysobjects

Code

ap_sob

Creation Date

13 december 2000 13:53:05

Modification Date

15 oktober 2014 13:38:41

Comment

All existing objects in the database according to AbaPerls


Table description

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.


Column list


Column


Domain

Data
Type

NOT
NULL

F
K


Comment

objname

 

sysname

X

 

Name of the object.

loadtime

 

datetime

X

 

When object was loaded.

objtype

ap_objtype

char(3)

X

X

Object type.

subsystem

ap_subsystem

varchar(30)

 

X

Subsystem object belongs to.

ss_version

 

int

 

 

Version number in source control.

ss_label

ap_sslabel

varchar(15)

 

 

Version-control label.

vc_repository

ap_path

nvarchar(250)

 

X

Path to VC repository

path

ap_path

nvarchar(250)

X

 

Path on disk of VC.

scriptname

ap_scriptname

varchar(64)

X

 

Load script/tool that loaded object.

username

ap_ntname

nvarchar(40)

X

 

Name of NT user that loaded the object.

hostname

ap_ntname

nvarchar(40)

X

 

Name of host from which the object was loaded.

domain

ap_ntname

nvarchar(40)

X

 

On which domain the user was logged into.

filename

ap_filename

nvarchar(180)

X

 

Filename in AbaPerls directory structure.

filetype

ap_filetype

varchar(10)

X

 

File extension.

crdate

 

datetime

 

 

When object was altered in SQL Server.

schema_ver

 

int

 

 

Always NULL.

parent

 

sysname

 

X

Parent object.

cert_id

 

int

 

 

Certificate for privileged module.

md5hash

ap_md5hash

binary(16)

 

 

MD5 hash of the file.


Keys

Name

Columns

Options

PK

pk_ap_sob

objname clustered

X


Indexes

Name

Columns

aba_sob_parent_ix

parent

aba_sob_filename_ix

filename, subsystem

objname

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.


loadtime

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


objtype

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


subsystem

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.


ss_version

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.


ss_label

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.


vc_repository

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.


path

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.


scriptname

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


filename

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.


filetype

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.


crdate

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.


schema_ver

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

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

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


cert_id

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.


md5hash

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.


Tables referring to abasysobjects

Child Table

Foreign Key Columns

abaindexdefinitions

objname

abaobjectstoragesettings

objname

abaspecialperms

objname

abasysobjects

parent


Tables abasysobjects refers to

Parent Table

Foreign Key Columns

abaobjecttypes

objtype

abarepositorymappings

vc_repository

abasubsystems

subsystem

abasysobjects

parent