The table TB_JOB_VERSION stores the complete history of every feature. The feature table has one job relevant attribute: JOB_VERSION. The table TB_JOB_VERSION also controls which features are visible.
TB_JOB_VERSION holds the history of every feature and controls which features are visible.
With JOB_VERSION the FID is not unique, however with the Virtual Private Database it is.
Example: A “SELECT * from <feature class> returns the following values: |
With Job 1: 24, (.X.), 12.1, ‘A’, 1 |
With Job 2: 24, (.Y.), 13.5, ‘A’, 2 |
The JOB_OPERATION_ID shows the operation performed on the feature, for example, Insert, Modify, or Delete.
Attributes of TB_JOB_VERSION |
Description |
CONFLICT |
|
JOB_VERSION |
Specifies the version of an object (feature). Mandatory. |
JOB_OLD_VERSION |
Specifies the previous version of an object. Optional. |
JOB_ID |
Specifies the job ID. Mandatory. |
JOB_OPERATION_ID |
Specifies the job operation ID. Mandatory. 1 = INSERT, 2 = UPDATE, 3 = DELETE - 1 = Indicates that this feature has already been existing, at the moment of the job enabling of the feature class. |
OS_USER_NAME |
Stores the OS user. |
OPERATION_DATE |
Stores the operation date. |
STATE |
Defines the state of the feature, either: 1 = live 2 = pending 3 = open 4 = deleted (additional states can be defined in TB_JOB_STATE) |
After a table has been job enabled, a new value for JOB_VERSION is created for every object (sequence TB_JOB_VERSION_S):
If a user works on a feature within a certain job (JOB_ID) and for example modifies a feature, the operation is registered in TB_JOB_VERSION as follows:
You can trace the history of every feature, including the operation performed, the date, user, and initial appearance.
TB_JOB_VERSION.JOB_OPERATION_ID can be used in Display Manager to highlight modified or newly created features, so they can be distinguished from life features. Also, you can define a special style for the deleted features. See Styling Job-Enabled Features.