Fehler und Diagnose

Was in Calíope schiefgegangen ist, wann und auf welchem Gerät.

Wo es zu finden ist: Workspace › Werkzeuge › Fehler

Das Fehlerprotokoll speichert eine Zeile pro Anwendungsfehler, mit Zeitstempel in Weltzeit, dem Gerät, auf dem er auftrat, dem betroffenen Bereich und dem beteiligten Verbindungsprofil, sofern vorhanden.

Es ist nicht das Abfrageprotokoll. Jenes speichert, was der Server auf eine Anweisung antwortet — etwa einen Syntax-ERROR 1064 —, was das normale Ergebnis des SQL-Schreibens ist. Dieses speichert, was der App passiert: eine Verbindung, die nicht zustande kommt, ein Tunnel, der abbricht, ein Backup, das sich nicht schreiben lässt.

Es funktioniert ohne Verbindung, und das ist Absicht: Das Protokoll ist lokal, und man muss es genau dann lesen können, wenn keine Verbindung möglich ist — dann ist es am wichtigsten.

Was nie gespeichert wird: kein Passwort, auch nicht gekürzt. Ein Authentifizierungsfehler hält fest, dass er auftrat und gegen welches Profil, nie mit welchen Anmeldedaten. Der Server wird über den Profil-Alias identifiziert, nicht über Host, Port und Benutzer.

Ein Fehler, der sich von selbst wiederholt, füllt das Protokoll nicht. Die Zustandsüberwachung fragt jeden Server alle paar Sekunden ab; ein ausgeschalteter Server würde über Nacht Tausende identischer Zeilen hinterlassen. Er wird beim ersten Mal festgehalten und erneut, wenn sich das Problem ändert, wenn der Server sich erholt und wieder ausfällt oder wenn es sechs Stunden später unverändert ist. Eine einzige Zeile bedeutet nicht, dass es nur einmal passiert ist.

Doppelklick eine Zeile (oder tipp sie auf dem iPad an), um alle Details zu öffnen — mit dem technischen Text für den Support und einer Taste zum Kopieren. Hat der Fehler eine eigene Erklärung, findest du dort die Taste Lösung anzeigen.

Apple Vision Pro: wie auf dem iPad: Sieh die Zeile an und führe Daumen und Zeigefinger zusammen, um sie zu öffnen.

Stichwörter: Fehler, Protokoll, Diagnose, Ausfälle, Support

Wie die Synchronisierung funktioniert und was das Gerät verlässt.

Wo es zu finden ist: Calíope › Einstellungen › Allgemein

Das Protokoll lässt sich in deine private iCloud spiegeln, sodass ein Fehler vom iPad auch auf dem Mac erscheint. Jede Zeile behält das Gerät, auf dem sie entstand: Ein zusammengeführtes Protokoll, bei dem man nicht weiß, wer welche Zeile schrieb, taugt nicht zur Diagnose.

Der Schalter ist anfangs aus, und das ist kein Versehen. Ein lokales Protokoll ist deine Datei auf deinem Rechner; es hochzuladen bringt die Aliasnamen deiner Profile und das technische Detail jedes Fehlers vom Gerät weg. Danach wird gefragt, das wird nicht vorausgesetzt. Er liegt unter Einstellungen › Allgemein, getrennt vom Schalter für die Aufzeichnung: Der eine entscheidet, ob gespeichert wird, der andere, ob es das Gerät verlässt.

Warum es nicht mit den übrigen Einstellungen reist. Einstellungen laufen über einen kleinen iCloud-Speicher mit einem Megabyte Obergrenze für alles zusammen; ist er voll, hört alles auf zu synchronisieren, nicht nur das, was ihn gefüllt hat. Ein Fehlerprotokoll wächst mit der Nutzung, es nimmt daher einen anderen Kanal — CloudKit, Datensatz für Datensatz —, wodurch Mac, iPad und iPhone zugleich schreiben können, ohne einander zu überschreiben.

Aufbewahrung. Standardmäßig 90 Tage, in den Einstellungen änderbar. Das Kürzen betrifft die lokale Datei und iCloud; das Leeren des Protokolls lässt also keine Kopie oben, die bei der nächsten Synchronisierung zurückkäme.

Beim Ausschalten. Calíope fragt, was mit der Kopie geschehen soll, die schon in iCloud liegt: Ausschalten und iCloud-Kopie behalten lässt sie dort für deine anderen Geräte, Ausschalten und iCloud-Kopie löschen entfernt sie für alle. Was jedes Gerät lokal hat, bleibt.

