[firebase-br] RES: Digest lista, volume 5052, assunto 1

Segunda Setembro 12 16:22:42 -03 2022

Boa Tarde,

Já tivemos esse mesmo problema (registro duplicado com a mesma pk). 

O problema nunca mais ocorreu quando migramos para Firebird 2.5.9 (ou 3.0),
pois esse problema identificamos em servidores que utilizavam Firebird 2.5.5
e 2.5.7.

Antes da migração, chegamos a colocar trigger BEFORE INSERT na tabela em
questão, com a condição semelhante a essa:

if exists (select 1 from tabela where PK = new.PK) then 
	Begin
	 -- aqui vc pode tratar, buscando um novo valor para a PK ou dar um
exception para o usuário te chamar, e poder melhor analisar o ambiente no
momento em que o erro se manifesta
	end

-----Mensagem original-----
De: lista <lista-bounces em firebase.com.br> Em nome de
lista-request em firebase.com.br
Enviada em: segunda-feira, 12 de setembro de 2022 12:00
Para: lista em firebase.com.br
Assunto: Digest lista, volume 5052, assunto 1

Enviar submissões para a lista de discussão lista para 
	lista em firebase.com.br

Para se cadastrar ou descadastrar via WWW, visite o endereço
	http://firebase.com.br/mailman/listinfo/lista_firebase.com.br
ou, via email, envie uma mensagem com a palavra 'help' no assunto ou corpo
da mensagem para 
	lista-request em firebase.com.br

Você poderá entrar em contato com a pessoa que gerencia a lista pelo
endereço
	lista-owner em firebase.com.br

Quando responder, por favor edite sua linha Assunto assim ela será mais
específica que "Re: Contents of lista digest..."

Resumos das últimas mensagens enviadas para a lista da FireBase.

Tópicos de Hoje:

   1. Chave Primária Duplicada (Valdir Dill)
   2. Re: Chave Primária Duplicada (Mário Reis)
   3. Re: Chave Primária Duplicada (Carlos H. Cantu)

----------------------------------------------------------------------

Message: 1
Date: Mon, 12 Sep 2022 06:58:42 -0300
From: Valdir Dill <valdiralbertod em gmail.com>
To: Lista Firebase <lista em firebase.com.br>
Subject: [firebase-br] Chave Primária Duplicada
Message-ID: <ee66de86-6346-3091-bafb-fbb42ec75c5a em gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Boa tarde,

Temos uma tabela (VENDAS). Ocorre também em outras tabelas, mas, aqui vamos
nos ater apenas à VENDAS.
Entre outros campos, a VENdAS tem o NUMERO e FILIAL. Estes 2 compõem o
índice primário.

Se tentarmos gravar a venda 100, com FILIAL 1, uma segunda vez, obviamente
que o Firebird vai "berrar", porque se está tentando duplicar o índice
primário.
É claro que antes do Firebird gerar erro, é aplicação que deve controlar
isso e não permitir que chegue a esse ponto. Mas...

O problema que ocorre, muito eventualmente, mas ocorreu já mais de uma vez
com usuários nossos é: o banco de dados está lá, tudo certo, com a venda 100
registrada apenas 1 vez, o índice primário ativo, tudo certo.
Aí faz-se um backup e o restore com gbak.exe. Nesse restore vem duas vendas
100, com filial 1 registradas, o que obviamente vai dar conflito no banco
pelo fato do índice primário estar duplicado.
Ao mesmo tempo, o índice primário é desativado automaticamente. Acredito que
o Firebird faça isso (desativar o índice), justamente para poder restaurar
esse segundo registro da venda 100.
Obs.: não é a mesma venda 100, pois outros campos não têm o mesmo valor. 
São duas vendas 100 diferentes.

