---
title: "SQLite-Datenbank auf eine andere Version bringen"
description: "Konvertiere eine SQLite-.db-Datei oder einen Dump in ein Skript, das auf SQLite ab 3.31 lädt, mit denselben Tabellen, Schlüsseln und Daten, plus Bericht."
canonical: https://intosql.com/de/sqlite-in-sqlite
last_updated: 2026-10-15
---

# SQLite-Datenbank auf eine andere Version bringen

Zieh eine SQLite-Datenbankdatei (.db, .sqlite, .sqlite3) oder das SQL, das .dump von sqlite3 schreibt, hierher und lade ein Skript herunter, das auf SQLite ab 3.31 lädt. Jede Spalte behält ihren deklarierten Typ und ihre Collation, STRICT entfällt, damit ältere Versionen die Tabellen akzeptieren, und jede Änderung steht im Bericht.

[Leitfaden: SQLite zu SQLite migrieren](https://intosql.com/docs/migrations/sqlite-to-sqlite)

[Datentypen von SQLite zu SQLite](https://intosql.com/docs/types/sqlite-to-sqlite)

## Was sich zwischen Datei und Skript ändert

Jede Zeile ist eine Regel, die der Konverter anwendet, mit der Berichtszeile, die er schreibt, wenn die Regel etwas an deinen Daten ändert.

| In der Datei | Im Skript | Berichtszeile |
| --- | --- | --- |
| declared types (any text: VARCHAR(255), DATETIME, BOOLEAN, JSON or none) | der Typ, in den jeder Wert der Spalte passt |  |
| BOOLEAN, BOOL | INTEGER 0 oder 1 mit einem CHECK |  |
| TEXT, VARCHAR(n), CHAR(n), CLOB | der deklarierte Typ, unverändert |  |
| DECIMAL(p,s), NUMERIC | der exakte Typ, wenn jeder Wert hineinpasst, sonst ein double |  |
| BLOB, and columns holding bytes | BLOB |  |
| DATE, DATETIME, TIMESTAMP holding ISO 8601 text | DATE, DATETIME als ISO-8601-Text |  |
| JSON holding JSON text | TEXT |  |
| Infinity in REAL columns | 9e999, das eigene Unendlich von SQLite |  |
| INTEGER PRIMARY KEY, AUTOINCREMENT | INTEGER PRIMARY KEY, AUTOINCREMENT beibehalten |  |
| COLLATE NOCASE | COLLATE NOCASE |  |
| generated columns | generierte Spalten, STORED oder VIRTUAL wie in der Quelle |  |
| generated columns with functions IntoSQL doesn't write, and the || operator | eine normale Spalte | `generated_not_translated` |
| defaults with functions IntoSQL doesn't write (strftime, randomblob) | kein Standardwert | `default_not_translated` |
| CHECK constraints | übersetzt |  |
| CHECK constraints with functions IntoSQL doesn't write | nicht angelegt | `check_skipped` |
| partial and expression indexes | nicht angelegt | `index_skipped` |
| foreign keys (unenforced unless PRAGMA foreign_keys=ON) | dieselben Fremdschlüssel, aufgelistet von PRAGMA foreign_key_check |  |
| foreign keys to tables the dump doesn't create | nicht angelegt | `foreign_key_skipped` |
| primary keys holding NULL, and NOT NULL columns with values that become NULL | NOT NULL entfernt | `not_null_relaxed` |
| views, triggers and virtual tables (FTS, R*Tree) | im Bericht aufgeführt | `not_converted_objects` |
| dumps without CREATE TABLE (--data-only) | Typen aus den Werten gelesen | `no_schema` |
| expressions in INSERT values other than the text functions dumps write | NULL | `expression_value` |
| NUL characters in text | beibehalten |  |
| text that isn't valid UTF-8 | die fehlerhaften Bytes als Ersatzzeichen | `invalid_utf8_replaced` |
| text decoded twice (ñ) | unverändert kopiert | `mojibake_suspected` |

## Das Skript in SQLite laden

Das Skript legt die Tabellen an, kopiert die Zeilen und fügt dann Schlüssel, Indizes und Fremdschlüssel hinzu, so lädt es schnell und hält beim ersten Fehler an.

```shell
sqlite3 -bail mydb.sqlite < sqlite.sqlite.sql
```

Fremdschlüssel werden in jeder Tabelle deklariert, und die Zeilen laden mit ausgeschalteter Fremdschlüsselprüfung. Danach listet das Skript jede Zeile auf, die auf eine nicht vorhandene Zeile verweist, statt auf halbem Weg abzubrechen.

Lade einen großen Dump in eine neue Datei auf einer lokalen Festplatte. Das Skript lädt alles in einer Transaktion ohne Synchronisierung, so läuft es mit Festplattengeschwindigkeit, und ein abgebrochenes Laden hinterlässt keine halben Tabellen.

Die Kommandozeile lädt die Datei direkt in eine SQLite-Datenbank, ohne ein Skript zu schreiben. Das ist kostenlos.

## Den SQLite-Dump für das beste Ergebnis erstellen

Der Konverter liest, was der Dump enthält. Mit diesen Optionen bleibt mehr von deinen Daten darin:

- Die Datenbankdatei selbst wird unverändert konvertiert und Seite für Seite in deinem Browser gelesen. Schließe zuerst die App, die in sie schreibt, damit keine Änderung in ihrer -wal-Datei zurückbleibt.
- sqlite3 app.db .dump > app.sql schreibt dieselbe Datenbank als SQL, das sich ebenfalls konvertieren lässt, als .sql oder .sql.gz.
- DB Browser for SQLite schreibt dieses SQL mit File, Export, Database to SQL file, und iterdump() in Python ebenso.

## Was nicht konvertiert wird

Views, Trigger, Prozeduren, Funktionen und andere Objekte in der eigenen Sprache von SQLite stehen mit Namen im Bericht und werden nie stillschweigend entfernt, damit du jedes vor dem Neuanlegen mit der SQLite-Version abgleichen kannst, in die du lädst.

## Fragen zum Wechsel von SQLite zwischen Versionen

### Wird mein Dump hochgeladen?

Nein. Der Konverter läuft in deinem Browser und liest den Dump stückweise von deiner Festplatte, daher verlässt er nie deinen Computer. Die Desktop-App und die Kommandozeile konvertieren ebenfalls auf deinem Computer.

### Wie groß darf der Dump sein?

Der Konverter hält nie den ganzen Dump im Speicher: Er liest die Datei zweimal, in Abschnitten, und schreibt das Skript fortlaufend. Dumps von mehreren Gigabyte werden im Browser, in der Desktop-App und mit der Kommandozeile konvertiert.

### Kann ich die .db-Datei selbst konvertieren?

Ja. Leg die .db-, .sqlite- oder .sqlite3-Datei ab: Sie wird in deinem Browser gelesen und nie hochgeladen. Text mit NUL-Zeichen und jede Ziffer eines double kommen so an, wie sie gespeichert sind, was ein .dump abschneiden kann.

### Aus welchen SQLite-Versionen kann der Dump stammen?

Datenbankdateien ab SQLite 3.0, in UTF-8 oder UTF-16, und Dumps aus .dump der sqlite3-Shell oder aus iterdump() in Python. Jede Testdatei und jeder Test-Dump stammt aus sqlite3 3.31 bis 3.54, einschließlich STRICT- und WITHOUT ROWID-Tabellen, und wird Zelle für Zelle mit seiner Quelle verglichen.

### Wie werden Spaltentypen bestimmt, wenn SQLite sie nicht erzwingt?

Jede Spalte behält ihren deklarierten Typ, ebenso COLLATE NOCASE und RTRIM. STRICT wird weggelassen, damit das Skript auf jeder Version ab 3.31 lädt.

### Bleiben INTEGER PRIMARY KEY und AUTOINCREMENT erhalten?

Ja. INTEGER PRIMARY KEY und AUTOINCREMENT bleiben, wie sie sind, und sqlite_sequence macht dort weiter, wo der Dump aufgehört hat.

### Was ist mit Sichten und Triggern?

Sie stehen mit Namen im Bericht und werden nicht konvertiert, damit du sie neu anlegen kannst, sobald die Tabellen da sind.

### Auf welchen SQLite-Versionen lädt das Skript?

SQLite 3.31 und neuer. Jede Testdatei und jeder Test-Dump lädt auf 3.31 und 3.54 und hält beim ersten Fehler an, falls etwas schiefgeht.

## Aus SQLite

- [SQLite zu PostgreSQL](https://intosql.com/de/sqlite-in-postgresql)
- [SQLite zu MySQL](https://intosql.com/de/sqlite-in-mysql)
- [SQLite zu MariaDB](https://intosql.com/de/sqlite-in-mariadb)
- [SQLite zu SQL Server](https://intosql.com/de/sqlite-in-sql-server)
- [SQLite zu Oracle](https://intosql.com/de/sqlite-in-oracle)

## Nach SQLite

- [MySQL zu SQLite](https://intosql.com/de/mysql-in-sqlite)
- [MariaDB zu SQLite](https://intosql.com/de/mariadb-in-sqlite)
- [PostgreSQL zu SQLite](https://intosql.com/de/postgresql-in-sqlite)
- [SQL Server zu SQLite](https://intosql.com/de/sql-server-in-sqlite)
- [Oracle zu SQLite](https://intosql.com/de/oracle-in-sqlite)

## Leitfaden und alle Paare

- [Leitfaden: SQLite zu SQLite migrieren](https://intosql.com/docs/migrations/sqlite-to-sqlite)
- [Datentypen von SQLite zu SQLite](https://intosql.com/docs/types/sqlite-to-sqlite)
- [Alle Datenbankpaare](https://intosql.com/de/datenbankmigration)