# Geschützte Datenbanken

Am Tabellenaufbau von drei Datenbanken ändert dieser Editor nichts. Sie stehen in
keinem Dialog zur Wahl, der anlegt oder ändert, und das Portalskript weist eine Anfrage
auch dann ab, wenn sie doch einmal darauf zeigt.

| Datenbank | Warum |
|---|---|
| **Workflow** (`Dex_Workflow`) | In ihr liegt der Zustand jedes laufenden Prozesses, und ihren Aufbau liest und schreibt die Workflow-Engine selbst. Eine Spalte mehr wäre dort keine Tabellenänderung, sondern ein Eingriff in eine laufende Maschine |
| **DOCUMENTS** (`documents5`, `documents6`, `Dex_Documents`) | Seinen Aufbau bestimmt DOCUMENTS. Er kommt aus der Auslieferung, ein Update setzt ihn wieder, und was dazwischen von Hand entstanden ist, fällt heraus |
| **Squeeze** (`Dex_Squeeze`) | Der Aufbau gehört zum Produkt und kommt aus der Auslieferung: eine Spalte, die das nächste Update wieder wegnimmt, hilft niemandem |

**Lesen und ihre Definitionen bearbeiten bleibt bei allen dreien möglich** – nur ihr
Aufbau nicht. Eigene Tabellen gehören in eine eigene Datenbank.

## Was das im Alltag heißt

* In den Dialogen *SQL Tabelle anlegen*, *SQL Tabelle ändern* und
  *Squeeze-Stammdaten in Tabelle laden* stehen diese drei Datenbanken gar nicht erst
  zur Wahl.
* Beim Export des Tabellenaufbaus werden sie nicht angeboten, beim Import bleiben
  Zeilen, die auf sie zeigen, auf *nicht importieren*.
* Ihre **Definitionen** lassen sich dagegen ganz normal öffnen, bearbeiten und
  speichern – der Editor ändert nur nichts an ihrem Tabellenaufbau.

## Wo die Entscheidung fällt

Im **Portalskript**, bei jedem einzelnen Aufruf – nicht in der Seite. Der Editor ist
`clientExecutable`, und ein Schalter aus der Anfrage wäre keine Befugnis, sondern eine
Behauptung. Die Anfrage sagt nur, woher sie kommt.

Was die Oberfläche tut, ist deshalb Anzeige und nicht Sperre: sie bietet erst gar nicht
an, was danach abgewiesen würde. Ein Plan, der erst beim Ausführen scheitert, ist
schlechter als einer, der die Zeile gar nicht erst anbietet.