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.