Direkt im Protokoll. Die Wolke in der Leiste des Werkzeugs macht dasselbe, ohne die Einstellungen zu öffnen. Beim Einschalten fragt sie, ob das Vorhandene hochgeladen werden soll (Vorhandenes Protokoll hochladen) oder nur, was ab jetzt fehlschlägt (Nur neue Fehler); beim Ausschalten, ob zuerst geladen werden soll, was in iCloud liegt (Protokoll aus iCloud laden), und diese Kopie bleibt, wo sie ist.

Stichwörter: icloud, synchronisieren, Geräte, Datenschutz, Aufbewahrung

Der Server hat nicht geantwortet: was zu prüfen ist, und in welcher Reihenfolge.

Gilt für: MySQL MariaDB Aurora SQL Server PostgreSQL ClickHouse Redis

Dieser Fehler bedeutet, dass der Verbindungsversuch nie mit einem Server gesprochen hat: Entweder lauscht auf diesem Host und Port nichts, oder etwas unterwegs blockiert es.

Der Reihe nach, vom Wahrscheinlichsten zum Unwahrscheinlichsten:

1. Host und Port des Profils. Ein Server im Container veröffentlicht meist einen anderen Port als den Standardport seiner Engine (siehe unten).
2. Der Server läuft. Prüf es auf der Maschine, auf der er läuft, sofern du Zugriff hast.
3. Der SSH-Tunnel, falls du einen nutzt. Ein Tunnelfehler zeigt sich sehr oft als „keine Verbindung“: Such im Protokoll direkt davor nach einem SSH-Fehler.
4. Eine Firewall oder das Netz. Ein abgebrochenes VPN, ein Firmennetz, das den Port des Servers filtert, oder eine Security-Group-Regel in der Cloud erzeugen denselben Fehler.
5. Auf welcher Schnittstelle der Server lauscht. Ein Server, der nur auf 127.0.0.1 lauscht, ist von einer anderen Maschine aus unerreichbar, auch wenn er läuft; die Antwort ist dann ein SSH-Tunnel, nicht das Öffnen des Ports.

Stichwörter: Verbindung, abgelehnt, Port, Host, Firewall, 2003, 1433, 5432, 1521, 2484

Die Verbindung kam an, doch die Anmeldedaten gelten von hier aus nicht.

Gilt für: MySQL MariaDB Aurora SQL Server PostgreSQL ClickHouse Redis

Dieser Fehler ist halb gute Nachricht: Das Netz funktioniert und der Server lebt. Was scheitert, ist die Identität.

Drei Ursachen, unterschiedlich zu beheben:

- Passwort oder Benutzername entsprechen nicht dem, was der Server erwartet. Prüf sie in der Verbindungsverwaltung. Achte beim Einfügen eines Passworts auf Leerzeichen am Anfang oder Ende.
- Das Konto existiert, aber nicht von diesem Rechner aus. Jede Engine entscheidet auf ihre Weise, von wo sich ein Konto verbinden darf; die Einzelheiten stehen unten.
- Das Konto hat keine Rechte an genau dieser Datenbank. Nennt die Meldung eine Datenbank, kam der Benutzer herein, darf sie aber nicht nutzen; ein GRANT darauf fehlt.

Stichwörter: Zugriff, verweigert, Anmeldedaten, Passwort, Rechte, 1045, 18456, 28P01

Sie wurde gelöscht, umbenannt, oder dein Konto darf sie nicht sehen.

Gilt für: MySQL MariaDB Aurora SQL Server PostgreSQL

Calíope öffnet die Sitzung in der Standarddatenbank des Profils; dieser Fehler taucht daher meist beim Verbinden mit einem veränderten Server auf, auf dem es diese Datenbank nicht mehr gibt.

Worauf zu achten ist:

- Der falsche Server. Bei mehreren ähnlichen Profilen schaut man leicht auf die Produktion und glaubt, es sei die Testumgebung.

Aktualisier den Schemabaum, um die Liste zu sehen, die der Server gerade tatsächlich liefert.

Stichwörter: Datenbank, unbekannt, Schema, Rechte, 1049, 4060, 3D000

Sie brach mitten im Vorgang ab: warum, und was halb fertig bleibt.

