10 lines
1.5 KiB
Markdown
10 lines
1.5 KiB
Markdown
# MMMODAS — CODIGO 017421 duplicado (investigação)
|
||
|
||
- `gfix -v -n` (validação somente leitura) em `Banco\MMMODAS.FDB`: exit 0, sem erros (`docs/runs/dupkey/gfix_validate_readonly.txt`). **Não é corrupção.**
|
||
- Causa: o índice `PK_C000025` está **INATIVO** (`RDB$INDEX_INACTIVE=1`). Com a PK inativa o Firebird não impõe unicidade; toda consulta por CODIGO faz varredura natural (`PLAN (C000025 NATURAL)`).
|
||
- As duas linhas são **produtos diferentes** (`CAM POLO ANIBAL NICO`, grupo 000036, NCM 61051000 × `CHINELO MASC NEW MHL`, grupo 000068, NCM 64022000). Duplicata física legítima, não artefato de índice.
|
||
- Histórico referencia o código sem distinguir: C000100 (2 linhas), C000032 (14), C000088 (4). Não dá para dizer a qual produto cada movimento pertence.
|
||
- Índices inativos são sistêmicos nas cópias (CONSTRUCAO 20, MMMODAS 27, RINCAO 91, TESTESOFICIAIS 68, UNIAO 0; `docs/runs/dupkey/inactive_indexes.json`): característica de como as cópias foram geradas.
|
||
- Identificador físico alternativo existe (`RDB$DB_KEY`), mas seria usar uma chave que muda em backup/restore para escrever em duas linhas de identidade ambígua. Reativar a PK falha enquanto houver duplicata; recodificar exige decisão de negócio (qual produto fica com 017421 e como tratar os 20 movimentos).
|
||
- **Decisão técnica:** nenhum UPDATE. As 46 células (2 linhas × 23 campos) permanecem `MANUAL_INPUT_REQUIRED (DUPLICATE_KEY_BLOCKED)`. Remédio para o operador: escolher qual produto recebe novo código, recodificar (com histórico) e então `ALTER INDEX PK_C000025 ACTIVE`.
|