Datei-Datenbank-Explorer
Öffne SQLite-Dateien lokal im Browser: Tabellen, Zeilenzahlen, Spalten und Schlüssel prüfen, SQL-Abfragen ausführen und CSV oder JSON speichern.
Deine Eingaben werden in deinem Browser verarbeitet und nicht an unsere Server übertragen. Hinweis: Drittanbieter-Ressourcen (z. B. Werbung und Analyse von Google/Cloudflare) sowie ein freiwilliger PayPal-Spendenlink können beim Laden bzw. Anklicken Daten übertragen. Browser-Erweiterungen oder -Plugins können sichtbare Inhalte in den Eingabefeldern mitlesen.
Ergebnis erscheint hier …
SQLite-Datei öffnen: Struktur, Zeilenzahlen und Daten prüfen
Was steckt in einer .db-Datei? Der Datei-Datenbank-Explorer liest SQLite-3-Dateien direkt auf deinem Gerät. Wähle eine Datei oder ziehe sie in das Auswahlfeld und klicke auf „Datenbank öffnen“. Die Übersicht nennt die Dateigröße, Tabellen, Views und Indizes. Für lesbare Tabellen zählt das Tool die Zeilen mit COUNT(*), statt sie zu schätzen. Interne SQLite-Tabellen zählen nicht zur Tabellensumme; die Indexzahl enthält auch automatische Indizes.
Tabellen und Schlüssel verstehen
Öffne eine Tabelle über ihren Namen oder die Auswahlliste. Du siehst die CREATE-Anweisung, Spaltennamen, deklarierte Typen und die daraus abgeleitete SQLite-Typaffinität. Dazu kommen die Position im Primärschlüssel, NOT-NULL-Angaben, Standardwerte und versteckte oder generierte Spalten. Die NOT-NULL-Spalte zeigt die deklarierte Einschränkung; sie bildet nicht jede implizite Regel eines Primärschlüssels ab. Unterhalb stehen Indizes mit ihren Spalten und Fremdschlüssel mit Zieltabellen sowie Änderungs- und Löschregeln.
Der Tabellenbrowser zeigt 10, 25, 50 oder 100 Zeilen pro Seite. Ein Klick auf eine Spaltenüberschrift sortiert die gesamte Tabelle aufsteigend, ein weiterer absteigend. Die Sortierung folgt SQLite, nicht einer nachträglichen Textsortierung im Browser. Views kannst du ebenfalls öffnen. Erweiterungen wie eigene Kollationen oder bestimmte virtuelle Tabellen stehen in der mitgelieferten SQLite-Engine eventuell nicht bereit.
Eigene SQL-Abfragen, ohne die Datei zu verändern
Das SQL-Feld akzeptiert eine einzelne SELECT-Abfrage, auch mit WITH. Zum Beispiel zählt SELECT COUNT(*) FROM "kunden"; die Zeilen einer Tabelle namens kunden. Nutze für andere Dateien deren tatsächliche Tabellennamen. Schreibbefehle, mehrere Anweisungen und frei eingegebene PRAGMA-Befehle sind gesperrt. Zusätzlich setzt die Engine query_only. Deine Originaldatei verändert das Tool nicht.
Abfragen liefern höchstens 10.000 Zeilen; die Vorschau zeigt davon die ersten 100. Ein Hinweis nennt eine Begrenzung, auch beim Ergebnisexport. Die Engine läuft in einem eigenen Worker. Eine Aktion stoppt nach 20 Sekunden, das erste Öffnen nach 45 Sekunden. Danach musst du die Datei neu laden. „Integrität prüfen“ führt die SQLite-Schnellprüfung quick_check aus, keine vollständige forensische Untersuchung.
CSV, JSON und das Schema speichern
Speichere eine ganze Tabelle als CSV oder JSON, unabhängig von der aktuellen Seite. Tabellenexporte haben eine Grenze von einer Million Zeilen. Über dieser Grenze bricht das Tool ab, statt heimlich einen Ausschnitt zu speichern. Der Ergebnisexport übernimmt dagegen nur die bis zu 10.000 Zeilen der letzten erfolgreichen SQL-Abfrage. „Schema als SQL“ speichert CREATE-Anweisungen ohne Tabelleninhalte.
Binärwerte erscheinen als Hextext mit 0x. Ganzzahlen außerhalb des sicheren JavaScript-Zahlenbereichs bleiben als Zeichenfolgen exakt. JSON erhält NULL-Werte; CSV enthält dafür leere Felder. Vor formelähnliche Textwerte setzt der CSV-Export ein Apostroph, damit Tabellenprogramme sie nicht als Formeln behandeln. Doppelte Ergebnisspalten bekommen eindeutige Namen. Für weitere Textdateien gibt es den CSV-Viewer und den JSON-Formatter.
WAL, Sicherungskopien und Speichergrenzen
Das Tool prüft die Kennung SQLite format 3 samt Nullbyte und zeigt den Journalmodus aus dem Dateikopf. Dieser Modus beweist nicht, dass eine WAL-Datei existiert. Wählst du Begleitdateien mit den Endungen -wal, -shm oder -journal mit aus, nennt die Übersicht ihre Namen. Der Browser kann andere Dateien im Quellordner nicht selbst suchen. Begleitdateien fließen nicht in die Auswertung ein. Erstelle deshalb eine konsistente SQLite-Sicherung, besonders bei einer laufenden Anwendung.
sql.js lädt die Datenbank vollständig in den Arbeitsspeicher. Über 50 MB brauchst du eine Bestätigung des Speicherhinweises; über 200 MB öffnet das Tool die Datei nicht. Die JavaScript- und WASM-Dateien liegen auf unserem Server und laden erst beim Öffnen. Deine Datenbankdatei verarbeitet nur dein Browser. „Schließen und leeren“ beendet den Worker und entfernt die Ansicht.
Häufige Fragen
Welche Datenbankdateien unterstützt der Explorer?
Unverschlüsselte SQLite-3-Dateien, häufig mit .db, .sqlite, .sqlite3 oder .db3. Entscheidend ist der Inhalt, nicht die Endung. DuckDB, Access, SQL-Textdumps und verschlüsselte SQLCipher-Dateien unterstützt das Tool nicht. CSV und JSON dienen hier nur als Exportformate.
Verlässt meine Datenbank das Gerät?
Nein. Das Tool liest die gewählte Datei lokal mit sql.js. Es sendet weder die Datei noch SQL-Abfragen oder Ergebnisse an einen Server.
Warum fehlen neue Datensätze?
Sie können noch in einer WAL-Datei liegen. Der Explorer liest nur die Hauptdatei. Nutze eine vollständige SQLite-Sicherung aus der Quellanwendung, nicht eine während des Betriebs kopierte Einzeldatei.
Kann ich UPDATE oder DELETE ausführen?
Nein. Das SQL-Feld erlaubt nur lesende SELECT-Abfragen, auch mit WITH. Schreibbefehle und PRAGMA sind gesperrt. Es gibt keinen Datenbank-Speicherbutton.
Was bedeutet ein Fehler trotz gültigem Dateikopf?
Die Datei kann unvollständig oder beschädigt sein oder eine Erweiterung benötigen, die sql.js nicht mitbringt. Prüfe eine neue Sicherung in der Quellanwendung. Eine gültige Kennung allein garantiert keine intakte Datenbank.