[firebase-br] Isso já ocorreu com mais alguém?

[Carlos H. Cantu]

Particularmente, a única situação onde eu vi o Firebird gravar um
valor "diferente" do que vc mandou é quando se usa os campos baseados
no IEEE (float, double precision, numeric/decimal no dialeto 1), sendo
que nesse caso, não é defeito no Firebird, e sim um artefato da
definição do IEEE, que não garante precisão dos valores armazenados.

Lembrando que em bases convertidas do dialeto 1 para o 3 através do
gfix, os campos numeric/decimal existentes continuam armazenando os
valores no formato definido pelo IEEE.

Outra situação, mais rara, é quando vc mistura DML e DDL numa mesma
transação.

PS: Tem que ficar espero com o IBExpert, pois ele apresenta os valores
usando "format" do Delphi, o que pode gerar arredondamentos,
dependendo da máscara definida.


[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br

GS> Tentei reproduzir pela terceira vez, mas dessa vez fiz a limpa na máquina e
GS> reinstalei o FB 2.5.4 para .2.5.5.
GS> Novamente criei a base do zero através de scripts e carreguei a base com os
GS> tradicionais 700M de dados .
GS> Refiz o calculado e ainda estou conferindo item-a-item um calculado para
GS> que não haja engano e depois de uns 15 minutos de conferencia ainda não
GS> achei nenhum erro.
GS> Eu não compreendi exatamente o que houve.
GS> Problemas com arredondamentos são conhecidos por misturar tipos diferentes
GS> float, int e bcd. O que faço por aqui é não misturar esses tipos, quase
GS> sempre declaro minhas variaveis como type of column para nunca nunca errar
GS> o tipo e tamanho de uma variavel que será enviada para o banco, mas com os
GS> numeros eu faço essas declarações explicitamente como numeric para ter
GS> certeza de que não estou misturando dados de natureza diferentes e tambem
GS> porque type of column carrega as constraints do banco para a variavel e
GS> isso pode ser um problema em algumas situações.
GS> O Carlos pediu para tentar ver se consigo reproduzir, mas devido a
GS> complexidade do programa, da base e do calculo (sabe o que é calcular um
GS> preço de venda em todas as etapas de um processo industral, né?) é
GS> complicado criar um teste unitário.
GS> O que eu faço por aqui é usar o IBExpert e ficar debugando a procedure
GS> step-by-step e é assim que estou descobrindo que o valor que a procedure
GS> calculou deu certo, mas o FB gravou errado.
GS> Eu acho, que talvez tenha sido porque havia transações ao fundo e quando
GS> paro para procurar o problema não ocorre porque é apenas eu e o ibexpert.
GS> Eu tenho quase certeza que não chegarei a nenhuma compreensão real do
GS> problema e vou depositar novamente o problema nos gremlins.


GS> Em 3 de março de 2016 14:11, Adilson B. Cápua Jr. <juniorcapua em gmail.com>
GS> escreveu:

>> Sempre que usava NUMERIC(12,2) para campos do tipo monetário eu tive
>> problemas com arredondamentos.
>> Só resolvi meus problemas quando passei a usar NUMERIC(12,4)
>>
>> Seu problema pode ser isso!