A única coisa que posso imaginar é que por algum erro, em algum momento, o
sistema tentou registrar duas vezes com o mesmo número (100 e FILIAL
1) e o Firebird não permitiu. Entretanto esses dados não gravados  (da
segunda venda) ficaram em "um limbo" e, ao fazer o restore, eles foram
ressuscitados.
Tentamos de todas formas reproduzir o problema em labortório, mas não
ocorre. Sempre que se tenta gravar uma segunda vez registro com os mesmos
dados nos campos índice, o Firebird impede e descarta tudo (corretamente).
Quado o usuário nos envia o banco, o problema já está instalado.

Alguém poderia me dar uma luz sobre isso. Pode ser de fato isso que esteja
ocorrendo? Como é que o Firebird permitiu um segundo registro com a mesma
chave primária? E como não permitir que o Firebird gere essa situação?

Usamos Firebird 2.5

Qualquer sugestão é bem vinda!

Obrigado!

------------------------------------------------------------------------
/Cordialmente
Valdir Dill
/

------------------------------

Message: 2
Date: Mon, 12 Sep 2022 11:01:26 +0000
From: Mário Reis <mariodosreyx em gmail.com>
To: FireBase <lista em firebase.com.br>
Cc: Valdir Dill <valdiralbertod em gmail.com>
Subject: Re: [firebase-br] Chave Primária Duplicada
Message-ID:
	<CAF_dzr=Yhvnaz8XRfb6y9YUEPMaq+bNrLmOvrJENETucEd4MCg em mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Bom dia,
Não sei se percebi bem! Está a dizer que FB2.5, no "Restore" lhe traz mais
um registo venda 100 + Filial 10!
Ou seja,  "Restore" a duplicar o registo! É isso que nos está a dizer?
Desculpará, mas isso cheira a "martelada da grossa" e não acredito que
consiga nunca mais reconstruir a PK sem eliminar essa redundância, primeiro,
ou então, é um problema de corrupção da base só por aí compreendo uma tal
situação! Também acontece, ou ainda, tem que rever o parâmetros do
backup/restore(Obs.: não é a mesma venda 100, pois outros campos não têm o
mesmo valor. São duas vendas 100 diferentes)!?.
Bem, há bastante  tempo que deixamos de ter Primary Key compostas e que não
sejam sequenciais únicos e absolutos, que nas "dependências, amarram toda a
aplicação" todos as outras chaves como o seu "Venda+Filial" são Unique Keys
e em regra não servem para mais do que isso. Depois nos acessos com essas
chaves, quando necessário, usamos views sobre esses campos. Nos inputs de
pesquisa podem até ser pedidos "N.Venda + N.º da Filial", mas lá por de
trás, posiciona no registo lê a PK toda e qualquer relação dai em diante se
processa via PK!
Quanto ao controle, é feito pelo próprio FB, sim, qual a admiração. Todo o
resto é degradação de tempo em acessos Fazer à lá "Clipper/Fox" com DBFs "if
found then trava com erro Else deixa criar" caiu.
Acabou na mesma hora em que a opção/decisão foi pelo RDBMS com "Integridade
Referencial" primeiro pelo PG depois pelo Firebird por ser muito mais leve
ainda que, à data, com bastante menos potencialidades!
E, bendita hora; mudar tudo custou um pouco, mas nem que nos pagassem para
voltar para trás! Está fora de questão!
Na hora o compromisso foi FB1.5, creio (hoje FB3), mas também mudamos o
paradigma de programação.
É o "data engine" quem trava a repetição de uma chave e quando ele retorna
em erro, interceptamos e  tratamos o erro.
E,  é assim há quase 20 anos sem problemas uma falha de energia com uma UPS
problemática, mas reposumemos o backup , limpinho e tudo voltou ao normal.
Com os meus melhores cumprimentos
Mário Agostinho Reis
919262146

Esta mensagem contém informação de natureza confidencial e é exclusivamente
dirigida ao(s) destinatário(s) indicado(s). Se, por engano, receber este
email agradecemos que não o copie nem o reenvie e que nos notifique do
ocorrido através do email de resposta.

