Dokumentobjekte (objectX)

Diese Seite wurde automatisch aus dem Datenbank-Schema-Dump generiert und kann unvollständig oder fehlerhaft sein.

Pro konfiguriertem DMS-Objekttyp existiert eine objectX-Tabelle, die alle Objekte dieses Typs hält. X = haupttyp + 1: object1 enthält Objekte mit haupttyp = 0, object17 solche mit haupttyp = 16 etc. Die volle Objekttyp-ID setzt sich aus haupttyp und untertyp zusammen (siehe Objekttyp-ID).

Eine objectX-Tabelle hat den folgenden Spaltenaufbau:

  • Positionen 1–35: Die 35 gemeinsamen Systemfelder — identisch über alle objectX-Tabellen (siehe unten).

  • Positionen 36+: Typspezifische Indexfelder (feld1, feld2, …, zahl1, …, datum1, …, real1, …) — je X unterschiedlich konfiguriert.

1. Gemeinsame Systemfelder

Die folgenden 35 Systemfelder kommen in allen objectX-Tabellen vor (Positionen 1–35, in dieser Reihenfolge). Ab Position 36 folgen typspezifische Indexfelder (feld*, zahl*, datum*, real*) — diese unterscheiden sich je X und werden nicht hier dokumentiert.

Name Typ Länge Beschreibung

id

int

Interne Objekt-ID (Primärschlüssel). Entspricht dem DMS-Systemfeld OBJECT_ID.

zeitstempel

int

Zeitstempel der letzten Indexdatenänderung (UNIX-Time). Entspricht OBJECT_TIME.

haupttyp

smallint

Numerischer Haupttyp des Objektes — bestimmt die Tabellenzuordnung (X = haupttyp + 1, d. h. ein Datensatz in object17 hat haupttyp = 16). Entspricht dem DMS-Systemfeld OBJECT_MAIN (dort als sprechender Wert wie WINDOWS oder IMAGE dargestellt).

untertyp

smallint

Untertyp des Dokumentes. Entspricht OBJECT_CO.

anzahl

smallint

Anzahl der Dokumentdateien (Seiten). Entspricht OBJECT_COUNT.

angelegt

datetime

Erstellungsdatum des Objektes. Entspricht OBJECT_CRDATE.

anleger

nvarchar

255

Benutzername des Erstellers. Entspricht OBJECT_CRID.

archiviert

datetime

Datum der Archivierung. Entspricht OBJECT_AVDATE.

archivar

nvarchar

255

Benutzername des Archivars. Entspricht OBJECT_AVID.

flags

int

Statusflags des Dokumentes (Bitmaske, z. B. archivierbar/archiviert). Entspricht OBJECT_FLAGS.

links

smallint

Anzahl der Verknüpfungen des Objektes. Entspricht OBJECT_LINKS.

medium_doc

int

ID des Archivierungsmediums der Dokumentdatei. Entspricht OBJECT_MEDDOCID. Verweist auf medien.

name_doc

nvarchar

255

Mediumname der Dokumentdatei auf dem Archivierungsmedium. Entspricht OBJECT_MEDDOCNA.

medium_dia

int

ID des Archivierungsmediums der Vorschaudatei (Dia). Entspricht OBJECT_MEDDIAID.

name_dia

nvarchar

24

Mediumname der Vorschaudatei (Dia). Entspricht OBJECT_MEDDIANA.

version

int

Versionsnummer des Dokumentes. Entspricht OBJECT_VERID.

lockuser

int

ID des sperrenden Benutzers (0 = nicht gesperrt). Verweist auf benutzer.id. Das DMS-Systemfeld OBJECT_LOCKUSER liefert auf Server-API-Ebene stattdessen die Anzeigewerte UNLOCKED / SELF / OTHERS und übergibt den DB-Wert als value-Attribut.

foreignid

nvarchar

248

