Extra Columns for Capture, Fail and History Tables - DSS 6 | Data Source Solutions Documentation

Documentation: Extra Columns for Capture, Fail and History Tables - DSS 6 | Data Source Solutions Documentation

Extra Columns for Capture, Fail and History Tables

Capture, Fail, and History tables are created automatically by Data Source Solutions DSS. They are for reference only and cannot be altered manually. These tables contain information about data capture, replication failures, and changes history. Each capture, fail, or history table created by DSS contains columns from the replicated table it serves, plus extra columns. These columns contain information about what the captured operation was and where it must be sent.

The following extra columns can appear in Capture, Fail or History tables:

Column	Datatype	Description
dss_address	string	Address of target location for change. Only set if action Restrict is defined with parameter HorizColumn.
dss_cap_loc	string	Name of location on which the change was captured.
dss_cap_tstamp	normally date, sometimes integer (number of seconds since 1st Jan 1970 GMT)	Timestamp of captured change. For log-based capture, this is the time that the change was committed (it did not logically "exist" before that moment). For trigger-based capture, this is when the DML statement itself was triggered. If DSS refresh fills this value, it uses the time that the refresh job started.
dss_cap_user	string	Name of the user who performed captured change. Supported only on few DBMSs, see capabilities Populates column dss_cap_user for use in ColumnProperties {dss_cap_user} substitutions.
dss_colval_mask	string	Mask showing the capture status of each column in the row. The mask string contains characters, each representing one column and indicating the status of that column’s value. The characters appear in the same order as the columns in the table definition. For example, `‑‑‑‑m‑` represents a six-column table and indicates that the second-last column value is missing while all other column values are available. Values (characters) are: `-`: Column value is a normal value, and no other mask status applies. A space character also represents the same status. `e`: Column value is an erased LOB. `j`: Column is a key column with a non-null value. `m`: Column value is missing. `n`: Column is a key column with a NULL value. `p`: Column value is a partial LOB. `t`: Column value is a trimmed LOB. `v`: Column value is changed. Earlier versions represented this using `u`. `V`: Column value is unchanged.
dss_err_msg	long string	Integration error message written into fail table.
dss_err_tstamp	date	Time at which integration error occurred. Written into fail table.
dss_op	number	Operation type. Values are 0 - Delete 1 - Insert 2 - After update 3 - Before key update 4 - Before non–key update 5 - Truncate table 6 – Verbose row-wise compare or refresh before insert and delete 7 – UI row-wise compare or refresh 8 - Delete affecting multiple rows 10 – Resilient variant of 0 11 – Resilient variant of 1 12 – Resilient variant of 2 13 – Resilient variant of 3 20 – Poor delete, with missing values 21 – Poor insert, with missing values 22 - Poor update with missing values 30 – Resilient variant of 20 31 – Resilient variant of 21 32 - Resilient variant of 22 41 – Variant of 21 with augmented values 42 – Variant of 22 with augmented values 51 – Resilient variant of 41 52 - Resilient variant of 42 A key–update sometimes appears as a before update followed by an after update, but is sometimes converted into a delete followed by an insert. A before non–key update row (dss_op=4) can be removed by defining action Capture with parameter NoBeforeUpdate. During an on-line refresh, a delete, insert and delete can be 'in-doubt'; these are shown as 10, 11 and 12 respectively. To ignore this 'in-doubt' information, use mod(10) to convert these back to 0, 1 or 2. Burst Integrate (Method=BURST) will convert a key update (dss_op 3 then 2) into a delete+insert pair (dss_op 0 then 1).
dss_seq	float or byte10 on Ingres, numeric on Oracle, timestamp on SQL Server	Sequence in which capture triggers were fired. Operations are replayed on integrate databases in the same order, which is important for consistency.
dss_tx_countdown	number	Countdown of change within a transaction. For example, if a transaction contains three changes, the first change would have a countdown value of 3, then 2, then 1. A value of zero indicates that commit information is missing for that change.
dss_tx_id	string	Transaction ID of captured change. This number is unique at any moment (each open transaction has a unique number) but may not be increasing.
dss_tx_seq	string	Sequence number of transaction. For log–based capture, this value can be mapped to the Ingres LSN or the Oracle SCN of the transaction's commit statement.