SQLite Data Studio: How-to

Zurück: SQLite Data Studio

Kurzrezepte für das, was immer wiederkehrt: eine Routine anlegen, ein Routine-Set aus einem anderen Plugin anmelden, die Abfrage-Historie nutzen, ein Skript zu einem Objekt erzeugen.

[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 „Test ausführen“ unterhalb des Editors – Verbindung wählen, Parameter ausfüllen, „Test 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: im Objekt-Explorer Menü „Aktionen“ der Verbindung → „Abfrage-Historie“ (oder direkt per URL-Parameter historyopen=1). Die Historie öffnet sich als Drawer über der Query-Workbench.
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, Tabelle oder Ansicht im Objekt-Explorer sichtbar.

1. Im Objekt-Explorer das Menü „Aktionen“ des Tabellen- oder Ansichtsknotens öffnen.
2. „CREATE-Statement“ (Tabellen und Ansichten) liefert das vollständige, aus dem Live-Katalog rekonstruierte CREATE-Statement; „Script as DROP“ (nur Tabellen) das passende DROP-Statement. Indizes haben diese Aktionen nicht.
3. Das Statement öffnet sich in einem neuen Abfrage-Reiter der Query-Workbench – es wird nichts automatisch ausgeführt, das Skript ist reiner Text zur Weiterverwendung (z. B. als Migrationsvorlage).

Hinweis: bei SQLite entspricht „CREATE-Statement“ 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