Fremd-ID eines Verweisdokumentes. Entspricht OBJECT_FOREIGNID.

systemid

int

System-ID des Objektes (Zuordnung zu einem externen System). Entspricht OBJECT_SYSTEMID.

modifyuser

nvarchar

255

Benutzername des letzten Bearbeiters. Entspricht OBJECT_MODIFYUSER.

modifytime

int

Zeitstempel der letzten Änderung am Objekt (UNIX-Time). Entspricht OBJECT_MODIFYTIME.

deleted

int

Markierung für in den Papierkorb verschobene Objekte. Entspricht OBJECT_DELETED.

osowner

nvarchar

32

GUID des Eigentümers des Objektes. Entspricht OBJECT_USERGUID. Verweist auf benutzer.osguid.

ossd

nvarchar

32

ID des Security Descriptors des Objektes. Entspricht OBJECT_OSSD. Wird von dms.SetSD, dms.ReadSD und dms.CreateSD verwendet.

dochistflags

smallint

Flags zur Steuerung der Dokumentdatei-Historisierung. Entspricht OBJECT_DOCHISTFLAGS.

indexhistflags

smallint

Flags zur Steuerung der Indexdaten-Historisierung. Entspricht OBJECT_INDEXHISTFLAGS. Steuert, ob beim Ändern Einträge in die objectXs-Shadow-Tabelle geschrieben werden.

filesize

bigint

Größe der Dokumentdatei in Bytes. Entspricht OBJECT_FILESIZE.

mimetypeid

int

MIME-Typ-ID der Dokumentdatei. Entspricht OBJECT_MIMETYPEID. Verweist auf die über dms.GetOsMimetypes abrufbare MIME-Typ-Liste.

props

int

Property-Flags des Objektes (interne Bitmaske).

signstate

int

Signaturzustand des Dokumentes. Entspricht OBJECT_SIGNSTATE.

retention_planned

datetime

Geplantes Aufbewahrungsenddatum (vor Bestätigung). Entspricht OBJECT_RETENTION_PLANNED. Wird durch std.SetPlannedRetention gesetzt.

retention

datetime

Verbindliches Aufbewahrungsenddatum. Entspricht OBJECT_RETENTION. Dokumente dürfen vor Ablauf dieses Datums nicht gelöscht werden.

docpagecount

int

Anzahl der realen Dokumentseiten. Entspricht OBJECT_DOCPAGECOUNT.

txtnoticecnt

int

Anzahl der Textnotizen am Dokument.

pdfannocnt

int

Anzahl der PDF-Annotationen am Dokument. Verweist auf dms.GetPDFAnnotations.

2. Typspezifische Indexfelder

Ab Spalte 36 folgen die Indexfelder, die in der DMS-Objektdefinition (osobjdef / osobjfields) für den jeweiligen Objekttyp X konfiguriert sind. Die Spaltennamen folgen einer typabhängig-positionellen Notation; das Suffix-Schema ist über alle DMS-Objekttabellen (objectX, stammX, registerX) hinweg identisch:

Suffix-Schema DB-Datentyp DMS-Datentyp (siehe dms.GetResultList) XML-Zugriff in DMSData

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>

Die Zuordnung „DB-Spaltenname → semantisches Indexfeld (Anzeigename, Maskenposition, Validierung, Werteliste)" ist pro Objekttyp unterschiedlich konfiguriert und über dms.GetObjDef abrufbar. In Server-API-Aufrufen kann ein Feld wahlweise über dbname (DB-Spalte), internal_name (interner Feldname aus der Objektdefinition), osguid (GUID des Feldes) oder name (Anzeigename) adressiert werden — siehe dms.GetResultList.

Anzahl, Reihenfolge und Datentypen der typspezifischen Felder unterscheiden sich pro X:

  • Beispiel object10: 39 typspezifische Felder (Mischung aus feld*, zahl*, datum*, real*).

  • Beispiel object11: 1 typspezifisches Feld (feld1).

  • Beispiel object17: 2 typspezifische Felder (datum1, feld1).

