Datenbank

Unter Administration > Datenbank (/v2/admin/database) liegt der Datenbank-Manager: Tabellen ansehen, Daten korrigieren und SQL ausführen.

Nur für Superadministratoren

Die Seite ist ausschließlich dem versteckten Superadministrator zugänglich. Sie umgeht jede fachliche Prüfung — Statusregeln, Pflichtfelder und Berechnungen greifen hier nicht. Wer Daten über diese Seite ändert, verantwortet die Konsistenz selbst.

Vorher sichern

Direkte Datenänderungen können die Anwendung beschädigen. Vor manuellen Eingriffen immer ein Backup erstellen (siehe Datensicherung).

Verbindung wählen

Oben rechts steht die Auswahl der Datenbank. calServer spricht im Betrieb mehrere an:

Verbindung	Inhalt
V2-Datenbank	Die eigene Datenbank von calServer v2 (PostgreSQL, MySQL oder MS SQL Server)
V1-Datenbank (MySQL)	Die Datenbank einer früheren v1-Installation, sofern für die Datenübernahme eingerichtet
MET/TEAM (MS SQL Server)	Die externe MET/TEAM-Datenbank, sofern eingerichtet

Verbindungen, die nicht nutzbar sind, werden mit Begründung eingeblendet statt versteckt — etwa wenn der passende PHP-Treiber im Container fehlt.

Tabellen und Daten

Links stehen alle Tabellen und Views der gewählten Verbindung, mit Suchfeld und Größenangabe. Nach dem Öffnen einer Tabelle:

• Daten — seitenweise, sortierbar, mit Filter je Spalte. ∅ steht für NULL.
• Struktur — Spalten mit Typ, Nullable und Default, dazu Primärschlüssel und Fremdschlüssel.

Zeilen lassen sich über das Stiftsymbol bearbeiten und über den Papierkorb löschen. Gespeichert werden nur tatsächlich geänderte Spalten; die Primärschlüsselfelder sind gesperrt.

Tabellen ohne Primärschlüssel

Ohne Primärschlüssel lässt sich nicht garantieren, dass eine Änderung genau eine Zeile trifft. Solche Tabellen sind hier schreibgeschützt — für diese Fälle bleibt die SQL-Konsole.

Maskierte Spalten

Spalten, die ein Geheimnis enthalten — password, token, secret, api_key und Verwandte —, werden als ******** ausgegeben, im Zeilen-Browser wie im SQL-Ergebnis und im Export. In Schlüssel/Wert-Tabellen wie property gilt das für den Wert, sobald der Schlüsselname auf ein Geheimnis hindeutet (etwa smtp_password).

Maskierte Spalten sind im Bearbeiten-Dialog gesperrt. Andernfalls würde ein Speichern die Maske über das echte Geheimnis schreiben. Ein Passwort lässt sich weiterhin über die SQL-Konsole setzen.

Maskierung ist kein Zugriffsschutz

Die Seite ist ohnehin superadmin-only — wer sie öffnet, käme per SQL an dieselben Werte (SELECT password AS p umgeht die Maskierung). Sie schützt gegen das versehentliche Mitlesen: Screenshare, Screenshot im Support-Ticket, Blick über die Schulter.

Export

Über CSV exportieren und JSON exportieren wird die aktuelle Sicht heruntergeladen — mit denselben Spaltenfiltern und derselben Sortierung wie im Grid. Die Maskierung greift auch hier.

Der Export ist gestreamt und bei DB_MANAGER_MAX_EXPORT_ROWS Zeilen (Vorgabe 50 000) gedeckelt. Wird gekürzt, meldet das die Oberfläche nach dem Download; die Datei selbst enthält keinen Hinweis darauf.

SQL-Konsole

Im Reiter SQL läuft ein Statement pro Ausführung. Standardmäßig nur lesend; für INSERT, UPDATE und DELETE muss der Schreibmodus eingeschaltet werden.

Wie streng „nur lesend" durchgesetzt wird, hängt vom Datenbanksystem ab:

Datenbanksystem	Durchsetzung
PostgreSQL	Die Datenbank selbst weist Schreibzugriffe ab (SET TRANSACTION READ ONLY)
MySQL / MariaDB	Ebenso (SET TRANSACTION READ ONLY)
MS SQL Server	Kein Äquivalent — es greifen die Statement-Prüfung und ein erzwungenes Rollback

Gesperrt sind in jedem Modus Schemaänderungen: CREATE, ALTER, DROP, TRUNCATE sowie GRANT, ATTACH und EXEC. Das ist Absicht — Schema gehört in Migrationen, sonst weicht das Kundenschema ab und die nächste Aktualisierung schlägt fehl. Mehrere durch Semikolon getrennte Anweisungen werden abgelehnt.

Lange Abfragen brechen nach einem Zeitlimit ab, große Ergebnisse werden gekürzt (Hinweis über der Tabelle). Beides ist über DB_MANAGER_STATEMENT_TIMEOUT_MS und DB_MANAGER_MAX_ROWS einstellbar. Zusätzlich sind 30 Ausführungen pro Minute und Benutzer erlaubt.

Verlauf

Rechts neben der Eingabe steht der eigene Verlauf: die zuletzt ausgeführten Anweisungen, per Klick wieder in das Eingabefeld übernehmbar. Fehlgeschlagene Anweisungen stehen ebenfalls darin — meist genau die, die man korrigieren will.

Der Verlauf gehört dem jeweiligen Benutzer, ist auf DB_MANAGER_HISTORY_LIMIT Einträge begrenzt (Vorgabe 50) und lässt sich über Verlauf leeren löschen. Das Systemprotokoll bleibt davon unberührt — die Protokolleinträge zu schreibenden Anweisungen gehören nicht dem Benutzer.

Protokollierung

Jede Änderung — Zeilen-Update, Löschung und jedes schreibende SQL — landet mit Benutzer, Verbindung und Anweisung im Systemprotokoll unter der Kategorie database-manager (siehe Information). Reines Lesen wird nicht protokolliert.

Was der Manager nicht kann

Bewusst nicht enthalten, mit dem jeweils richtigen Weg:

Nicht enthalten	Stattdessen
Tabellen anlegen/ändern/löschen	Migrationen (Software-Aktualisierung)
SQL-Dump importieren	Datensicherung wiederherstellen
Datenbankbenutzer und -rechte	Aufgabe des Datenbankbetriebs
Neue Zeile über Maske anlegen	INSERT in der SQL-Konsole

Adminer

calServer v2 liefert keinen Adminer mehr aus. Wer ihn zusätzlich betreiben will, kann die Umgebungsvariable ADMINER_URL des API-Containers (im Helm-Chart v2.adminerUrl) auf eine eigene, unter derselben Adresse ausgelieferte Instanz zeigen lassen. Nötig ist das nur für die oben genannten Funktionen, die der Manager absichtlich nicht abdeckt.

Backup

Über den Backup-Bereich werden Datenbanksicherungen konfiguriert:

• Automatische Backups nach Zeitplan
• Manuelle Backup-Auslösung
• Backup-Historie einsehen