Uma falha na segunda linha não garante que a primeira tenha sido desfeita. O resultado depende da fronteira de confirmação adotada pelo importador. Este laboratório fictício compara duas rotinas em bancos SQLite temporários, sem tocar em sistemas reais.
A base inicial contém A de R$ 100. O lote recebido tenta inserir B de R$ 200, A de R$ 900 e C de R$ 300, nessa ordem. O identificador é chave única. A segunda tentativa conflita com o A existente e interrompe a leitura antes de C.
Erro da instrução e reversão da transação
| Rotina | Antes do lote | Depois da falha |
|---|---|---|
| Confirmação de cada instrução | R$ 100 | R$ 300 |
| Transação com reversão explícita | R$ 100 | R$ 100 |
Na primeira rotina, B já foi confirmado quando A falha. A base termina parcialmente atualizada. Na segunda, B está dentro da transação aberta. O erro de unicidade, com o comportamento padrão ABORT, desfaz a instrução que falhou, mas mantém a alteração anterior dentro da transação. O programa executa ROLLBACK para desfazer o lote inteiro.
O verificador examina esse estado intermediário: ainda existem R$ 300 antes da reversão explícita. Assim, o teste não confunde erro da instrução com cancelamento automático de tudo.
Uma correção documentada permite nova tentativa
Em um segundo arquivo, a documentação fictícia confirma que o registro de R$ 900 pertence a D, não a A. Essa correção é uma premissa fornecida, não uma renomeação automática para contornar a restrição. O lote corrigido contém B, D e C, somando R$ 1.400. Sua confirmação integral leva a base para R$ 1.500.
O pacote preserva base inicial, lote recusado, correção e resultados esperados. O teste usa conexão com controle explícito de transações e confirma tanto o estado parcial quanto a reversão e a tentativa corrigida.
As fontes são as documentações de transações e conflitos do SQLite. Na perícia contábil, registrar o lote e seu estado de confirmação evita interpretar uma carga parcial como base integral. O controle não decide se os valores são economicamente devidos.