Diese Seite beschreibt Calíope 1.7, die Version, die ich gerade baue. Die 1.6 ist im App Store für Mac, iPad, iPhone, Apple Watch, Apple TV und Apple Vision Pro. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Speichert die Daten eines Servers, damit du dich schnell verbinden kannst.
Wo es zu finden ist: Seitenleiste › Schaltfläche + (neue Verbindung)
Klick im Verbindungsmanager auf + in der linken Seitenleiste. Gib einen beschreibenden Namen, die Familie des Servers (das Protokoll, das er spricht) und das Produkt darin ein, dann Host, Port, Benutzer und Passwort. Das Feld "Standarddatenbank" ist optional.
Die Zeile Umgebung gibt dem Profil eines deiner Umgebungsetiketten —standardmäßig Keine—, und Umgebungsetiketten … öffnet den Katalog, in dem du sie anlegst.
Im Abschnitt Serveroptionen kannst du den Zeichensatz und die Kollation festlegen sowie SSL/TLS aktivieren. Ist SSL aktiv, erscheinen Felder zur Auswahl des Zertifikats und des Client-Schlüssels.
ClickHouse
Mit ClickHouse hat der Abschnitt weder Zeichensatz noch Kollation, weder Client-Zertifikat noch -Schlüssel, und SSL/TLS anzuhaken setzt den Port von 8123 auf 8443, wenn es der Standard war, und beim Abhaken wieder zurück.
Oracle
Mit Oracle Database heißt das Datenbankfeld Dienst und fragt nach dem Dienstnamen (SERVICE_NAME, FREEPDB1 bei einer Free-Installation), nicht nach einer SID. Der Abschnitt hat weder Zeichensatz noch Kollation, weder Client-Zertifikat noch -Schlüssel, und SSL/TLS anzuhaken setzt den Port von 1521 auf 2484, wenn es der Standard war, und beim Abhaken wieder zurück.
MySQLMariaDBAurora
Wie es sich anmeldet. Calíope beherrscht die fünf Verfahren von MySQL und MariaDB: caching_sha2_password (Standard seit MySQL 8), mysql_native_password, client_ed25519 und parsec von MariaDB sowie mysql_clear_password, das das Passwort im Klartext schickt und deshalb nur bei eingeschaltetem SSL/TLS verwendet wird: ohne es schickt Calíope das Passwort nicht und sagt das. Dieses Verfahren verlangen PAM, LDAP und die IAM-Authentifizierung von Aurora. Welches Verfahren gilt, legt das Konto auf dem Server fest, nicht das Profil.
PostgreSQL
Wie es sich anmeldet. Calíope beherrscht die drei Verfahren von PostgreSQL mit Passwort: SCRAM-SHA-256 (Standard seit PostgreSQL 14), md5 und das Klartext-Passwort (password in pg_hba.conf), das nur bei eingeschaltetem SSL/TLS gesendet wird: ohne es schickt Calíope das Passwort nicht und sagt das. Dieses Verfahren verlangen LDAP, PAM, RADIUS und die IAM-Authentifizierung von RDS und Aurora. Kerberos (GSSAPI) und SSPI gibt es nicht: Bei einem Server, der nur diese zulässt, schlägt die Verbindung mit dem Hinweis fehl, dass Calíope dieses Verfahren nicht beherrscht.
Stichwörter: Profil, neue Verbindung, Server speichern, Host, konfigurieren, Authentifizierung, caching_sha2_password, mysql_native_password, ed25519, parsec, mysql_clear_password, SCRAM-SHA-256, md5, PAM, LDAP, IAM
Wähl das Profil in der Liste der Seitenleiste aus. Das Formular auf der rechten Seite wird mit den aktuellen Daten geladen und du kannst jedes Feld direkt bearbeiten. Es gibt keinen Sichern-Knopf: Jede Änderung wird gespeichert, sobald du sie machst.
Das Löschen eines Profils hat ein eigenes Thema, denn es lässt sich nicht rückgängig machen und nimmt mehr mit, als man denkt: siehe Eine Verbindung löschen.
Stichwörter: Profil bearbeiten, Verbindung ändern, Profil löschen
Die drei Stellen, von denen aus ein Profil gelöscht wird, was mit ihm verschwindet und warum es sich nicht rückgängig machen lässt.
Wo es zu finden ist: Seitenleiste › Taste − (Verbindung löschen)
Eine Verbindung zu löschen entfernt nicht nur ihre Adresse und ihren Benutzernamen: es nimmt alles mit, was Calíope zu diesem Server gespeichert hatte. Deshalb fragt es vorher, und deshalb nennt die Frage den Namen der Verbindung — wenn es nicht die ist, die du meintest, ist das der Moment, es zu merken.
Von wo aus
- macOS: wähl das Profil aus und klick auf − in der Leiste unter der Liste, neben dem +. Oder rechtsklick auf die Zeile und wähl Löschen.
- iPad: wähl das Profil aus und tipp auf − in der unteren Leiste; oder halt die Zeile gedrückt und wähl Löschen; oder wisch die Zeile von rechts nach links. Beim Loslassen wird nichts gelöscht: die Wischgeste zeigt die Taste, und die Frage kommt trotzdem. In die andere Richtung — von links nach rechts — ist es In Gruppe verschieben.
Was mit ihr verschwindet
- Das Profil mit all seinen Daten.
- Sein Passwort aus dem Schlüsselbund, dazu das SSH-Passwort und die Passphrase seines privaten Schlüssels.
- Sein Abfrageverlauf und seine Zeilen im Fehlerprotokoll und im Protokoll der Servermeldungen.
- Das gespeicherte SQL im Editor dieser Verbindung und ihr Schema-Cache.
Das lässt sich nicht rückgängig machen. Es gibt weder Papierkorb noch Widerrufen: die Bestätigung ist die einzige Gelegenheit umzukehren.
Auf deinen anderen Geräten. Mit eingeschalteter iCloud-Synchronisierung reist die Löschung mit, und die Verbindung verschwindet auch dort. Umgekehrt passiert nichts Seltsames: ein Profil, das du auf dem anderen Gerät angelegt hast und das dieses noch nicht gesehen hat, wird nicht als Löschung gelesen und verschwindet also nicht von selbst.
Eine ganze Gruppe. Wer eine Gruppe löscht, löscht auch die Verbindungen darin, mit derselben Frage und derselben Reichweite; das steht in Profile in Gruppen organisieren.
Stichwörter: Verbindung löschen, Profil löschen, Server entfernen, rückgängig, Papierkorb, Passwort, Schlüsselbund, wischen
Wie der alternative Host genutzt wird, wenn die Serveradresse vom Gerät abhängt, mit dem du dich verbindest.
Wo es zu finden ist: Seitenleiste › Verbindungen › Alternativer Host
Das Profilfeld „Alternativer Host“ ist für einen Server gedacht, den man über zwei verschiedene Adressen erreicht. Der typische Fall ist ein Entwicklungsrechner: vom Rechner selbst antwortet er unter 127.0.0.1, vom iPad aus muss dagegen seine Adresse im lokalen Netz verwendet werden. Da Profile zwischen deinen Geräten synchronisiert werden, kann ein einzelnes Host-Feld nicht an beiden Orten richtig sein.
Beim Verbinden wird zuerst der Haupt-Host versucht. Antwortet er nicht, wird der alternative mit demselben Port, demselben Benutzer, demselben Passwort und denselben Optionen versucht: Nur die Adresse ändert sich. Brauchst du auch einen anderen Port, schreib „Adresse:Port“ (zum Beispiel 10.0.0.20:3307).
Kommt die Sitzung über die alternative Adresse zustande, erscheint neben dem Servernamen eine Markierung, und „Verbindung testen“ nennt die Adresse, die geantwortet hat — so weißt du immer, gegen welchen Rechner du arbeitest.
Beim SSH-Tunnel wird das Feld ignoriert, und das ist Absicht: Dort löst der Tunnel-Rechner die Serveradresse auf, nicht dein Gerät, sie ändert sich also nicht danach, von wo aus du dich verbindest.
Stichwörter: alternativer host, zweite adresse, lokale ip, lokales netz, failover, 127.0.0.1, ipad, zwei adressen
Wann du ihn brauchst, welche Felder Calíope dann nicht mehr verwendet und wo das Passwort landet.
Wo es zu finden ist: Seitenleiste › Verbindungen › Verbindungsstring
Das Feld „Verbindungsstring“ erscheint nur, wenn das Modul des Profils MongoDB ist, und es ist optional. Bleibt es leer, baut Calíope die Verbindung aus den Feldern darüber: Adresse, Port, Benutzer, Passwort, TLS und Datenbank. Für einen gewöhnlichen Server reicht das.
Schreib ihn, wenn sich die Verbindung mit diesen Feldern nicht beschreiben lässt. Es gibt drei Fälle: ein Replikatsatz, der mehrere Adressen und den Namen des Satzes braucht; eine andere Authentifizierungsdatenbank als die übliche, die mit authSource angegeben wird; und ein Atlas-Cluster, dessen Adresse mit mongodb+srv:// beginnt und keinen Port zum Eintippen hat. Mit mongodb+srv:// fragt Calíope die Server des Clusters beim DNS deines Systems ab, demselben, das der Rest des Geräts nutzt, VPN eingeschlossen.
Wenn du ihn schreibst, hat Vorrang, was der String sagt: die Adressen, Benutzer, Passwort, ob TLS verwendet wird, und die Optionen. Was er nicht sagt, kommt aus dem Profil: Enthält er weder Benutzer noch Passwort, werden die aus den Feldern verwendet, und nennt er keine Datenbank, die des Profils, sonst admin. Mit mehreren Adressen und replicaSet sucht Calíope das primäre Mitglied und arbeitet mit ihm. Zwei Dinge entscheidet der String nie. Nutzt das Profil einen SSH-Tunnel, kommt die Adresse vom Tunnel und nicht aus dem String, denn der Server, den der String nennt, ist der, den die Tunnelmaschine sieht, nicht dein Gerät. Und die Zertifikate kommen immer aus dem Profil: Der String kann TLS ein- oder ausschalten und verlangen, dass das Zertifikat nicht geprüft wird, aber CA-Zertifikat (.pem) und Client-Zertifikat (.pem) wählst du unter SSL-Zertifikate.
Sagt der String nichts zu authSource, läuft die Authentifizierung gegen admin. Dort liegen die administrativen Konten, und davon gehen auch mongosh und Compass aus, wenn jemand einfach Benutzer und Passwort eintippt; liegen deine in einer anderen Datenbank, gib das mit authSource an.
Manche Optionen nimmt der String an, ohne sie zu verwenden. tlsCAFile und tlsCertificateKeyFile werden ignoriert: Es sind Pfade zu einer Datei, und Calíope öffnet nur Dateien, die du selbst auswählst; das Zertifikat gehört deshalb ins Profil. Lese- und Schreiboptionen wie readPreference, w oder retryWrites werden angenommen, damit ein aus Atlas kopierter String unverändert funktioniert, ändern aber nichts an dem, was Calíope tut.
Ein Hinweis zum Passwort: das aus dem Feld darüber wird im Schlüsselbund gespeichert, ein im String geschriebenes Passwort dagegen nicht. Der String wird mit dem restlichen Profil gespeichert und reist bei aktiver iCloud-Synchronisierung mit ihm. Ist dir das wichtig, lass das Passwort in seinem Feld und nutze den String nur für den Rest.
Ist der String fehlerhaft, schlägt die Verbindung fehl und sagt es: das ist ein Formularfehler und wird dort behoben, nicht durch erneutes Versuchen.
Wo es zu finden ist: Verbindungsmanager › Verbindung testen
Klick im Profilformular auf Verbindung testen. Calíope versucht, mit den eingegebenen Daten eine echte Verbindung aufzubauen, und zeigt das Ergebnis in einem grünen Banner (Erfolg) oder roten Banner (Fehler mit Beschreibung) an.
Der Test ist besonders nützlich, um SSL-Zugangsdaten, Firewalls oder Host-Konfigurationen zu prüfen, bevor du das Profil speicherst.
Stellt die Verbindung her und öffnet den Workspace.
Wo es zu finden ist: Verbindungsmanager › Verbinden
Sobald die Profildaten vollständig sind, klick auf die Schaltfläche Verbinden (mit Blitzsymbol). Calíope öffnet den Verbindungspool mit dem Treiber der Engine und lädt den Schema-Baum.
Schlägt die Verbindung fehl, öffnet sich ein Blatt, das sagt, was passiert ist und was zu prüfen ist. Lösung anzeigen führt, wenn es erscheint, zum Thema dieser Hilfe, das es erklärt, und Technische Details zeigt den Text des Servers oder des Netzwerks unverändert. Das Formular wiederholt ihn in dem Feld, in dem das Ergebnis von Verbindung testen erscheint, als „Verbindungsfehler: …“. Prüf den Host, die Zugangsdaten und ob der Server aktiv und aus deinem Netzwerk erreichbar ist.
Stichwörter: connect, verbinden, Workspace öffnen, Pool
Wechselt die Datenbank der Session über das Schema-Panel.
Wo es zu finden ist: SQL-Editor › Schema-Panel › Als aktive Datenbank verwenden
Klick im Schema-Panel des SQL-Editors mit der rechten Maustaste auf eine Datenbank (auf dem iPad: lange drücken) und wähl Als aktive Datenbank verwenden. Die Session wechselt ohne erneutes Verbinden dorthin — das entspricht dem Ausführen von USE datenbank_name —, und das Servermenü zeigt ihren Namen neben dem des Servers. Der Wechsel betrifft nur die aktuelle Session.
Oracle
Mit Oracle listet der Baum Schemas statt Datenbanken: Ein Schema ist ein Benutzer, und die Datenbank ist der Dienst, mit dem du verbunden bist. Oracle hat kein USE: Das gewählte Schema ist das, in dem der Editor unqualifizierte Namen auflöst, und jede Ausführung setzt es in der Sitzung, wie ALTER SESSION SET CURRENT_SCHEMA. Das Profil ändert sich nicht: Sein Dienst bleibt derselbe.
Stichwörter: use database, Datenbank wechseln, Datenbank auswählen
Trennt die Verbindung zum Server und kehrt zum Verbindungsmanager zurück.
Wo es zu finden ist: Workspace › Trennen
Klick auf die Schaltfläche Trennen in der Kopfzeile des Workspace. Calíope schließt den Verbindungspool und kehrt mit einer Animation zum Bildschirm des Verbindungsmanagers zurück.
Beim Schließen des Hauptfensters der App wird die Verbindung automatisch getrennt.
Verbindet automatisch neu, wenn der Server die Session schließt.
Wo es zu finden ist: Seitenleiste › Profilformular › Automatische Wiederverbindung
Aktivier im Verbindungsprofil-Formular den Schalter Automatische Reconnect. Calíope nutzt ihn, wenn du die aktive Datenbank wechselst (Als aktive Datenbank verwenden im Schema-Bereich): Ist die Verbindung in diesem Moment getrennt —der Server hat sie wegen Inaktivität geschlossen oder wurde neu gestartet, oder der SSH-Tunnel ist abgestürzt—, öffnet Calíope die ganze Sitzung neu, samt Tunnel, und wiederholt den Wechsel.
Abfragen aus dem Editor oder den Werkzeugen werden nicht wiederholt: Die Trennung wird als Verbindungsabbruch angezeigt.
Mit SSH-Tunnel ist es genau dieser Moment, der die Benachrichtigungen über den abgestürzten und wiederhergestellten Tunnel auslöst (siehe Benachrichtigungen zum SSH-Tunnel).
Arbeite gleichzeitig mit mehreren Servern, ohne den Kontext zu verlieren.
Wo es zu finden ist: Workspace › Servermenü
Calíope unterstützt mehrere gleichzeitig aktive Verbindungen zu Servern. Jeder Server hat seine eigene, unabhängige Session mit eigenem Schema-Baum, geöffneten SQL-Tabs, Query-Verlauf und Zustand des KI-Assistenten.
So funktioniert es:
Jedes Mal, wenn du im Verbindungsmanager auf Verbinden klickst, wird eine neue Session geöffnet, ohne die vorherigen zu schließen. Alle Sessions bestehen nebeneinander und du kannst zwischen ihnen wechseln, ohne etwas zu verlieren.
Zustand jeder Session:
- SQL-Tabs und ihr Inhalt bleiben beim Serverwechsel erhalten.
- Der Schema-Baum zeigt die Datenbanken des aktiven Servers.
- Der KI-Assistent behält seinen Gesprächsverlauf pro Session.
Du kannst so viele Sessions öffnen, wie du brauchst, zum Beispiel um Daten zwischen Entwicklungs-, Staging- und Produktionsumgebungen gleichzeitig zu vergleichen.
Stichwörter: Multi-Server, mehrere Verbindungen, gleichzeitig, verschiedene Verbindungen, Sessions, multiserver
Wechselt zwischen verbundenen Servern über das Aufklappmenü des Workspace.
Wo es zu finden ist: Workspace › Servermenü
Das Server-Auswahlmenü zeigt den Namen des aktiven Servers und eine Statusanzeige der Verbindung (grüner Punkt = verbunden, rot = Fehler). Beim Anklicken klappt ein Menü mit allen geöffneten Sessions auf.
Unter macOS: Die Auswahl erscheint in der Werkzeugleiste des Fensters, oben links. Sie zeigt den Servernamen, die aktive Datenbank und den Aufklapp-Pfeil.
Auf dem iPad: Die Auswahl erscheint links von der Tab-Leiste und ist oben im Workspace immer sichtbar.
Auf dem iPhone: Sie steht auch oben in der Liste Werkzeuge, sodass du von jedem Bildschirm des Workspace die Sitzung wechseln, einen Server hinzufügen oder die Verbindung trennen kannst.
Menüoptionen:
- Tipp oder klick auf den Namen eines beliebigen Servers, um diese Session zu aktivieren.
- Die aktive Session ist mit einem ✓ markiert.
- Server hinzufügen öffnet den Verbindungsmanager über dem aktuellen Workspace, um einen weiteren Server zu verbinden, ohne die geöffneten Sessions zu verlieren.
- Trennen schließt die Session des aktiven Servers.
Stichwörter: Servermenü, Auswahl, Server wechseln, switcher, aktive Session, Verbindungsanzeige
Verbindet zu einem zusätzlichen Server, ohne die aktuelle Arbeit zu verlassen.
Wo es zu finden ist: Workspace › Servermenü › Server hinzufügen
So fügst du eine neue Verbindung hinzu, während du bereits an einem anderen Server arbeitest:
1. Öffne das Server-Auswahlmenü (in der Symbolleiste des Fensters unter macOS, in der Tab-Leiste auf dem iPad).
2. Wähl Server hinzufügen.
3. Der Verbindungsmanager öffnet sich: unter macOS in einem eigenen Fenster, auf dem iPad als Blatt.
4. Wähl ein bestehendes Profil aus oder erstell ein neues und klick auf Verbinden.
5. Der Verbindungsmanager schließt sich von selbst und die neue Session steht in der Auswahl bereit.
Die vorherigen Sessions bleiben während des gesamten Vorgangs geöffnet und unverändert.
Stichwörter: Server hinzufügen, neue Session, zweite Verbindung, Server ergänzen, weiteren verbinden
Schließt die Session eines Servers, ohne die anderen aktiven Verbindungen zu beeinträchtigen.
Wo es zu finden ist: Workspace › Trennen
Wenn mehrere Sessions geöffnet sind, kannst du jede einzeln schließen:
Aktiver Server:
- Öffne das Server-Auswahlmenü und klick auf Trennen oder nutz die rote Trennen-Schaltfläche in der Werkzeugleiste.
Beliebige Session (erst wechseln):
1. Öffne das Server-Auswahlmenü.
2. Wähl den Server aus, den du schließen möchtest, um ihn zu aktivieren.
3. Klick auf Trennen.
Beim Schließen einer Session aktiviert Calíope automatisch die zuletzt verfügbare Session. War es die einzige geöffnete Session, kehrt die App zum Verbindungsmanager zurück.
Stichwörter: Server trennen, Session schließen, Verbindung schließen, disconnect, Server entfernen
Verschlüsselt die Verbindung zum Server mit SSL-Zertifikaten.
Wo es zu finden ist: Seitenleiste › Profilformular › SSL
Aktivier im Verbindungsprofil-Formular den Schalter SSL im Abschnitt Serveroptionen. Es erscheinen drei optionale Felder für die Client-Zertifikate:
- CA-Zertifikat — Datei des Zertifikats der Zertifizierungsstelle (.pem oder .crt). Mit dieser Datei überprüft Calíope die Identität des Servers.
- Client-Zertifikat — Datei des Client-Zertifikats für die gegenseitige Authentifizierung.
- Client-Schlüssel — der zum Client-Zertifikat gehörende private Schlüssel.
Aktivierst du SSL, ohne ein CA-Zertifikat anzugeben, überprüft Calíope das Serverzertifikat anhand der Zertifizierungsstellen des Systems (sicheres Standardverhalten). Verwendet der Server ein selbstsigniertes Zertifikat, schlägt die Verbindung fehl, sofern du nicht die passende CA bereitstellst.
Zertifikat ohne Überprüfung akzeptieren (unsicher): Aktivier dieses Kästchen nur, wenn du dich mit einem Entwicklungsserver mit selbstsigniertem Zertifikat verbindest und die CA nicht bereitstellen kannst. Die Verbindung bleibt verschlüsselt, ist aber anfällig für Man-in-the-Middle-Angriffe. Aktivier sie nicht für Produktionsserver.
Wo die Datei liegt: Wenn du ein CA, ein Zertifikat oder einen Client-Schlüssel auswählst — oder außerhalb des Mac einfügst —, behält Calíope eine eigene Kopie auf diesem Gerät, nie in iCloud Drive, und das Profil verweist auf diese Kopie. Das Original kannst du danach verschieben oder löschen, und auf dem Mac wird es auch nach einem Neustart gelesen. Um ein Zertifikat zu erneuern, wähl es erneut aus, auch wenn es gleich heißt. Die Datei bleibt auf dem Gerät, auf dem du sie ausgewählt hast, und ihr Speicherort auch: Ein auf einem anderen Gerät eingerichtetes Profil kommt ohne sie an. Vor dem Verbinden zeigt die Verbindungsliste Dateien auf diesem Gerät auswählen, und das Formular sagt „Dieses Profil verwendet ein Zertifikat, das auf einem anderen Gerät ausgewählt wurde: Wähl es hier aus.“; wähl sie dort aus, und von da an behält dieses Gerät seine eigene Kopie.
Kann eine Datei nicht gelesen werden, verbindet Calíope nicht ohne sie: Es bricht mit „TLS-Datei nicht lesbar“ ab und nennt die Datei und welche der drei es ist.
Die SSL-Verbindung wird beim Klick auf Verbindung testen geprüft; das grüne Banner bestätigt, ob die Verschlüsselung aktiv ist.
ClickHouse
Mit ClickHouse gibt es nur CA-Zertifikat und das Kästchen, ein ungeprüftes Zertifikat zu akzeptieren: ClickHouse meldet sich mit Benutzer und Passwort an, deshalb zeichnet das Formular weder Client-Zertifikat noch Client-Schlüssel, und ein Profil, das sie enthält, verbindet sich erst, wenn sie entfernt sind. SSL einzuschalten setzt den Port von 8123 auf 8443, wenn es der Standard war. Über einen SSH-Tunnel wird das Zertifikat gegen den Host des Profils geprüft.
Oracle
Mit Oracle gibt es nur CA-Zertifikat und das Kästchen, ein ungeprüftes Zertifikat zu akzeptieren: Oracle meldet sich mit Benutzer und Passwort über einseitiges TLS (TCPS) an, deshalb zeichnet das Formular weder Client-Zertifikat noch Client-Schlüssel. SSL einzuschalten setzt den Port von 1521 auf 2484, wenn es der Standard war: Der Listener bedient TCPS auf einem anderen Port. Das Zertifikat wird gegen den Host des Profils geprüft, auch über einen SSH-Tunnel und auch mit eigener CA: Der Name des Servers muss im Zertifikat stehen. Enthält ein Profil ein Client-Zertifikat oder einen Client-Schlüssel —importiert oder von einer anderen Familie übernommen—, wird die Verbindung nicht geöffnet, und der Fehler sagt es: Entferne sie aus dem Profil.
Erfordert Touch ID, Face ID oder Optic ID, bevor du dich mit irgendeinem Server verbindest.
Wo es zu finden ist: Seitenleiste › Einstellungen › Allgemein › Sicherheit
Calíope kann die Biometrie des Geräts verlangen, bevor eine Verbindung geöffnet wird: Touch ID auf dem Mac und auf den iPads, die es haben, Face ID auf dem iPhone und den übrigen iPads und Optic ID auf Apple Vision Pro. Es ist ein Schalter für die ganze App, keine Einstellung jedes Profils.
Wo du ihn einschaltest
- Einstellungen › Allgemein › Sicherheit › Touch ID zum Verbinden erforderlich (oder Face ID zum Verbinden erforderlich oder Optic ID zum Verbinden erforderlich: der Schalter nennt die Biometrie, die das Gerät hat), auf allen Plattformen gleich. Er erscheint nur, wenn das Gerät Biometrie hat.
Ist er an, fragt Verbinden zuerst, und schlägt die Authentifizierung fehl, kommt die Verbindung nicht zustande. Ein Profil zu testen fragt nicht. Prüf die Berechtigungen unter Systemeinstellungen › Touch ID & Passwort (Mac), Einstellungen › Face ID & Code oder Einstellungen › Touch ID & Code (iPad und iPhone) oder Einstellungen › Optic ID & Code (Apple Vision Pro).
So gruppierst du deine Verbindungen (Produktion, Entwicklung, Kunde X usw.) und verschiebst Profile zwischen Gruppen unter macOS, iPad, iPhone und Apple Vision Pro.
Wo es zu finden ist: Verbindungsmanager › Rechtsklick › In Gruppe verschieben
Wenn die Verbindungsliste wächst, kannst du sie nach Umgebung, Kunde oder einem beliebigen anderen Kriterium gruppieren. Gruppen sind einklappbar und werden in connections.json als sortierbare Sammlungen gespeichert.
Eine Gruppe erstellen
- macOS: Rechtsklick auf eine beliebige bestehende Gruppe (oder auf die Kopfzeile der Seitenleiste) und wähl Neue Gruppe. Sie wird mit dem Standardnamen Neue Gruppe erstellt und geht direkt in den Bearbeitungsmodus, damit du sie umbenennen kannst.
- iPad, iPhone und Apple Vision Pro: Tipp im Verbindungsmanager auf Gruppen verwalten (der Ordner mit Zahnrad in der unteren Leiste) und im Blatt auf Neue Gruppe.
Umbenennen / löschen
- macOS: Rechtsklick auf den Gruppennamen → Gruppe umbenennen oder Gruppe löschen.
- iPad: Zum Umbenennen tipp auf den Stift in der Zeile im Blatt Gruppen verwalten; zum Löschen wisch diese Zeile von rechts nach links. Du kannst auch den Gruppenkopf in der Liste gedrückt halten.
- Beim Löschen einer Gruppe werden auch die Verbindungen darin gelöscht, samt gespeichertem Passwort, Abfrageverlauf und dem darin gespeicherten SQL. Bevor etwas gelöscht wird, fragt Calíope nach und nennt dir, wie viele Verbindungen gehen und wie sie heißen. Das lässt sich nicht rückgängig machen: Wenn du nur die Gruppierung auflösen willst, hol die Profile vorher mit In Gruppe verschieben ▸ Ohne Gruppe heraus.
Ein Profil verschieben
- macOS: Rechtsklick auf das Profil → In Gruppe verschieben ▸ → wähl die Zielgruppe oder Ohne Gruppe, um es aus jeder Gruppierung herauszunehmen.
- iPad: Wisch das Profil von links nach rechts, um die Aktion Verschieben (Ordnersymbol, indigofarben) einzublenden; das Blatt zur Gruppenauswahl öffnet sich.
Gruppen neu anordnen (iPad)
- Öffne Gruppen verwalten und zieh am Griff ☰, um sie neu anzuordnen. Die Reihenfolge wird im Feld sortOrder jeder Gruppe gespeichert.
Ein-/ausklappen
- Jede Gruppe hat ein ▸ zum Ein-/Ausklappen der Profilliste. Der Zustand wird pro Gruppe gespeichert.
Persistenz
- Die Gruppen und ihre Zuordnung liegen in der Datei connections.json auf dem aktuellen Gerät. Ist die iCloud-Synchronisierung aktiviert, werden sie zwischen deinen Geräten geteilt.
Filtern
- Das Feld über der Liste lässt nur die passenden Verbindungen stehen; solange Text darin steht, werden alle Gruppen offen gezeichnet, ohne das Gespeicherte zu ändern (siehe Die Verbindungsliste filtern).
Stichwörter: Gruppe, Gruppen, organisieren, Ordner, Kategorie, Produktion, Entwicklung, Profil verschieben, ziehen, swipe, neue Gruppe, umbenennen, Gruppe löschen, ohne Gruppe, connections.json
Markiere jede Verbindung als lokal, Staging, Produktion oder was du brauchst, mit dem Namen und der Farbe deiner Wahl, und sieh sie als Band über jedem Werkzeug.
Wo es zu finden ist: Verbindungsmanager › Rechtsklick › Umgebungsetiketten …
Ein Umgebungsetikett sagt, wohin eine Verbindung zeigt — lokal, Staging, Produktion oder was du festlegst — mit einem Namen und einer Farbe, die du wählst. Nach dem Verbinden erscheint das Etikett als Band in seiner Farbe über dem Werkzeug, in allen Werkzeugen, und im Servermenü: Bevor du etwas ausführst, siehst du, auf welchem Server du bist.
Der Katalog
- Die Etiketten liegen in einem einzigen Katalog, Umgebungsetiketten. Du öffnest ihn mit dem Button Umgebungsetiketten … im Profilformular, neben Umgebung, oder über das Kontextmenü der Kopfzeile Ohne Gruppe oder einer beliebigen Gruppe: Rechtsklick auf macOS, gedrückt halten auf iPad, iPhone und Apple Vision Pro.
- Der Katalog ist anfangs leer. Neues Etikett öffnet das Formular, und Beginnen mit bietet drei Vorlagen mit einem Tippen: Lokal (grün, kein Schutz), Staging (bernsteinfarben, bestätigt Schreibzugriffe) und Produktion (rot, bestätigt Schreibzugriffe). Danach änderst du, was du willst: Name des Etiketts, Farbe und Schutz.
- Zieh die Zeilen, um die Reihenfolge in der Auswahl zu ändern; auf iPad, iPhone und Apple Vision Pro tippst du vorher auf Bearbeiten.
- Etikett löschen fragt vorher und sagt, wie viele Verbindungen es verwenden. Diese Verbindungen bleiben ohne Etikett; sie werden nicht gelöscht.
Einem Profil ein Etikett geben
- Im Profilformular bietet die Auswahl Umgebung die Option Keine und die Etiketten des Katalogs. Die Verbindungslisten im Verbindungsmanager und in den Einstellungen zeigen vor dem Namen ein Farbmuster.
Die Stufe gehört zum Etikett, nicht zum Profil
- Jedes Etikett hat eine Stufe für Schutz: kein Schutz, bestätigt Schreibzugriffe oder schreibgeschützt. Zwanzig Verbindungen mit „Produktion“ übernehmen davon Namen, Farbe und Stufe; das Etikett zu ändern ändert alle zwanzig. Braucht eine Verbindung eine andere Stufe, leg ein anderes Etikett an. Was jede Stufe tut, steht im Thema „Schutzstufen“.
- Die Gruppe erbt nichts: Gruppe und Etikett sind unabhängig. In der Gruppe „Kunde X“ kann es eine Verbindung „Lokal“, eine „Staging“ und eine „Produktion“ geben.
Wo es gespeichert wird
- Der Katalog wird in connections.json gespeichert, zusammen mit den Gruppen und Profilen: Er reist mit ihnen über iCloud Drive, wenn die Synchronisierung aktiv ist, und der Export unter Einstellungen › Verbindungen enthält ihn.
Was die Schutzstufe jedes Umgebungsetiketts bewirkt: keine, Schreibendes bestätigen oder schreibgeschützt.
Wo es zu finden ist: Verbindungsmanager › Rechtsklick › Umgebungsetiketten …
Jedes Umgebungsetikett trägt eine Schutz-Stufe, die du in seinem Formular unter Umgebungsetiketten wählst. Die Stufe gehört zum Etikett: Alle Verbindungen, die es tragen, teilen sie.
Die drei Stufen
- Kein Schutz: Anweisungen laufen wie gewohnt; das Etikett markiert die Verbindung nur mit seinem Band.
- Bestätigt Schreibzugriffe: Bevor etwas Schreibendes läuft, fragt Calíope „In … schreiben?“, mit der Quelle und der Zahl der Anweisungen, und macht nur weiter, wenn du In … ausführen mit dem Namen des Etiketts tippst. Es fragt einmal pro Ausführung: Ein Skript mit zwanzig Anweisungen ist eine einzige Frage. Was schon eine eigene Bestätigung hatte – das ganze Skript ausführen, wiederherstellen, ein Objekt in Kataloge löschen, einen Prozess beenden, einen Benutzer löschen –, trägt den Namen des Etiketts im Titel und fragt nicht zweimal. Ist ein Blatt offen, erscheint die Frage darüber. Abbrechen im SQL-Editor lässt die Abfrage angehalten; anderswo sagt ein Hinweis, dass sie nicht ausgeführt wurde, weil du abgebrochen hast, und er landet nicht im Fehlerprotokoll.
- Schreibgeschützt: Was schreibt, wird nicht an den Server geschickt, und der Fehler nennt das Etikett. Außerdem werden die Werkzeuge, die nur schreiben – Tabellen-Builder, Benutzerverwaltung, Tabellenwartung und Datenmigration –, nicht angeboten, und in den übrigen wird nicht gezeichnet, was schreibt: wiederherstellen, ersetzen, importieren, befüllen, Objekte anlegen und löschen, Prozesse beenden, Zeilen eines Ergebnisses bearbeiten und löschen.
Was als Schreiben zählt
- Alles, was weder ein Lesen noch eine Transaktionssteuerung ist. Eine Transaktion öffnen, bestätigen oder zurücksetzen und die Datenbank wechseln (USE) schreiben nicht. SET schon, ebenso eine Transaktionssteuerung, die READ WRITE verlangt: Damit würde eine Sitzung den Schreibschutz des Servers aufheben. Ein BEGIN … END-Block zählt als Schreiben.
- Die Prüfung liest den Text, nicht das, was der Server tun wird: Ein SELECT, das eine Funktion mit Nebenwirkungen aufruft, etwa SELECT nextval('s'), geht als Lesen durch.
- Eine Zellenbearbeitung rückgängig machen oder wiederholen sind neue Schreibzugriffe, und mit „bestätigt Schreibzugriffe“ fragen sie jedes Mal.
Wo es greift
- Der SQL-Editor – Ausführen, das Terminal und der SQL Player – und was der KI-Assistent im Editor ablegt, gehen durch dieselbe Prüfung. Der Assistent kennt außerdem die Stufe des Etiketts und berücksichtigt sie bei seinen Vorschlägen.
- Der Safe Mode des SQL-Editors kommt zuerst und ändert sich nicht: Was er blockiert, erreicht die Frage nie.
- Siri und Kurzbefehle können die Frage nicht zeigen: Mit einem Etikett, das Schreibzugriffe bestätigt, wird ein Schreibzugriff über Siri nicht ausgeführt, mit einem schreibgeschützten schlägt er fehl. Der MCP-Server war schon immer schreibgeschützt.
- Eine im Editor verknüpfte Datenbank und das Ziel der Datenmigration schützt das Etikett ihres eigenen Profils.
- Berichte lesen nur. Auf einer schreibgeschützten Verbindung kann ein Bericht seine temporären Tabellen anlegen; mehr nicht.
- Ein SQL-Alarm, dessen Regel schreibt, läuft mit einem schützenden Etikett nicht, auf keiner der beiden Stufen.
Die Serverschicht
Bei schreibgeschützt bittet Calíope dort, wo sich die Engine pro Sitzung schreibschützen kann, auch den Server darum: Was der Prüfung entgeht, lehnt der Server ab.
MySQLMariaDBAurora
Jede Verbindung arbeitet mit SET SESSION TRANSACTION READ ONLY. Der Server lehnt mit Fehler 1792 INSERT, UPDATE, DELETE, CREATE und DROP ab – auch für eine temporäre Tabelle – sowie SELECT … FOR UPDATE. Er lässt SET GLOBAL, KILL und FLUSH durch, die Calíopes Prüfung schon vorher ablehnt, und ANALYZE TABLE, das auch Calíope nicht ablehnt, weil es keine Zeilen ändert.
PostgreSQL
Jede Verbindung startet mit default_transaction_read_only = on. Der Server lehnt mit Fehler 25006 ab, was schreibt, auch eine temporäre Tabelle, SELECT nextval(…) und SELECT … FOR UPDATE: Hier wird die Funktion mit Nebenwirkungen gestoppt, die die Prüfung durchlässt. Er lässt ALTER SYSTEM durch, das Calíope vorher ablehnt, und SELECT pg_terminate_backend(…), das keiner von beiden ablehnt. Ein SET default_transaction_read_only = off würde die Schicht abschalten: Deshalb lehnt Calíope SET ab.
ClickHouse
Jede Anfrage trägt readonly=2. Der Server lehnt mit Code 164 INSERT, Mutationen (ALTER TABLE … UPDATE), CREATE, DROP, TRUNCATE, OPTIMIZE und SYSTEM FLUSH LOGS ab. Er lässt SET, die SETTINGS-Klausel, KILL QUERY – Anhalten funktioniert weiter – und die temporären Tabellen eines Stapels durch. SET readonly = 0 kann ihn nicht abschalten.
SQL Server
Keine Serverschicht: T-SQL hat keinen Schreibschutz pro Sitzung, und ApplicationIntent=ReadOnly leitet nur zu einem lesbaren Replikat einer Verfügbarkeitsgruppe; gegen einen einzelnen Server verhindert es nichts. Es schützt Calíopes Prüfung.
Oracle
Keine Serverschicht: SET TRANSACTION READ ONLY gilt für eine Transaktion und endet beim nächsten COMMIT oder ROLLBACK; eine Entsprechung pro Sitzung gibt es nicht. Es schützt Calíopes Prüfung.
Redis
Keine Serverschicht: Redis hat keinen Schreibschutz pro Verbindung (READONLY ist etwas anderes: Es erlaubt das Lesen von einem Replikat eines Clusters). In der Konsole fragt Calíope den Server, was schreibt, und Administratives, das der Server nicht markiert – CONFIG SET, CLIENT KILL … –, zählt trotzdem als Schreiben. Die Einzelheiten stehen im Thema „Die Befehlskonsole“.
MongoDB
Keine Serverschicht: MongoDB hat keinen Schreibschutz pro Verbindung; es gibt die Rollen des Kontos (read). Ein Befehl in MongoDB-Befehle wird anhand einer Liste der lesenden beurteilt, und eine Aggregation mit $out oder $merge schreibt. Die Einzelheiten stehen im Thema „Befehle an den Server senden“.
Was es nicht ist
Es ist ein Schutz vor Versehen, keine Sicherheit. Sicherheit ist ein schreibgeschützter Benutzer auf dem Server.
Tipp ins Feld über der Liste, um nur die passenden Verbindungen zu behalten — nach Name, Host oder Gruppe.
Bei dreißig oder vierzig Profilen reicht das Ausklappen einer Gruppe nicht mehr. Das Feld oben in der Seitenleiste lässt nur die Verbindungen stehen, die zu deiner Eingabe passen.
Wonach gesucht wird: Name des Profils, Host und alternativer Host, Standarddatenbank, Benutzername, Name der Engine und Name seiner Gruppe. Wer den Namen einer Gruppe tippt, sieht sie also vollständig — so sagt man zeig mir Produktion. Akzente und Groß-/Kleinschreibung spielen keine Rolle.
Beim Filtern öffnen sich die Gruppen von selbst, auch die eingeklappten, damit nichts Passendes in einer geschlossenen Gruppe versteckt bleibt. Dieses Öffnen wird nicht gespeichert: leer das Feld, und jede Gruppe ist wieder genau so, wie du sie verlassen hast.
Die Auswahl bleibt stehen. Fällt das Profil, das du gerade bearbeitest, aus dem Filter, zeigt das Formular rechts es weiterhin an: zu verlieren, was du bearbeitest, weil du in ein Suchfeld getippt hast, wäre schlimmer als das Problem, das die Suche löst.
Mit Esc oder dem × leerst du das Feld. Der Filter wird beim Beenden der App nicht gemerkt.
Stichwörter: filtern, suchen, Verbindungen, Liste, Gruppe, Host, Profil finden
Was eine Familie ist, was ein Produkt ist, und wie Calíope beim Testen der Verbindung das Produkt vorschlägt, als das sich der Server meldet.
Wo es zu finden ist: Seitenleiste › Verbindungsmanager
Calíope gruppiert Server nach Familie, also nach dem Protokoll, das sie sprechen: MySQL / MariaDB, PostgreSQL, SQL Server, Oracle Database, ClickHouse, MongoDB und Redis. Innerhalb jeder Familie wählst du das Produkt: den konkreten Namen dessen, was vor dir steht.
Familien und Produkte
- MySQL / MariaDB: MySQL, MariaDB, Amazon Aurora MySQL und „Anderer MySQL-kompatibler Server“.
- PostgreSQL: PostgreSQL, Amazon Aurora PostgreSQL und „Anderer PostgreSQL-kompatibler Server“.
- SQL Server: Microsoft SQL Server.
- Oracle Database: Oracle Database.
- ClickHouse: ClickHouse.
- MongoDB: MongoDB und „Anderer MongoDB-kompatibler Server“.
- Redis: Redis.
Was jedes entscheidet. Die Familie entscheidet, mit welcher Engine sich Calíope verbindet und welche Werkzeuge angeboten werden. Das Produkt bestimmt den Namen, den Prompt des Terminals und die vorgegebenen Fragmente; Aurora MySQL etwa bringt eigene mit. Ein Produkt, das nicht die Referenz seiner Familie ist, zeigt im Formular einen Hinweis als Erinnerung; du kannst ihn mit Nicht mehr anzeigen ausblenden.
Profil anlegen
1. Wähle unter Server (Typ auf iPad und iPhone) die Familie.
2. Wähle unter Produkt – auf dem Mac das Menü daneben – das Produkt. Fehlt deines, wähle „Anderer … kompatibler Server“. Eine Familie mit nur einem Produkt – SQL Server, Oracle Database, ClickHouse, Redis – zeigt kein Menü Produkt.
3. Trage Host, Port, Benutzer und Passwort wie gewohnt ein. Bei Aurora fügst du den Endpoint des Clusters ein und aktivierst SSL/TLS.
Der Server sagt, wer er ist. Wenn du Verbindung testen drückst oder die Datenbankliste lädst, fragt Calíope den Server, und wenn er sich als anderes Produkt derselben Familie meldet, schlägt Calíope es unter der Auswahl vor: Drücke … verwenden, um das Profil zu korrigieren, oder ignoriere es. Es ändert nie etwas von allein. MongoDB wird nicht gefragt.
Hinweis
Produktspezifische Funktionen (IAM-Authentifizierung von Aurora, getrennte Endpoints, aurora_%-Metriken) werden nicht gesondert behandelt: Calíope behandelt den Server als Standardmitglied seiner Familie. Ein IAM-Token kommt deshalb hinein wie bei MySQL 8 oder PostgreSQL: als Klartext-Passwort, das Calíope nur bei eingeschaltetem SSL/TLS schickt. Das Token erzeugt, wer sich verbindet, nicht Calíope.
SQL Server verbindet sich mit Version 2022 oder neuer, immer verschlüsselt. Ein SQL-Server-Profil, das auf ein Gerät mit Calíope 1.4 synchronisiert wird, erscheint dort als MariaDB, weil diese Version die Familie nicht kennt; es dort zu öffnen, funktioniert erst, wenn das Gerät aktualisiert ist.
ClickHouse verbindet sich mit Version 25.3 oder neuer über seine HTTP-Schnittstelle —Port 8123, oder 8443 mit TLS—, auch über einen SSH-Tunnel. Ein ClickHouse-Profil, das auf ein Gerät mit einer älteren Calíope-Version synchronisiert wird, erscheint dort als MariaDB; sobald das Gerät aktualisiert ist, holst du es zurück, indem du im Profil wieder ClickHouse wählst.
Redis nummeriert seine Datenbanken, statt sie zu benennen: Das Formular fragt daher nach einer Datenbanknummer – 0 bis 15, sofern der Server nicht mit mehr konfiguriert ist – und hat weder Kodierung noch Sortierung. Der Benutzer ist optional: Das Passwort allein genügt zur Anmeldung, der Benutzer ist nur bei ACL-Benutzern nötig (Redis 6 oder neuer).
Oracle Database verbindet sich mit einem Dienst, nicht mit einer Datenbank: Das Formular fragt nach dem Dienst – dem SERVICE_NAME, FREEPDB1 bei einer Free-Installation – auf Port 1521, oder 2484 mit SSL/TLS. Eine SID genügt nicht; trage den Dienstnamen ein. Um ihn zu finden, listet lsnrctl status auf dem Server die Dienste, auf die er hört. Calíope wird gegen Oracle AI Database 26ai gemessen, die Free-Version, die Docker ohne Konto herunterlädt; 19c und 23ai sprechen dasselbe Protokoll, sind aber nicht gemessen. Angemeldet wird mit Benutzer und Passwort, auch über einseitiges TLS; Token-Authentifizierung (OCI IAM, OAuth), Kerberos, die des Betriebssystems und das Wallet mit Client-Zertifikat gibt es nicht –mit Autonomous meldest du dich über TLS ohne Wallet an–. Ein Oracle-Profil, das mit einem Gerät mit einer früheren Calíope-Version synchronisiert wird, erscheint dort als MariaDB; sobald dieses Gerät aktualisiert ist, stellst du es wieder her, indem du im Profil erneut Oracle Database wählst.
Klonen kopiert das gewählte Profil vollständig mit seinem Passwort und lässt den Klon ausgewählt, damit du das Nötige änderst.
Klonen kopiert das gewählte Profil vollständig —Felder, Gruppe, Umgebungsetikett sowie die auf diesem Gerät gewählten TLS-Dateien und den SSH-Schlüssel— und sein Passwort. Der Klon heißt wie das Original mit „Kopie von“ davor, beginnt mit dem Nutzungszähler bei null und bleibt ausgewählt, damit du das Nötige änderst.
Du findest es in der Leiste der Verbindungsliste, im Kontextmenü jeder Zeile und, außerhalb des Mac, durch Wischen über die Zeile.
Stichwörter: klonen, kopieren, duplizieren, Profil, Verbindung
Die Liste der Datenbanken, Zeichensätze und Kollationen laden
Server-Daten laden fragt den Server nach seinen Datenbanken, Zeichensätzen und Kollationen, damit du sie aus einer Liste wählst, statt sie zu tippen.
Die Schaltfläche mit dem Kreispfeil neben Datenbank und Zeichensatz, Server-Daten laden, fragt den Server nach seinen Datenbanken, Zeichensätzen und Kollationen, damit du sie aus einer Liste wählst, statt sie zu tippen. Sie ist deaktiviert, solange Host oder Benutzer fehlen.
Gibt es die Standarddatenbank des Profils auf dem Server nicht, weist das Formular darauf hin. Zeichensatz und Kollation erscheinen nur bei Engines, die sie beim Verbinden nutzen: nicht bei ClickHouse, Oracle oder Redis. Läuft das Profil über einen SSH-Tunnel, wird der Schlüssel des Bastions wie beim Verbinden abgefragt.
Calíope meldet, wenn der SSH-Tunnel abstürzt und wenn er sich automatisch wiederherstellt.
Wo es zu finden ist: Calíope › Einstellungen › Allgemein → Benachrichtigungen
Wenn ein Profil SSH-Tunnel und Automatische Reconnect aktiviert hat, sendet Calíope lokale Benachrichtigungen zu zwei Zeitpunkten:
- Absturz des Tunnels — wenn Calíope die Verbindung getrennt vorfindet, bevor eine Wiederverbindung versucht wird.
- Erfolgreiche Wiederverbindung — wenn die Wiederverbindung den Tunnel wiederherstellt.
Beide kommen aus der automatischen Wiederverbindung, und Calíope versucht sie, wenn du die aktive Datenbank wechselst: Eine Abfrage, die den Tunnel abgestürzt vorfindet, meldet sich hier nicht. Ohne Automatische Reconnect wird keine gesendet.
Aktivieren oder deaktivieren:
Geh zu Einstellungen › Allgemein › Benachrichtigungen und verwende den Schalter SSH-Tunnel abgestürzt / wiederhergestellt.
Wenn die Wiederverbindung fehlschlägt, wird keine Benachrichtigung über die Wiederverbindung gesendet; der Absturz wurde bereits gemeldet. Der Mindestabstand zwischen Benachrichtigungen desselben Hosts beträgt 60 s.