SQLite Data Studio: How-to

Zurück: SQLite Data Studio

[Live] Kurzrezepte für wiederkehrende Aufgaben. Vollständige Verträge: SQLite Data Studio: Routinen (Routinen-API) und SQLite Data Studio: Admin-Oberfläche (Admin-Oberfläche).

Voraussetzung: mindestens eine konfigurierte Verbindung (SQLite Data Studio: Verbindungen); Fähigkeit design im Studio, oder direkter Dateizugriff auf das Set-Verzeichnis.

1. Im Studio: Bereich „Routinen„ → „Neue Routine“ → Name eingeben ([A-Za-z0-9_-]+).
2. Im geöffneten Routinen-Editor Register „Eigenschaften„: Rückgabetyp wählen, Parameter hinzufügen (Name, Typ, Pflicht-Checkbox), SQL-Datei im unteren Feld eintragen.
3. Speichern. Der Editor validiert Manifest und SQL-Dateien über denselben Validator wie das Register „JSON“ — eine abgelehnte Eingabe wird mit Fehlermeldung und dem exakt eingegebenen Text erneut angezeigt (kein Datenverlust bei einem Tippfehler).
4. Testen: Abschnitt „Routine testen„ unterhalb des Editors — Verbindung wählen, Parameter ausfüllen, „Ausführen“.

Alternativ (Dateisystem): Manifest <name>.json + SQL-Datei direkt im Set-Verzeichnis anlegen (Schema: Routinen → Manifest) — für Routinen, die als Teil eines Plugin-Deployments mitgeliefert werden, statt interaktiv im Studio entstehen.

Häufiger Fehler: „unknown returns„ beim Speichern — returns muss einer der sechs erlaubten Werte sein (rows_affected/insert_id/rows/row/scalar/none); Tippfehler wie row_affected werden abgelehnt, nicht stillschweigend korrigiert.

Voraussetzung: eigenes Plugin mit einem SQL-Verzeichnis für seine Routinen.

1. Event-Hook im action.php des eigenen Plugins registrieren (Details + Code-Beispiel: API-Referenz → Event).
2. Set-Name wählen, der nicht mit einem bereits registrierten kollidiert (default ist reserviert für das Studio-eigene Set).
3. Routinen im eigenen Verzeichnis adressieren als <set>:<name>.

Häufiger Fehler: Set erscheint nicht in setRegistry()→names() — das Event feuert erst beim ersten Zugriff auf die Routinen-Infrastruktur in diesem Request (Lazy Bootstrap); ein zu früh ausgeführter Zugriffs-Code (vor der Hook-Registrierung) sieht das Set noch nicht.

Voraussetzung: Fähigkeit query im Studio, aktive Verbindung.

1. In der Query-Workbench beliebige Abfrage ausführen — jeder Lauf landet automatisch im Ring-Puffer der aktiven Verbindung (nur SQL-Text, Zeitpunkt, Dauer, Zeilenzahl — nie gebundene Werte).
2. Historie öffnen: rechte Modul-Rail → Uhrsymbol, oder direkt per URL-Parameter historyopen=1.
3. Gewünschten Eintrag „In Editor übernehmen“ — SQL-Text landet im Konsolenfeld, ersetzt den aktuellen Entwurf.
4. „Historie löschen„ leert den Ring-Puffer der aktiven Verbindung vollständig (kein Einzeleintrag-Löschen).

Voraussetzung: Fähigkeit query oder design, Objekt (Tabelle/View/Index) im Objekt-Explorer sichtbar.

1. Objekt-Explorer öffnen, Knoten der Tabelle/View/des Index per Kontextmenü anklicken.
2. „Script as CREATE“ liefert das vollständige, aus dem Live-Katalog rekonstruierte CREATE-Statement; „Script as DROP„ (nur Tabellen/Views/Indizes) das passende DROP-Statement.
3. Ergebnis erscheint in einem Formularfeld (kopierbar) — es wird nichts automatisch ausgeführt, das Skript ist reiner Text zur Weiterverwendung (z. B. als Migrationsvorlage).

Hinweis: bei SQLite entspricht „Script as CREATE“ wörtlich dem in sqlite_master gespeicherten Original-Statement (inkl. ursprünglicher Formatierung); bei den übrigen Backends wird das Statement aus den Introspektions-Metadaten neu zusammengesetzt und kann in Details (Whitespace, Klausel-Reihenfolge) vom historischen Original abweichen.

• SQLite Data Studio: Routinen — Manifest-Schema im Detail
• SQLite Data Studio: Admin-Oberfläche — vollständiger Oberflächen-Überblick
• SQLite Data Studio: Berechtigungen — welche Fähigkeit welches Rezept voraussetzt

Verifiziert gegen: wk-dw-sqliteds-plugin@a84984f (2026-07-15).