Valdir Dill via lista <lista em firebase.com.br> escreveu no dia segunda,
12/09/2022 à(s) 09:59:

> Boa tarde,
>
> Temos uma tabela (VENDAS). Ocorre também em outras tabelas, mas, aqui 
> vamos nos ater apenas à VENDAS.
> Entre outros campos, a VENdAS tem o NUMERO e FILIAL. Estes 2 compõem o 
> índice primário.
>
> Se tentarmos gravar a venda 100, com FILIAL 1, uma segunda vez, 
> obviamente que o Firebird vai "berrar", porque se está tentando 
> duplicar o índice primário.
> É claro que antes do Firebird gerar erro, é aplicação que deve 
> controlar isso e não permitir que chegue a esse ponto. Mas...
>
> O problema que ocorre, muito eventualmente, mas ocorreu já mais de uma 
> vez com usuários nossos é: o banco de dados está lá, tudo certo, com a 
> venda 100 registrada apenas 1 vez, o índice primário ativo, tudo certo.
> Aí faz-se um backup e o restore com gbak.exe. Nesse restore vem duas 
> vendas 100, com filial 1 registradas, o que obviamente vai dar 
> conflito no banco pelo fato do índice primário estar duplicado.
> Ao mesmo tempo, o índice primário é desativado automaticamente. 
> Acredito que o Firebird faça isso (desativar o índice), justamente 
> para poder restaurar esse segundo registro da venda 100.
> Obs.: não é a mesma venda 100, pois outros campos não têm o mesmo valor.
> São duas vendas 100 diferentes.
>
> A única coisa que posso imaginar é que por algum erro, em algum 
> momento, o sistema tentou registrar duas vezes com o mesmo número (100 
> e FILIAL
> 1) e o Firebird não permitiu. Entretanto esses dados não gravados  (da 
> segunda venda) ficaram em "um limbo" e, ao fazer o restore, eles foram 
> ressuscitados.
> Tentamos de todas formas reproduzir o problema em labortório, mas não 
> ocorre. Sempre que se tenta gravar uma segunda vez registro com os 
> mesmos dados nos campos índice, o Firebird impede e descarta tudo 
> (corretamente). Quado o usuário nos envia o banco, o problema já está 
> instalado.
>
> Alguém poderia me dar uma luz sobre isso. Pode ser de fato isso que 
> esteja ocorrendo? Como é que o Firebird permitiu um segundo registro 
> com a mesma chave primária? E como não permitir que o Firebird gere 
> essa situação?
>
> Usamos Firebird 2.5
>
> Qualquer sugestão é bem vinda!
>
> Obrigado!
>
>
> ----------------------------------------------------------------------
> --
> /Cordialmente
> Valdir Dill
> /
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br 
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>

------------------------------

Message: 3
Date: Mon, 12 Sep 2022 09:05:20 -0300
From: "Carlos H. Cantu" <listas em warmboot.com.br>
To: FireBase <lista em firebase.com.br>
Subject: Re: [firebase-br] Chave Primária Duplicada
Message-ID: <828013511.20220912090520 em warmboot.com.br>
Content-Type: text/plain; charset=iso-8859-1

Imagino a seguinte situação:

1) Houve uma corrupção na base de dados, mais especificamente no índice da
PK da tabela de vendas, que é usado pelo Firebird para saber se já existe um
registro e impedir duplicidade. Com a corrupção, o FB não encontrou a venda
no índice e deixou gravar uma segunda venda com os mesmos IDs, pois para
ele, ainda não existia.

2) Em algum momento, você fez um backup/restore. Durante o restore, os
índices são recriados e com isso a "duplicidade" apareceu, fazendo com que o
a PK ficasse desativada no banco restaurado. Se vc não se atentou nisso (o
gbak reporta o problema), pode ter usado o banco com a PK desativada,
possibilitando o surgimento de novas duplicidades, já que a PK não estava
ativa para assegurar que isso não acontecesse.

