Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Gesperrte Anwender-Spaces bearbeiten

Eine Utility-Anweisung kann einen Space in einem Zustand zurücklassen, in dem er nicht uneingeschränkt weiter bearbeitet werden kann (siehe Kapitel „Utility-Konzept“).

Welche Utility-Anweisungen in einem bestimmten Zustand eines Anwender-Space ausgeführt werden dürfen und in welchen neuen Zustand der Anwender-Space dadurch jeweils übergeführt wird, ist im Handbuch „ SQL-Sprachbeschreibung Teil 2: Utilities“ ausführlich beschrieben.

  • Spaces im Zustand „copy pending“ erfordern COPY.

  • Spaces im Zustand „load running“ erfordern RECOVER und ggf. anschließend RECOVER INDEX.

  • Spaces im Zustand „recover pending“ erfordern RECOVER.

  • Spaces im Zustand „check pending“ erfordern CHECK CONSTRAINTS. Wenn CHECK CONSTRAINTS Integritätsverletzungen meldet, müssen diese Verletzungen beseitigt werden.

Tabellen im Zustand „check pending“ mit SQL-Anweisungen bearbeiten

Tabellen eines Anwender-Space, der sich im Zustand „check pending“ befindet (siehe Seite "Space-Zustände nach der Ausführung von Utility-Anweisungen"), können von den Eigentümern dieser Tabellen mit SQL-Anweisungen zur Datenmanipulation bearbeitet werden. Auf diese Weise lassen sich alle Sätze anpassen oder löschen, die eine Integritätsbedingung verletzen. Voraussetzung ist, dass diese SQL-Anweisungen mit dem Pragma CHECK OFF eingegeben werden. Das Pragma CHECK OFF ist, syntaktisch gesehen, ein gewöhnlicher SQL-Kommentar. Es ermöglicht jedoch die Ausführung von SQL-Anweisungen auf Tabellen, für die Integritätsbedingungen verletzt sind. Innerhalb einer SQL-Anweisung wird ein Pragma durch die Zeichenfolge „--%“ eingeleitet und durch Zeilenende abgeschlossen.
Ausführlich beschrieben ist das Pragma CHECK OFF im Handbuch „ SQL-Sprachbeschreibung Teil 2: Utilities“.

Verletzungen von Integritätsbedingungen lassen sich auch beheben, indem die Eigentümer der betroffenen Tabellen die verletzten Integritätsbedingungen mit der SQL-Anweisung ALTER TABLE ... DROP CONSTRAINT löschen.

Nachdem alle Verletzungen von Integritätsbedingungen behoben sind, muss der Datenbankverwalter erneut die Utility-Anweisung CHECK CONSTRAINTS ausführen, um die betroffenen Anwender-Spaces bzw. Tabellen für die berechtigten Personengruppen wieder allgemein verfügbar zu machen.