# Hierarchical object types

<a id="database.stamm"></a>

## Master files (`stammX`)

> **Warning:** This page was automatically generated from the database schema dump and may be incomplete or incorrect.

**Master files** are the top hierarchy level of the enaio® DMS: a container for related business objects (customer file, project file, case file, …). A master file itself carries no document data; it structures subordinate [registers](hierarchical_object_types.md#database.register) and [document objects](hierarchical_object_types.md#database.object).

Per configured master-file object type, a table `stammX` exists holding all master files of that type. Analogously to the [object convention](hierarchical_object_types.md#database.object), **`X` = main type + 1**. The variants are:

* `stammX` — main table.
* `stammXr` — rights table.
* `stammXs` — shadow table (index-data history).
* `stammXlistY` / `stammXlistYs` — table-field data and its shadow variant.

### Type-specific index fields

From position 17 onward, the index fields configured in the object definition ([osobjdef](dms_object_types_index_fields_and_structures.md#database.osobjdef) / [osobjfields](dms_object_types_index_fields_and_structures.md#database.osobjfields)) for the respective master type X follow. The suffix convention (`feld*`, `zahl*`, `datum*`, `real*`) and the XML access via `dbname` are identical to [Object — type-specific index fields](hierarchical_object_types.md#database.object).

### Rights table (`stammXr`)

Analogous to the [object rights table](hierarchical_object_types.md#database.object): 4-column structure (`id`, `type`, `value`, `field`), identical across all master-file object types.

### Shadow table (`stammXs`)

Analogous to the [object shadow table](hierarchical_object_types.md#database.object): holds the index-data history of the master file. First column `osguid`, followed by the type-specific index fields of the corresponding `stammX` table.

### Table fields (`stammXlistY`, `stammXlistYs`)

Analogous to [object table fields](hierarchical_object_types.md#database.object): per table field Y defined on master type X, a `stammXlistY` table with `id` (FK to `stammX.id`) and `line`. Shadow variant `stammXlistYs` with `osguid` and `line`.

### Related Server-API jobs

* [dms.XMLInsert](../dms.md#dms.XMLInsert) — create a master file.
* [dms.XMLUpdate](../dms.md#dms.XMLUpdate) — modify master-file index data.
* [dms.XMLImport](../dms.md#dms.XMLImport) — insert/update via search match (combines search + insert/update on the same tables).
* [dms.XMLDelete](../dms.md#dms.XMLDelete) — delete a master file (cascades to registers and documents depending on options).
* [dms.GetObjectDetails](../dms.md#dms.GetObjectDetails) — master-file system fields.
* Object-type ID — structure of the master-file type ID X.

<a id="database.register"></a>

## Registers (`registerX`)

> **Warning:** This page was automatically generated from the database schema dump and may be incomplete or incorrect.

**Registers** are the subdivision level within a master file: they structure a [master file](hierarchical_object_types.md#database.stamm) into thematic areas (e.g. "Correspondence", "Contracts", "Receipts"). Registers themselves carry no document data; they hold [document objects](hierarchical_object_types.md#database.object) and, optionally, nested sub-registers.

Per configured register object type, a table `registerX` exists holding all registers of that type. Analogously to the [object convention](hierarchical_object_types.md#database.object), **`X` = main type + 1**. The variants are:

* `registerX` — main table.
* `registerXr` — rights table.
* `registerXs` — shadow table (index-data history).
* `registerXlistY` / `registerXlistYs` — table-field data and its shadow variant.

### Type-specific index fields

From position 19 onward, the index fields configured in the object definition ([osobjdef](dms_object_types_index_fields_and_structures.md#database.osobjdef) / [osobjfields](dms_object_types_index_fields_and_structures.md#database.osobjfields)) for the respective register type X follow. The suffix convention (`feld*`, `zahl*`, `datum*`, `real*`) and the XML access via `dbname` are identical to [Object — type-specific index fields](hierarchical_object_types.md#database.object).

### Rights table (`registerXr`)

Analogous to the [object rights table](hierarchical_object_types.md#database.object): 4-column structure (`id`, `type`, `value`, `field`), identical across all register object types.

### Shadow table (`registerXs`)

Analogous to the [object shadow table](hierarchical_object_types.md#database.object): holds the index-data history of the register. First column `osguid`, followed by the type-specific index fields of the corresponding `registerX` table.

### Table fields (`registerXlistY`, `registerXlistYs`)

Analogous to [object table fields](hierarchical_object_types.md#database.object): per table field Y defined on register type X, a `registerXlistY` table with `id` (FK to `registerX.id`) and `line`. Shadow variant `registerXlistYs` with `osguid` and `line`.

### Related Server-API jobs

* [dms.XMLInsert](../dms.md#dms.XMLInsert) — create a register (within a master file or parent register).
* [dms.XMLUpdate](../dms.md#dms.XMLUpdate) — modify register index data.
* [dms.XMLImport](../dms.md#dms.XMLImport) — insert/update via search match (combines search + insert/update on the same tables).
* [dms.XMLMove](../dms.md#dms.XMLMove) — move a register between master files or parent registers.
* [dms.XMLDelete](../dms.md#dms.XMLDelete) — delete a register.
* [dms.GetObjectDetails](../dms.md#dms.GetObjectDetails) — register system fields.
* Object-type ID — structure of the register type ID X.

<a id="database.object"></a>

## Document objects (`objectX`)

> **Warning:** This page was automatically generated from the database schema dump and may be incomplete or incorrect.

Per configured DMS object type, one `objectX` table exists holding all objects of that type. **`X` = `haupttyp` + 1**: `object1` contains objects with `haupttyp = 0`, `object17` those with `haupttyp = 16` etc. The full object-type ID is composed of `haupttyp` and `untertyp` (see Object-type ID).

An `objectX` table has the following column layout:

- **Positions 1–35:** the 35 **common system fields** — identical across all `objectX` tables (see below).
- **Positions 36+:** **type-specific index fields** (`feld1`, `feld2`, …, `zahl1`, …, `datum1`, …, `real1`, …) — configured differently per `X`.

### Type-specific index fields

Starting at column 36, the index fields configured in the DMS object definition ([osobjdef](dms_object_types_index_fields_and_structures.md#database.osobjdef) / [osobjfields](dms_object_types_index_fields_and_structures.md#database.osobjfields)) for that object type X follow. The column names follow a **type-dependent positional** notation; the suffix scheme is identical across all DMS object tables (`objectX`, `stammX`, `registerX`):

| Suffix scheme | DB data type | DMS data type (see [dms.GetResultList](../dms.md#dms.GetResultList)) | XML access in [DMSData](../xsd/DMSData.md) |
|---|---|---|---|
| `feld1`, `feld2`, … | `nvarchar(N)` | `TEXT` (`ostype="X"`) | `<Field dbname="feldN" datatype="TEXT" ostype="X">…</Field>` |
| `zahl1`, `zahl2`, … | `int` / `smallint` | `INTEGER` (`ostype="9"`) | `<Field dbname="zahlN" datatype="INTEGER" ostype="9">…</Field>` |
| `datum1`, `datum2`, … | `datetime` | `DATE` (`ostype="D"`) | `<Field dbname="datumN" datatype="DATE" ostype="D">…</Field>` |
| `real1`, `real2`, … | `decimal` / `real` | `DECIMAL` | `<Field dbname="realN" datatype="DECIMAL">…</Field>` |
The mapping "DB column name → semantic index field (display name, mask position, validation, value list)" is configured per object type and accessible via [dms.GetObjDef](../dms.md#dms.GetObjDef). In Server-API calls a field can be addressed alternatively via `dbname` (DB column), `internal_name` (internal field name from the object definition), `osguid` (field GUID) or `name` (display name) — see [dms.GetResultList](../dms.md#dms.GetResultList).

Number, order and data types of the type-specific fields differ per `X`:

- Example `object10`: 39 type-specific fields (a mix of `feld*`, `zahl*`, `datum*`, `real*`).
- Example `object11`: 1 type-specific field (`feld1`).
- Example `object17`: 2 type-specific fields (`datum1`, `feld1`).

> **Tip:** **Gaps** in the numbering are normal — when an index field is removed from the object definition, its DB column is kept unused, and new fields receive the next free number.

### Table fields (`objectXlistY`, `objectXlistYs`)

Table fields (grid fields) on an object type X are stored in dedicated tables `objectXlistY`. Y is the sequential number of the table field in the object definition (`list1`, `list2`, `list3`, …); each table field gets its own `objectXlistY` table. One row per grid row.

Common columns of every `objectXlistY` table:

| Name | Type | Length | Description |
|---|---|---|---|
| `id` | `int` | — | Reference to `objectX.id` — binds all grid rows to a specific main object. |
| `line` | `int` | — | Row number in the grid (1-based, sequential). |
After that, the type-specific columns of the respective table field follow (e.g. `feld1`, `feld2`, `datum1`, …) — analogous to the index fields on the main object table.

For every table field there is a shadow variant `objectXlistYs` with index-data history. Common columns: `osguid` (snapshot identifier) and `line`; followed by the type-specific columns.

### Related Server-API jobs

* [dms.XMLInsert](../dms.md#dms.XMLInsert) — create new objects.
* [dms.XMLUpdate](../dms.md#dms.XMLUpdate) — update index data / system fields (triggers a shadow entry when `indexhistflags` is active).
* [dms.XMLImport](../dms.md#dms.XMLImport) — insert/update via search match (combines search + insert/update on the same tables).
* [dms.XMLDelete](../dms.md#dms.XMLDelete) — delete an object or move it to the recycle bin.
* [dms.GetObjectDetails](../dms.md#dms.GetObjectDetails) — read system fields of an object.
* [dms.GetObjectHistory](../dms.md#dms.GetObjectHistory) — history overview.
* [dms.GetShadowData](../dms.md#dms.GetShadowData) — read the content of a shadow version.
* [dms.RestoreIndexdataVersion](../dms.md#dms.RestoreIndexdataVersion) — restore index data from shadow.
* [dms.GetObjDef](../dms.md#dms.GetObjDef) — mapping of the type-specific index fields.
* Object-type ID — structure of the object-type ID X.

<a id="database.sdrel"></a>

## sdrel

> **Warning:** This page was automatically generated from the database schema dump and may be incomplete or incorrect.

Structure-data relation table. Maps the hierarchical relation **master file (folder) → register → document object** in a single table — one row per storage location of a document, carrying references to `stamm_id`, `register` (register ID) and `object_id` plus the respective object types.

Belongs to the hierarchical object types ([stamm](hierarchical_object_types.md#database.stamm), [register](hierarchical_object_types.md#database.register), [object](hierarchical_object_types.md#database.object)) and is the central table for the folder–register–document assignment. The **nesting of registers** among each other is, however, **not** represented here — that is handled by [osparregrel](hierarchical_object_types.md#database.osparregrel).

### Columns

| Name | Type | Length | Description |
|---|---|---|---|
| `loeschen` | `smallint` | — |  |
| `zeitstempel` | `int` | — |  |
| `stamm_id` | `int` | — |  |
| `object_id` | `int` | — |  |
| `objekttyp` | `int` | — |  |
| `register` | `int` | — |  |
| `regtype` | `int` | — |  |
| `deleted` | `int` | — |  |

<a id="database.osparregrel"></a>

## osparregrel

> **Warning:** This page was automatically generated from the database schema dump and may be incomplete or incorrect.

Defines the relation between hierarchically nested registers within a folder (master file). One row per parent/child relation between two registers: `parentregid`/`parentregtype` points at the parent register, `registerid`/`registertype` at the child. The binding to the master file is via `folderid`/`foldertype`.

This nesting information is **not** represented in [sdrel](hierarchical_object_types.md#database.sdrel) — sdrel only maps the folder–register–document assignment.

### Columns

| Name | Type | Length | Description |
|---|---|---|---|
| `folderid` | `int` | — |  |
| `foldertype` | `int` | — |  |
| `registerid` | `int` | — |  |
| `registertype` | `int` | — |  |
| `parentregid` | `int` | — |  |
| `parentregtype` | `int` | — |  |
| `deleted` | `int` | — |  |