PS: Corrupção não é normal. Sugiro que verifique o ambiente do servidor,
especialmente HDDs e memória RAM, e lembre-se de deixar o forced writes
ligado.

[]s
Carlos H. Cantu
eBook Guia de Migração para o FB 4 - www.firebase.com.br/guiafb4.php
www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

VDvl> Boa tarde,

VDvl> Temos uma tabela (VENDAS). Ocorre também em outras tabelas, mas, aqui
vamos nos ater apenas à VENDAS.
VDvl> Entre outros campos, a VENdAS tem o NUMERO e FILIAL. Estes 2 compõem o
índice primário.

VDvl> Se tentarmos gravar a venda 100, com FILIAL 1, uma segunda vez, 
VDvl> obviamente que o Firebird vai "berrar", porque se está tentando
duplicar o índice primário.
VDvl> É claro que antes do Firebird gerar erro, é aplicação que deve 
VDvl> controlar isso e não permitir que chegue a esse ponto. Mas...

VDvl> O problema que ocorre, muito eventualmente, mas ocorreu já mais de 
VDvl> uma vez com usuários nossos é: o banco de dados está lá, tudo 
VDvl> certo, com a venda 100 registrada apenas 1 vez, o índice primário
ativo, tudo certo.
VDvl> Aí faz-se um backup e o restore com gbak.exe. Nesse restore vem 
VDvl> duas vendas 100, com filial 1 registradas, o que obviamente vai 
VDvl> dar conflito no banco pelo fato do índice primário estar duplicado.
VDvl> Ao mesmo tempo, o índice primário é desativado automaticamente. 
VDvl> Acredito que o Firebird faça isso (desativar o índice), justamente 
VDvl> para poder restaurar esse segundo registro da venda 100.
VDvl> Obs.: não é a mesma venda 100, pois outros campos não têm o mesmo
valor. São duas vendas 100 diferentes.

VDvl> A única coisa que posso imaginar é que por algum erro, em algum 
VDvl> momento, o sistema tentou registrar duas vezes com o mesmo número 
VDvl> (100 e FILIAL 1) e o Firebird não permitiu. Entretanto esses dados 
VDvl> não gravados  (da segunda venda) ficaram em "um limbo" e, ao fazer o
restore, eles foram ressuscitados.
VDvl> Tentamos de todas formas reproduzir o problema em labortório, mas 
VDvl> não ocorre. Sempre que se tenta gravar uma segunda vez registro 
VDvl> com os mesmos dados nos campos índice, o Firebird impede e descarta
tudo (corretamente).
VDvl> Quado o usuário nos envia o banco, o problema já está instalado.

VDvl> Alguém poderia me dar uma luz sobre isso. Pode ser de fato isso 
VDvl> que esteja ocorrendo? Como é que o Firebird permitiu um segundo 
VDvl> registro com a mesma chave primária? E como não permitir que o
Firebird gere essa situação?

VDvl> Usamos Firebird 2.5

VDvl> Qualquer sugestão é bem vinda!

VDvl> Obrigado!

VDvl> ------------------------------------------------------------------
VDvl> ------
VDvl> /Cordialmente
VDvl> Valdir Dill
VDvl> /
VDvl> ______________________________________________
VDvl> FireBase-BR (www.firebase.com.br) - Hospedado em 
VDvl> www.locador.com.br Para saber como gerenciar/excluir seu cadastro na
lista, use:
VDvl> http://www.firebase.com.br/fb/artigo.php?id=1107
VDvl> Para consultar mensagens antigas: 
VDvl> http://www.firebase.com.br/pesquisa_lista.html

------------------------------

Subject: Legenda do Digest

_______________________________________________
lista mailing list
lista em firebase.com.br
http://firebase.com.br/mailman/listinfo/lista_firebase.com.br

------------------------------

Fim da Digest lista, volume 5052, assunto 1
*******************************************