Migração de dados de SQLite para SQL Server

Migrar de SQLite para SQL Server: o que muda no destino

Se a tabela não existe no SQL Server, o dbSlice para e mostra um CREATE TABLE traduzido para o SQL Server, para o seu DBA revisar e rodar. Por padrão, ele não cria nada nos seus bancos. O SQLite tem tipagem frouxa; por isso, o dbSlice lê o tipo que você declarou, com tamanho e precisão, e o traduz:

Texto mantém o tamanho declarado. Um VARCHAR(100) do SQLite é sugerido como NVARCHAR(100). Colunas declaradas como TEXT, ou sem tamanho, viram NVARCHAR(MAX), que o SQL Server não aceita como chave nem num índice comum. Dê um tamanho a essas colunas se forem chave ou indexadas.
INTEGER vira BIGINT. Os inteiros do SQLite têm 64 bits, e um INTEGER PRIMARY KEY é o row id de 64 bits do SQLite; por isso, o DDL sugerido usa BIGINT.
Decimais mantêm a precisão. DECIMAL(10,2) é sugerido como DECIMAL(10,2). Um decimal declarado sem precisão é sugerido como DECIMAL(38,10); confira os valores reais antes de rodar o CREATE TABLE.
Colunas sem tipo (permitidas no SQLite) são sugeridas como NVARCHAR(MAX). Declare o tipo que os dados realmente têm.
Datas guardadas como texto ou número. O SQLite não tem tipo de data; os apps guardam texto ISO (2026-11-02 10:30:00) ou Unix time. Quando a coluna no SQL Server é DATE ou DATETIME2, o dbSlice converte os dois no caminho. Números de dia juliano (REAL) precisam de um SELECT na origem: SELECT id, datetime(created_jd) AS created_at, … FROM orders.
Valores misturados numa coluna. O SQLite aceita texto numa coluna INTEGER. Números guardados como texto são convertidos quando o destino é numérico. Um valor que não é número de jeito nenhum para a linha com o erro real; limpe-o num SELECT antes.
Ids. Se a chave no SQL Server é uma coluna IDENTITY, ligue Keep identity para manter os ids do SQLite; isso exige permissão de ALTER e é confirmado na tela antes. Uma chave BIGINT comum não precisa de nada disso.
O Upsert roda como MERGE e as cargas em massa usam SqlBulkCopy, com triggers e constraints verificados.

Como o dbSlice controla a carga

Lê o arquivo SQLite ordenado pela chave.
Casa as linhas por uma chave que você escolhe. Modos: Initial load, depois Upsert, Insert new, Update only ou incremental por coluna (updated_at ou o row id).
Confere antes de gravar com o Record Diff e as conferências na tela, e prova o resultado com o Compare e a lista completa de chaves divergentes.
Mascara no caminho as cópias de desenvolvimento e teste, mantendo chaves e chaves estrangeiras intactas.
Exportar em vez de carregar: quando você só precisa de um arquivo, o mesmo app exporta uma tabela do SQLite para CSV, JSON, XML ou HTML.

Passo a passo: converter uma tabela de SQLite para SQL Server

Abra o arquivo do banco SQLite e conecte no SQL Server.
Escolha a tabela de origem (ou um SELECT, como no exemplo da data juliana) e a tabela de destino.
Escolha a coluna-chave, e ligue Keep identity se a chave do destino for uma coluna IDENTITY.
Escolha o modo: Initial load, depois Upsert ou Insert new.
Rode o Record Diff e depois a cópia, ou salve como job para a CLI e o Agendador de Tarefas do Windows.

Mover dados entre SQLite e SQL Server, com qualquer um dos dois como origem

No outro sentido, o dbSlice exporta uma tabela do SQL Server para um arquivo de banco SQLite, prático para uma cópia portátil ou um app offline. Para PostgreSQL, veja SQLite para PostgreSQL.

Perguntas frequentes

O SQLite precisa de servidor ou driver?

Não. O dbSlice abre o arquivo do banco diretamente.

Triggers e views são convertidos?

Não. O dbSlice move dados; views podem ser origem por meio de um SELECT.

As execuções incrementais copiam as exclusões?

Não. Rode o Compare ou uma recarga antes da troca.

Existe versão gratuita?

Sim, na Microsoft Store: ela conecta, navega, compara e exporta para CSV. Gravar num destino exige uma licença Desktop ou Server.