Die Verbindung stand und brach dann ab. Wichtig ist nicht das Neuverbinden — das ist einfach —, sondern zu wissen, was halb erledigt blieb.

Lief eine Schreibanweisung ohne explizite Transaktion, kann sie ganz, teilweise oder gar nicht angewendet worden sein, je nachdem, wo abgeschnitten wurde. Das Abfrageprotokoll nennt die zuletzt abgesetzte; prüf sie auf dem Server, bevor du sie wiederholst.

Übliche Ursachen:

- Das Netz. WLAN-Wechsel, Ruhezustand oder ein sich neu verbindendes VPN trennen die Verbindung ohne Vorwarnung.

Stichwörter: Verbindung verloren, Zeitlimit, wait_timeout, Netz, 2006, 2013

SSH-Authentifizierung fehlgeschlagen: Schlüssel, Passwort und der Zweitgerät-Fall.

Der Tunnel hat den SSH-Server erreicht, konnte sich aber nicht ausweisen. Die Datenbank wurde noch gar nicht versucht.

Der verwirrendste Fall: Du hast gerade dein zweites Gerät eingerichtet. Profile synchronisieren über iCloud, die Berechtigung zum Lesen deiner privaten Schlüsseldatei jedoch nicht — und das ist kein Versehen: Diese Berechtigung verweist auf das Dateisystem eines Rechners und bedeutet auf einem anderen nichts. Auf dem neuen Gerät musst du die Schlüsseldatei im Profil erneut auswählen. Das ist die häufigste Ursache für „dasselbe Profil geht auf dem Mac und nicht auf dem iPad“.

Alles Weitere, der Reihe nach:

- Der SSH-Benutzer ist nicht der Datenbankbenutzer. Das sind zwei getrennte Identitäten, oft mit verschiedenen Namen.
- Der öffentliche Schlüssel liegt nicht auf dem Server. Er muss in der ~/.ssh/authorized_keys dieses Benutzers auf dieser Maschine stehen.
- Dateirechte auf dem Server. Eine für andere lesbare authorized_keys ignoriert der Server stillschweigend, ohne den Grund zu nennen.
- Die Passphrase des Schlüssels. Ist der Schlüssel geschützt, musst du sie eingeben; ein geschützter Schlüssel ohne Passphrase verhält sich wie ein falscher Schlüssel.

Stichwörter: ssh, Authentifizierung, privater Schlüssel, authorized_keys, Tunnel

Wann das normal ist, wann nicht, und wie man vor dem Akzeptieren prüft.

Beim ersten Verbinden mit einem SSH-Server speichert Calíope den Fingerabdruck seines Schlüssels. Legt der Server später einen anderen vor, hält Calíope an und warnt.

Diese Warnung ist keine Formalität. Ein Schlüsselwechsel sieht genauso aus wie ein Abhörversuch zwischen deinem Rechner und dem Server: Akzeptierst du den neuen Schlüssel, würdest du deine Anmeldedaten unbemerkt weitergeben.

Wann der Wechsel legitim ist:

- Das Betriebssystem des Servers wurde neu installiert.
- Die virtuelle Maschine oder der Container wurde neu erstellt.
- Name oder IP wurden einer anderen Maschine zugewiesen (in der Cloud häufig).

Wie man richtig prüft: Erfrag den Fingerabdruck bei der Administration der Maschine über einen anderen Kanal als die Verbindung selbst — eine Nachricht, einen Anruf — und vergleich ihn mit dem angezeigten. Stimmt er, akzeptier. Kannst du nicht prüfen, akzeptier nicht.

Stichwörter: ssh, Hostschlüssel, Fingerabdruck, Sicherheit, Man-in-the-Middle

Unterstützte Formate und warum die Datei von selbst unlesbar wird.

Calíope bringt eine eigene SSH-Implementierung mit und nutzt nicht das ssh des Systems, unterstützt also einen bestimmten Satz Formate: ed25519- und ECDSA-Schlüssel im OpenSSH-Format.

Wenn die Datei existiert, aber nicht gelesen wird:

