Fórum BUG com Select #53236
07/10/2005
0
Select LISTAS_PROD.ID,
LISTAS_PROD.IDENT_VISUAL,
LISTAS_PROD.PRECO,
case LISTAS_PROD.GRUPO when ´*´ then ´Todos´ else LISTAS_PROD.GRUPO end as GRUPO,
LISTAS_PROD.ID_PAI,
LISTAS_PROD.POS_INDEX,
PRODUTOS.ID_PROD,
PRODUTOS.NOME_PROD,
Cast(LISTAS_PROD.preco as float) /100 as [b:663b941dd8][color=red:663b941dd8]PRECO_Calc[/color:663b941dd8][/b:663b941dd8] from
LISTAS_PROD inner join PRODUTOS on
LISTAS_PROD.ID_PROD = PRODUTOS.ID_PROD
where LISTAS_PROD.ID_PAI =:ID_PAI order BY
PRODUTOS.NOME_PROD
O campo ´LISTAS_PROD.preco´ é um Inteiro. O campo calculado cujo nome nome ´PRECO_Calc´ retorna um preço com centavos que não existem. Exemplo: supondo que o preço seja originalmente 99999900 (é um preço em centavos), ao calcular o preço no Select acima, é retornado [b:663b941dd8]999999,04[/b:663b941dd8].
Corrigi isso mudando um pouco o Select para:
Select LISTAS_PROD.ID,
LISTAS_PROD.IDENT_VISUAL,
LISTAS_PROD.PRECO,
case LISTAS_PROD.GRUPO when ´*´ then ´Todos´ else LISTAS_PROD.GRUPO end as GRUPO,
LISTAS_PROD.ID_PAI,
LISTAS_PROD.POS_INDEX,
PRODUTOS.ID_PROD,
PRODUTOS.NOME_PROD,
Cast([b:663b941dd8]LISTAS_PROD.preco /100 as float)[/b:663b941dd8] as [b:663b941dd8][color=red:663b941dd8]PRECO_Calc[/color:663b941dd8][/b:663b941dd8] from
LISTAS_PROD inner join PRODUTOS on
LISTAS_PROD.ID_PROD = PRODUTOS.ID_PROD
where LISTAS_PROD.ID_PAI =:ID_PAI order BY
PRODUTOS.NOME_PROD
Alguém já viu isso? Alguém sabe porque acontece? Deu uma dorzinha de cabeça razoável pra resolver....
t+
Rtava
Curtir tópico
+ 0Posts
07/10/2005
Afarias
select ... LISTAS_PROD.preco/[b:b944012d48]100.0[/b:b944012d48] as PRECO_Calc ...
T+
Gostei + 0
07/10/2005
Rtava
Acho estranho dizer que um campo FLOAT não é preciso.... Mas, ok. Considerando que no FB não seja mesmo preciso, é mais estranho ainda que gere um erro logo na segunda casa decimal. Se fosse da quinta casa em diante vá lá, mas na segunda.... Acho que neste caso específico isso já pode bem ser tratado como um bug mesmo. Por outro lado, ao menos, já contornei o problema também e isso deixa de ser um caso crítico.
T+
Gostei + 0
07/10/2005
Rtava
[color=blue:5311e1c360]5. FLOAT and DOUBLE PRECISION
Float data types are used to store values with significant decimals. The following float types are supported:
Type Size Value range
Float 4 bytes 7 significant decimals;
-3.4 x 10^-38 to 3.4 x 10^38
Double Precision 8 bytes 15 significant decimals;
-1.7 x 10^-308 to 1.7 x 10^308[/color:5311e1c360]
Ou seja, para campos do tipo Float até a sexta casa esse problema não deveria ocorrer, pois ele fornece 7 casas decimais.
Gostei + 0
07/10/2005
Afarias
|Acho estranho dizer que um campo FLOAT não é preciso.... Mas, ok.
|Considerando que no FB não seja mesmo preciso,
isso não é no FB, floats não são precisos a nível de processador
no Delphi por exemplo quem busca cálculos precisos usa Currency e nunca Double ou Single.
outros softwares implementam BCD para tratar essa questão
|já pode bem ser tratado como um bug mesmo.
mas não é.
o problema não são as cadas decimais, tipos float (ponto-flutuante) podem representar números bastante grandes.
o problema é q este tipo não tem precisão nas *operações* matemáticas, isso é uma questão dos processadores
INTEIROS sim, são tipos de dados precisos em operações matemáticas (mas tb dão bem mais trabalho para os processadores, por isso só ´recentemente´ temos ai suporte adequado aos Inteiros de 64bits)
T+
Gostei + 0
07/10/2005
Rtava
Sem querer criar controvércias, pois só tenho intenção de aprender mais, mas sou obrigado a continuar discordando do que você comentou.
Acho que não faz o menor sentido fazer uma divisão de um número inteiro por 100 e o resultado ser um número com o último algarismo alterado (como no meu exemplo: 99999900/100 = 999999,04). Também não posso acreditar que o processador tenha alguma relação com isso, até porque se fosse o caso minhas aplicações todas também teriam problemas. Além disso, minha aplicação está sendo executada numa máquina Pentium 4, 3GHz com 1Gb de RAM (que nem é tão boa assim, mas já tem precisão suficiente para trabalhar com números de ponto flutuante).
Outro detalhe com relação ao problema, comparando a outros bancos de dados como MySQL, SQL Server e Oracle, em nenhum deles ocorre esse problema (testados na mesma máquina).
Então eu acho, numa boa, conforme disse antes só tenho intenção de aprender mais, eu acho que não existe nenhum explicação razoável para estar acontecendo esse problema. Até porque na própria documentação do Firebird (que foi o trecho que colei no post anterior) informa a precisão decimal, que é de 7 casas. Dentro dessas casas decimais, não deveria dar esse tipo de erro de jeito nenhum...
Mas blz.
Valeu!
Gostei + 0
07/10/2005
Afarias
http://en.wikipedia.org/wiki/Floating_point
e para um problema q ´não´ ocorre no MySQL ::
http://dev.mysql.com/doc/mysql/en/problems-with-float.html
Eis alguns trechos importantes nestas referências citadas acima:
´There are many cases where floating-point numbers do not model real numbers well, even in simple cases such as representing the decimal fraction 0.1, which cannot be exactly represented in any binary floating-point format.´
´For DOUBLE and FLOAT columns, the problems remain because inexactness is the basic nature of floating point numbers´
resumindo: representar ponto flutuante num sistema BINÁRIO não é fácil... não importa se vc tem um PentiumIV 3Ghz HT super-ultra-plus, ele continua usando o sistema binário.
T+
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)