Lücken in der Nummerierung sind normal — wird ein Indexfeld aus der Objektdefinition entfernt, bleibt seine DB-Spalte ungenutzt erhalten, neue Felder erhalten dann die nächste freie Nummer.

3. Rights-Tabelle (objectXr)

Zu jeder objectX-Tabelle existiert eine Rights-Tabelle objectXr (X = Objekttyp-ID). Sie hält die Berechtigungseinträge, die für jedes einzelne Objekt gelten (komplementär zum globalen Sicherheitssystem via ossd und Security Descriptors).

Alle objectXr-Tabellen haben identisch genau 4 Felder (alle NOT NULL):

Name Typ Länge Beschreibung

id

int

Objekt-ID. Verweist auf objectX.id.

type

int

Berechtigungstyp (z. B. Benutzer, Gruppe, Rolle) — interne Bitmaske zur Unterscheidung des Trägers.

value

nvarchar

255

Berechtigungswert: GUID des Benutzers/der Gruppe (benutzer.osguid bzw. gruppen.osguid) oder Rollenname, je nach type.

field

int

Feld- oder Aktions-Bitmaske, die regelt, welche Operationen (Lesen, Ändern, Löschen, …) auf welchen Indexfeldern erlaubt sind.

Weiterführend: Das systemweite Sicherheitskonzept (Security Descriptors, Zugriffssteuerungs-Jobs) ist in Sicherheitssystem beschrieben.

4. Shadow-Tabelle (objectXs) — Indexdaten-Historie

Zu jeder objectX-Tabelle existiert eine Shadow-Tabelle objectXs. Sie hält die Indexdaten-Historie: bei jeder durch dms.XMLUpdate (oder vergleichbare Jobs) bewirkten Indexdatenänderung wird der vorherige Zustand der typspezifischen Indexfelder in objectXs historisiert, sofern das Flag objectX.indexhistflags aktiviert ist.

Struktur:

  • Erste Spalte (immer): osguid (nvarchar(32)) — GUID des Snapshots. Identifiziert eine konkrete Historieversion. Der Job dms.RestoreIndexdataVersion referenziert Versionen über diese GUID.

  • Danach: alle typspezifischen Indexfelder der zugehörigen objectX-Tabelle (z. B. feld1, zahl1, datum1, …) — mit identischen Datentypen und Längen.

  • Die 35 gemeinsamen Systemfelder aus objectX (id, zeitstempel, …) sind in objectXs nicht enthalten — Shadow-Tabellen historisieren ausschließlich Indexdaten, nicht Systemfelder.

Querverweise:

5. Tabellenfelder (objectXlistY, objectXlistYs)

Tabellenfelder (Grid-Felder) auf einem Objekttyp X werden in eigenen Tabellen objectXlistY gespeichert. Y ist die laufende Nummer des Tabellenfelds in der Objektdefinition (list1, list2, list3, …); jedes Tabellenfeld bekommt eine eigene objectXlistY-Tabelle. Pro Zeile des Grids existiert ein Datensatz.

Gemeinsame Spalten aller objectXlistY-Tabellen:

Name Typ Länge Beschreibung

id

int

Verweis auf objectX.id — bindet alle Grid-Zeilen an ein konkretes Hauptobjekt.

line

int

Zeilennummer im Grid (1-basiert, fortlaufend).

Danach folgen die typspezifischen Spalten des jeweiligen Tabellenfelds (z. B. feld1, feld2, datum1, …) — analog zu den Indexfeldern auf der Hauptobjekttabelle.

Zu jedem Tabellenfeld existiert eine Shadow-Variante objectXlistYs mit der Indexdaten-Historie. Gemeinsame Spalten: osguid (Snapshot-Identifikator) und line; danach die typspezifischen Spalten.

6. Verwandte Server-API-Jobs