- Die Berechtigung ist womöglich abgelaufen. Calíope erreicht nur Dateien, die du selbst in einem Dialog auswählst, und diese Berechtigung wird als Referenz gespeichert, die manchmal ungültig wird: Verschiebst du die Datei, benennst du den Ordner um oder stellst du den Rechner aus einer Sicherung wieder her, musst du sie erneut auswählen.
- Es könnte ein alter RSA-Schlüssel sein. Wandle ihn in ed25519 um, der zudem schneller und kürzer ist.
- Vielleicht hast du den öffentlichen Schlüssel gewählt. Die richtige Datei endet nicht auf .pub.
- Er könnte passphrasengeschützt sein. Dann musst du die Passphrase beim Verbinden eingeben; ohne sie lässt sich der Schlüssel nicht entschlüsseln, und das Ergebnis ist von einer unlesbaren Datei nicht zu unterscheiden.

Stichwörter: privater Schlüssel, ed25519, ecdsa, openssh, Berechtigung, Lesezeichen

Er bricht alle paar Minuten ab: fast immer schließt der Server untätige Sitzungen.

Der Tunnel war offen und dann nicht mehr. Das Profil neu zu verbinden hilft, aber wenn es oft passiert, gibt es eine konkrete Ursache, die sich beseitigen lässt.

Am häufigsten schließt der SSH-Server selbst untätige Sitzungen. Viele sshd-Konfigurationen haben ClientAliveInterval und ClientAliveCountMax so eingestellt, dass nach wenigen Minuten ohne Datenverkehr getrennt wird. Da eine Datenbanksitzung lange Lesephasen ohne Senden hat, bricht der Tunnel genau dann ab, wenn du zur App zurückkehrst.

Weitere Ursachen:

- Der Rechner war im Ruhezustand. Beim Aufwachen sind die bestehenden Netzverbindungen ungültig.
- Ein Netzwechsel. Von WLAN auf Kabel oder zwischen WLANs zu wechseln, ändert die Quelladresse und trennt die Sitzung.
- Ein Limit gleichzeitiger Sitzungen auf dem Server, wenn mehrere Personen denselben SSH-Benutzer teilen.

Das Aktivitätsfenster zeigt den Tunnel als aktiven Modus, solange er lebt — so siehst du auf einen Blick, ob er noch offen ist.

Stichwörter: ssh, Tunnel, Trennung, ClientAliveInterval, Untätigkeit

Er hat die Verbindung angenommen und geschlossen oder geschwiegen, ohne seinen Schlüssel zu zeigen: meist ein Port, der kein SSH ist.

Die Gegenseite hat die TCP-Verbindung angenommen und dann geschlossen oder 15 Sekunden lang nichts gesagt, ohne ihren SSH-Schlüssel zu zeigen. Calíope bricht dort ab: Schließt sie, kommt der Fehler nach etwa einer Sekunde; schweigt sie, nach 15.

Die üblichen Ursachen
- Ein Port, der kein SSH ist. Die häufigste: der Port der Datenbank als SSH-Port des Tunnels eingetragen. Prüf ihn im Profil — SSH ist meist 22.
- Der Server lehnt neue Verbindungen ab. sshd trennt Verbindungen über seinem Limit MaxStartups, bevor er grüßt; das passiert bei vielen gleichzeitigen Verbindungen oder während jemand Passwörter gegen ihn ausprobiert.
- Eine Firewall oder ein Proxy dazwischen, der die Verbindung annimmt und dann trennt.

Frühere Versionen von Calíope blieben in diesem Fall ohne Fehler bei „Verbinde …“ stehen; jetzt schlägt die Verbindung mit dieser Meldung fehl.

Stichwörter: ssh, Tunnel, Port, MaxStartups, Firewall, Zeitüberschreitung

Was Calíope von iCloud braucht und was ohne iCloud nicht mehr geht.

Calíope nutzt iCloud, um deine Profile, deine Einstellungen und — falls du es aktivierst — deine Protokolle von einem Gerät zum anderen zu bringen. Ohne aktives Konto bleibt all das lokal.

Was zu prüfen ist:

1. Dass du in den Systemeinstellungen bei iCloud angemeldet bist.
2. Dass iCloud Drive eingeschaltet ist, nicht nur das Konto.
3. Dass Calíope in der Liste der Apps steht, die iCloud Drive nutzen dürfen. Das übersieht man leicht: Das Konto kann in Ordnung und die App abgewählt sein.

Inzwischen geht nichts verloren. Alles bleibt auf diesem Gerät gespeichert; nur die Kopie auf das andere unterbleibt. Sobald iCloud zurück ist, holt die Synchronisierung von selbst auf.

