---
title: "Portare un database SQLite a un'altra versione"
description: "Converti un file .db o un dump SQLite in uno script che si carica su SQLite 3.31 e successivi, con le stesse tabelle, chiavi e dati, e un report delle modifiche."
canonical: https://intosql.com/it/sqlite-in-sqlite
last_updated: 2026-10-15
---

# Portare un database SQLite a un'altra versione

Trascina un file di database SQLite (.db, .sqlite, .sqlite3) o l'SQL che scrive .dump di sqlite3, e scarica uno script che si carica su SQLite 3.31 e successivi. Ogni colonna conserva il tipo dichiarato e la collation, STRICT viene omesso perché le versioni più vecchie accettino le tabelle, e ogni modifica è elencata nel report.

[Guida alla migrazione da SQLite a SQLite](https://intosql.com/docs/migrations/sqlite-to-sqlite)

[Tipi di dati da SQLite a SQLite](https://intosql.com/docs/types/sqlite-to-sqlite)

## Cosa cambia tra il file e lo script

Ogni riga è una regola che il convertitore applica, con la riga del report che scrive quando la regola cambia qualcosa nei tuoi dati.

| Nel file | Nello script | Riga del report |
| --- | --- | --- |
| declared types (any text: VARCHAR(255), DATETIME, BOOLEAN, JSON or none) | il tipo in cui stanno tutti i valori della colonna |  |
| BOOLEAN, BOOL | INTEGER 0 o 1 con un CHECK |  |
| TEXT, VARCHAR(n), CHAR(n), CLOB | il tipo dichiarato, mantenuto così com'è |  |
| DECIMAL(p,s), NUMERIC | il tipo esatto quando ogni valore ci sta, altrimenti un double |  |
| BLOB, and columns holding bytes | BLOB |  |
| DATE, DATETIME, TIMESTAMP holding ISO 8601 text | DATE, DATETIME come testo ISO 8601 |  |
| JSON holding JSON text | TEXT |  |
| Infinity in REAL columns | 9e999, l'infinito di SQLite |  |
| INTEGER PRIMARY KEY, AUTOINCREMENT | INTEGER PRIMARY KEY, AUTOINCREMENT mantenuto |  |
| COLLATE NOCASE | COLLATE NOCASE |  |
| generated columns | colonne generate, STORED o VIRTUAL come nella sorgente |  |
| generated columns with functions IntoSQL doesn't write, and the || operator | una colonna semplice | `generated_not_translated` |
| defaults with functions IntoSQL doesn't write (strftime, randomblob) | nessun valore predefinito | `default_not_translated` |
| CHECK constraints | tradotti |  |
| CHECK constraints with functions IntoSQL doesn't write | non creato | `check_skipped` |
| partial and expression indexes | non creato | `index_skipped` |
| foreign keys (unenforced unless PRAGMA foreign_keys=ON) | le stesse chiavi esterne, elencate da PRAGMA foreign_key_check |  |
| foreign keys to tables the dump doesn't create | non creato | `foreign_key_skipped` |
| primary keys holding NULL, and NOT NULL columns with values that become NULL | NOT NULL rimosso | `not_null_relaxed` |
| views, triggers and virtual tables (FTS, R*Tree) | elencati nel report | `not_converted_objects` |
| dumps without CREATE TABLE (--data-only) | tipi ricavati dai valori | `no_schema` |
| expressions in INSERT values other than the text functions dumps write | NULL | `expression_value` |
| NUL characters in text | mantenuto |  |
| text that isn't valid UTF-8 | i byte errati come carattere di sostituzione | `invalid_utf8_replaced` |
| text decoded twice (ñ) | copiato così com'è | `mojibake_suspected` |

## Carica lo script in SQLite

Lo script crea le tabelle, copia le righe, poi aggiunge chiavi, indici e chiavi esterne, così si carica in fretta e si ferma al primo errore.

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

Le chiavi esterne sono dichiarate in ogni tabella e le righe si caricano con i controlli delle chiavi esterne disattivati. Lo script poi elenca ogni riga che punta a una riga che non esiste, invece di fallire a metà.

Per un dump grande, carica in un file nuovo su un disco locale. Lo script carica tutto in un'unica transazione con la sincronizzazione disattivata, così va alla velocità del disco, e un caricamento che si ferma a metà non lascia tabelle parziali.

La riga di comando carica il file direttamente in un database SQLite, senza scrivere uno script. È gratis.

## Fai il dump di SQLite per il miglior risultato

Il convertitore legge ciò che il dump contiene. Con queste opzioni il dump conserva più dei tuoi dati:

- Il file del database si converte così com'è, letto pagina per pagina nel browser. Chiudi prima l'app che ci scrive, così nessuna modifica resta indietro nel suo file -wal.
- sqlite3 app.db .dump > app.sql scrive lo stesso database come SQL, che si converte anch'esso, come .sql o .sql.gz.
- DB Browser for SQLite scrive quel SQL con File, Export, Database to SQL file, e così fa iterdump() di Python.

## Cosa non viene convertito

Viste, trigger, procedure, funzioni e altri oggetti scritti nel linguaggio di SQLite sono elencati per nome nel report, mai eliminati in silenzio, così puoi verificare ognuno con la versione di SQLite in cui carichi prima di ricrearlo.

## Domande sul passaggio di SQLite tra versioni

### Il mio dump viene caricato?

No. Il convertitore funziona nel tuo browser e legge il dump dal tuo disco a pezzi, quindi non lascia mai il tuo computer. Anche l'app desktop e la riga di comando convertono sul tuo computer.

### Quanto può essere grande il dump?

Il convertitore non tiene mai l'intero dump in memoria: legge il file due volte, per intervalli, e scrive lo script man mano. I dump di più gigabyte si convertono nel browser, nell'app desktop e con la riga di comando.

### Posso convertire direttamente il file .db?

Sì. Trascina il file .db, .sqlite o .sqlite3: viene letto nel browser e mai caricato. Il testo con caratteri NUL e ogni cifra di un double arrivano come sono salvati, cosa che un .dump può troncare.

### Da quali versioni di SQLite può provenire il dump?

File di database da SQLite 3.0 in poi, in UTF-8 o UTF-16, e dump del .dump della shell sqlite3 o di iterdump() di Python. Ogni file e dump di test viene da sqlite3 dalla 3.31 alla 3.54, tabelle STRICT e WITHOUT ROWID incluse, ed è confrontato con la sorgente cella per cella.

### Come vengono decisi i tipi di colonna se SQLite non li applica?

Ogni colonna mantiene il suo tipo dichiarato, e così COLLATE NOCASE e RTRIM. STRICT viene escluso, così lo script si carica su ogni versione dalla 3.31.

### INTEGER PRIMARY KEY e AUTOINCREMENT vengono mantenuti?

Sì. INTEGER PRIMARY KEY e AUTOINCREMENT restano come sono, e sqlite_sequence riparte da dove l'ha lasciata il dump.

### E viste e trigger?

Sono elencati per nome nel report e non vengono convertiti, così puoi ricrearli una volta caricate le tabelle.

### Su quali versioni di SQLite si carica lo script?

SQLite 3.31 e successive. Ogni file e dump di test si carica su 3.31 e 3.54, fermandosi al primo errore se qualcosa va storto.

## Da SQLite

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

## Verso SQLite

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

## Guida e tutte le coppie

- [Guida alla migrazione da SQLite a SQLite](https://intosql.com/docs/migrations/sqlite-to-sqlite)
- [Tipi di dati da SQLite a SQLite](https://intosql.com/docs/types/sqlite-to-sqlite)
- [Tutte le coppie di database](https://intosql.com/it/migrazione-database)