[firebase-br] Erro na recuperação do valor

[Adriano dos Santos Fernandes]

Eduardo Bahiense escreveu:
> 
> O problema disso é, pasmem, que cada processador tem sua regra, assim, 
> em uma mesma rede onde residam um PIV em um Celeron, por exemplo, cada 
> um pode dar um número diferente para 9898,2.
> 
Que eu saiba isso é relacionado ao modelo IEEE usado, ou seja, 
processadores de mesma arquitetura teriam que ter valores idênticos.

> Observe que mesmo que o campo seja NUMERIC(N,X), se sua variável no 
> DEPLHI for single ou double, ou mesmo se você atribuir Campo.AsFloat := 
> 9798,2, estará sujeito a esse problema. Claro que, no caso do campo ser 
> NUMERIC, quando o FB converter, normalmente, resultará 9798,2, porém, se 
> no FB o campo for FLOAT, teremos duas interpretação do valor, uma na 
> máquina cliente e outra na máquina servidora, pois são processadores 
> distintos solicitados a retornar um valor de ponto flutuante.
> 
> Assim, o tipo float torna-se inviável para o tratamento de valores 
> financeiros, por exemplo, ou de valores resultantes de cálculos extensos 
> (soma de muitos itens, por exemplo), cujo resultado será expresso com 1 
> ou duas casas decimais. Nessas situação, é inevitável a dierença de 1 
> centavo para mais ou para menos, comparado ao valor obtido pela 
> calculadora de mesa. Seu uso, como já disse anteriormente, é recomendado 
> para sistemas de cálculos matemáticos de alta precisão, como cálculos de 
> engenharia.
> 
> Como eu descobri tudo isso? Porque apanhei mais que malha velha para 
> soltar poeira com esses tais 1 centavo e só resolvi quando modifiquei o 
> Sistema para usar Currency internamente e o banco de dados para usar 
> NUMERIC(X,N). O que descrevi acima, consegui na lista oficial da 
> Borland, há alguns anos, mas não tenho mais o documento original para te 
> referenciar.
> 
Currency seria um double de 80 bits, não? O problema é que só aumenta a 
precisão, não resolvendo se vc precisar de uma precisão alta. No Java, 
usa-se BigDecimal que é uma classe com lógica própria para operações com 
números BCD.

> Observe que,mesmo em ACCESS, ou qualquer outro SGBD, ou mesmo em 
> PARADOX, o descrito acima é verdadeiro.
> 
E em qualquer linguagem. A primeira vez que vi este tipo de problema foi 
em um warning que dizia que um if com uma divisão de constantes 
comparado com o valor que teria que dar nunca seria executado. :-)


Adriano