Stichwörter: icloud, Konto, Drive, Synchronisierung, Companion

Ein fehlgeschlagener Upload verliert keine Daten; was tun, wenn es sich wiederholt.

Zuerst: Es ist nichts verloren. Alles, was Calíope synchronisiert, hat seine Kopie auf diesem Gerät; der Upload ist eine zusätzliche Kopie. Ein Fehler hier heißt, dass das andere Gerät die Daten später sieht, nicht dass sie gelöscht wurden.

Passiert es einmal und kehrt nicht wieder, war es fast immer das Netz. Es wird von selbst erneut versucht.

Wiederholt es sich:

- Prüf den Speicher deines Kontos. Ein volles iCloud erzeugt diesen Fehler dauerhaft.
- Sieh nach, ob zu viele Schreibvorgänge hintereinander laufen. Calíope bündelt Uploads gerade deshalb, um unter dem Frequenzlimit von iCloud zu bleiben; ein erster Upload eines sehr großen Protokolls kann jedoch mehrere Versuche brauchen.
- Schalte die betroffene Synchronisierung aus und wieder ein. Beim Einschalten wird alles von Grund auf hochgeladen.

Mach vorher eine Kopie. Die Einstellungen bieten einen vollständigen Konfigurationsexport; es gibt ihn, weil eine schlecht durchgeführte Sync-Aktivierung die Verbindungsdatei des Containers durch eine leere ersetzen kann. Das ist ein gemessener Vorfall, keine Vermutung.

Stichwörter: icloud, Synchronisierung, Fehler, erneut versuchen, Sicherung

Was in Calíope Platz belegt und was sich kürzen lässt, ohne Wichtiges zu verlieren.

Calíope speichert standardmäßig sehr wenig in iCloud: Deine Verbindungsprofile und Einstellungen belegen wenige Kilobyte.

Mit der Nutzung wachsen die Protokolle, und nur wenn du sie einschaltest: das Abfrage- und das Fehlerprotokoll. Beide haben in den Einstellungen eine einstellbare Aufbewahrung; sie zu senken ist der direkteste Weg, Platz zurückzugewinnen, ohne etwas zu verlieren, das du gerade ansahst.

Was zu kürzen ist, nach Wirkung:

1. Die Aufbewahrungstage des Abfrageprotokolls. Mit Abstand am größten: Es speichert den vollständigen Text jeder Anweisung.
2. Die Tage des Fehlerprotokolls.
3. Der Verlauf des KI-Assistenten, falls synchronisiert.

Das Leeren eines der drei aus seinem eigenen Werkzeug löscht auch die iCloud-Kopie, der Platz kommt also wirklich zurück und nicht bei der nächsten Synchronisierung wieder weg.

Deine Arbeitsdaten sind davon nicht betroffen: Datenbanken liegen auf ihren Servern, und Calíope kopiert sie nie nach iCloud.

Stichwörter: icloud, Speicher, Kontingent, Aufbewahrung, Protokoll, aufräumen

Wie Dateizugriff in einer App-Store-App funktioniert.

Calíope läuft in einer Sandbox — eine Vorgabe des App Store: Es kann eine Datei nicht über ihren Pfad öffnen, sondern nur die, die du ausdrücklich in einem Öffnen- oder Sichern-Dialog auswählst.

Das hat eine praktische Folge, die beim ersten Mal überrascht: den Pfad von Hand einzutippen genügt nicht. Auch wenn die Datei existiert und dir gehört: Ist sie nicht durch einen Dialog gegangen, sieht die App sie nicht.

So wird die Berechtigung erteilt: Öffne die Datei oder den Ordner über Öffnen… oder Sichern unter…. Danach speichert Calíope die Berechtigung und kann sie ohne Nachfrage wiederverwenden.

Wann sie neu erteilt werden muss:

- Wenn du die Datei oder ihren Ordner verschiebst oder umbenennst.
- Wenn du den Rechner aus einer Sicherung wiederherstellst.
- Wenn es ein anderes Gerät ist. Diese Berechtigungen synchronisieren bewusst nicht: Auf einem anderen Rechner bedeuten sie nichts.

Aus demselben Grund müssen ein privater SSH-Schlüssel oder ein Ordner für geplante Backups auf jedem Gerät erneut ausgewählt werden.

Stichwörter: Berechtigung, Sandbox, Datei, Zugriff, App Store, Sicherheit

Warum eine Datei, die funktionierte, plötzlich nicht mehr aufgeht.

Wenn du eine Datei in einem Dialog auswählst, speichert Calíope nicht ihren Pfad, sondern eine Zugriffsberechtigung — eine vom System ausgestellte Referenz, die ablaufen kann. Läuft sie ab, kann die App die Datei nicht mehr öffnen, auch wenn sie noch am selben Ort liegt.

Was sie ungültig macht:

- Die Datei verschieben, umbenennen oder neu erstellen.
- Einen Ordner im Pfad umbenennen.
- Den Rechner aus einer Sicherung wiederherstellen.
- Die Datei liegt auf einem externen oder Netzwerkvolume, das ausgehängt wurde.

Und es gibt einen Fall, der kein Fehler ist, sondern eine Regel: Diese Berechtigungen synchronisieren nicht zwischen Geräten, und zwar nicht aus Nachlässigkeit. Eine solche Berechtigung verweist auf das Dateisystem einer bestimmten Maschine; auf einer anderen zeigt sie ins Leere, und sie mitzunehmen erzeugt Fehler ohne sichtbare Erklärung — typischerweise eine SSH-Authentifizierung, die grundlos scheitert.

Die Lösung ist immer dieselbe: Wähl die Datei erneut aus. Sonst geht nichts verloren; der Zugriff muss nur noch einmal erteilt werden.

Stichwörter: Berechtigung, abgelaufen, Lesezeichen, Datei, Gerät, Synchronisierung

Was er abfängt, warum, und wie du es trotzdem ausführst, wenn du sicher bist.

Der sichere Modus prüft Anweisungen vor dem Senden und stoppt jede, die ALTER, CREATE, DELETE, DROP, GRANT, TRUNCATE, UPDATE, REPLACE oder RENAME enthält, mit WHERE oder ohne. Er sucht das Wort, nicht den Schaden, und gilt im Editor, im Terminal und im SQL Player gleichermaßen.

Es ist keine Rechtebeschränkung. Dein Konto darf das durchaus; der Safe Mode lässt dich nur bestätigen, dass du es so gemeint hast. Er existiert für den Sekundenfehler: das DELETE, dessen WHERE draußen blieb, weil du es vor dem Ausführen nur halb markiert hattest.

Um es trotzdem auszuführen, schalte den Safe Mode in der Leiste des SQL-Editors aus und starte erneut. Der Schalter liegt offen sichtbar und nicht tief in den Einstellungen — gerade damit das Ausschalten ein bewusster und kurzzeitiger Akt ist.

Praxistipp: In Produktionsprofilen eingeschaltet lassen, in Entwicklungsprofilen aus. Sie wird je Profil gespeichert, und darin je Editor-Tab, du musst also nicht daran denken.

Stichwörter: sicherer Modus, drop, delete, where, Schutz

Wo du ihn eingibst, wo er gespeichert wird und warum er nicht mit den Einstellungen reist.

Wo es zu finden ist: Calíope › Einstellungen › KI-Assistent

Der SQL-Assistent nutzt einen externen Anbieter und braucht einen API-Schlüssel von dir, um mit ihm zu sprechen. Er wird unter Einstellungen › KI-Assistent eingetragen.

Wo er gespeichert wird: im Schlüsselbund des Systems, nicht in einer App-Datei. Weder die Konfigurationssicherung noch die normale Synchronisierung nimmt ihn standardmäßig mit: Ein Geheimnis verlässt dieses Gerät nur, wenn du es ausdrücklich verlangst und mit einem in diesem Moment gewählten Passwort verschlüsselst.

Wenn du gerade ein anderes Gerät eingerichtet hast und der Assistent dort nicht arbeitet, liegt es daran: Der Schlüssel muss auf jedem Gerät eingegeben werden, oder die Schlüsselbund-Synchronisierung muss in den Einstellungen aktiv sein.

Calíope steht nicht zwischen dir und dem Anbieter. Der Schlüssel gehört dir, geht direkt an deinen Anbieter, und der Verbrauch wird deinem Konto berechnet. Deshalb werden Nutzungslimits und Guthaben im Dashboard des Anbieters verwaltet und nicht hier.

Stichwörter: API-Schlüssel, Assistent, KI, Schlüsselbund, Anbieter

Nutzungslimits des Anbieters und was sich aus Calíope heraus einstellen lässt.

Das Kontingent legt nicht Calíope fest, sondern der von dir eingerichtete KI-Anbieter — je nach Tarif und Guthaben.

Zwei verschiedene Grenzen, die denselben Fehler erzeugen:

- Frequenz. Zu viele Anfragen in kurzer Zeit. Eine Minute warten genügt.
- Verbrauch. Guthaben oder Periodenkontingent sind erschöpft. Das muss im Dashboard des Anbieters aufgefüllt werden.

Was sich hier einstellen lässt: Unter Einstellungen › KI-Assistent kannst du die maximalen Tokens pro Antwort senken — der größte Posten — und auf ein günstigeres Modell wechseln. Ein langes Gespräch kostet ebenfalls mehr, weil der Verlauf bei jeder Anfrage mitreist: Ein neues Gespräch zu beginnen senkt die Kosten der folgenden.

Der Rest des Programms arbeitet unverändert. Der Assistent ist nur ein Werkzeug unter vielen; nichts, was du mit SQL-Editor, Backups oder Katalogen tust, hängt von ihm ab.

Stichwörter: Kontingent, Limit, Tokens, Modell, Kosten, Anbieter

Die Datenbank bleibt in einem Zwischenzustand: wie du den Abbruchpunkt findest und was zu tun ist.

Wo es zu finden ist: Workspace › Werkzeuge › Backup

Gilt für: MySQL MariaDB Aurora SQL Server PostgreSQL

Eine Wiederherstellung wendet die Datei Anweisung für Anweisung an. Bricht sie ab, ist das bis dahin Angewandte angewandt: Die Datenbank kehrt nicht von selbst in den vorigen Zustand zurück.

Zuerst: Halte sie nicht für in Ordnung. Eine halb wiederhergestellte Datenbank hat vollständige Tabellen, leere Tabellen und fehlende Tabellen — auf den ersten Blick kann sie funktionsfähig wirken.

Wo du nachsiehst: Das technische Detail des Fehlers nennt die Anweisung, bei der abgebrochen wurde. Meist ist es eines dieser Dinge:

- Eine bereits vorhandene Tabelle. Eine Wiederherstellung in eine nicht leere Datenbank scheitert am ersten wiederholten CREATE TABLE.

- Eine Anweisung über 64 MB. Calíope liest sie nicht: Eine solche Datei sieht nicht nach SQL aus, und die Wiederherstellung hält dort an.

Der Ausweg: Am saubersten ist es, die Datenbank zu löschen und von Grund auf in eine leere wiederherzustellen. Ein Fortsetzen aus der Mitte verlangt genaue Kenntnis des bereits Angewandten, und die trägt die Datei nicht.

Stichwörter: wiederherstellen, Sicherung, definer, max_allowed_packet, halb, GO

Wie man die sichtbaren Zeilen in eine Textdatei exportiert und wo die Protokolldatei liegt.

Wo es zu finden ist: Workspace › Werkzeuge › Fehler

Exportieren speichert die sichtbaren Zeilen mit den angewendeten Filtern in einer reinen Textdatei; ohne Zeilen ist die Schaltfläche deaktiviert.

Am Fuß der Liste steht der Pfad der Protokolldatei. Auf dem Mac öffnet Im Finder zeigen ihren Ordner; außerhalb des Mac kopiert Pfad kopieren den Pfad.

Stichwörter: exportieren, Fehlerprotokoll, Textdatei, Pfad, Finder

Was bei ausgeschaltetem Protokoll passiert: Nichts wird gespeichert, und die Liste sagt das, statt leer zu wirken.

Wo es zu finden ist: Workspace › Werkzeuge › Fehler

Calíope zeichnet ihre Fehler auf, außer du schaltest es im Tab Allgemein der Einstellungen mit „Anwendungsfehler aufzeichnen“ aus. Ausgeschaltet wird nichts gespeichert, und ist die Liste leer, zeigt das Werkzeug „Die Aufzeichnung ist ausgeschaltet“ statt eines leeren Protokolls —eine leere Liste würde nahelegen, dass es keine Fehler gab—, mit einer Schaltfläche Aufzeichnung einschalten, um es wieder einzuschalten.

Dieser Schalter ist ein anderer als der für die iCloud-Synchronisierung des Protokolls („Fehler des anderen Geräts sehen“).

Stichwörter: Fehlerprotokoll, ausschalten, einschalten, Fehler aufzeichnen, Einstellungen