TRIO COMP. SQLDATASET DATASETPROVIDER CLIENTDATASET

19/08/2008

0

Estou utilizando em minha aplicacao o TRIO COMPONENTES SQLDATASET + DATASETPROVIDER + CLIENTDATASET do DbExpress + FireBird 1.5 com sql dialect 1 Delphi 7

A Sitação é a seguinte: Tenho uma tabela onde colocos os dados de Valor e Quantidade, como se fosse uma quantidade de parcelas, e disparo por uma trigger a o valor / quantidade, gerando os registros para uma outra tabela relacionada com a citada acima, ate aki td bem.

em um caso especifico onde tenha uma divisao que gere um resultado com uma dizima por ex: 400,00 / 17 resultado seria ´23,529411764´ ou ´23,53´

no banco de dados o campo valor esta como numeric(15,2) e esta gravando o resultado correto da divisao.

o problema é que quando do um select na tabela filha ele coloca os registros como ´23,52´ e se vc calcular esse valor X 17 vai da ´399,84´ e não o valor de 400,00

observei que ao efetuar o mesmo select com os componentes do BDE ele retorna os registros com uma dizima ´23,529411764´ se eu colocar uma mascara ele funciona corretamente ´23,53´.

tb efetuei o select com os componentes da plaheta do interbase, esse sim retorna o resultado correto ´23,53´.

tb fiz os mesmos teste com o Delphi 2006 e não obtive exito.

Alguem já passou por algum problema desses, ou sabe se existe alguma atualizacao do dbexpress?

Obrigado.


Igorcb

Igorcb

Responder

Posts

23/08/2008

Igorcb

nada ainda pessoal... alguma ideia, atualizacao!!!!


Responder

23/08/2008

Marco Salles

Mas vc acha mesmo que isto precisa de Atualização ???

Se voce esta definindo o campo como numeric(15,2) pq que voce acha
que ele deveria resultar num valor ja arredondado ????

existe maneiras para se resolver isto ... Existem por exemplo no Firebird 2.0 as UDF para este tipo de arredondamento... Mas no Firebird 1.5 esta
função de Truncamento deve ser implementada

Porém acho que isto tb não resolveria...

Imagine a situação de 23,52[u:67eec52d0f][b:67eec52d0f]6[/b:67eec52d0f][/u:67eec52d0f]411764´ com a função ele arredondaria para cima o que tornaria o resultado ainda pior

Acho então que voce deve aumentar a Precisão do Campo de numeric

Na hora de Apresentar os dados voce pode especificar um padrão menor
ja arredondado... por exemplo usando o método ongettext

Agora não acho que voce deva pegar estes valores das parcelas e multiplicar pela quantidade para Obter o Valor ....Qq que seja a precisão
no caso de dizimas periodicas quase sempre vc terá problemas

Ora se estas Tabelas estão Relacionadas como voce mesmo disse é so
pegar o Campo Total da Tabela Mestre que deve estar sendo retornado por algum DataSet ... Mas mesmo que o Select se Faça necessário , voce pode Obter o TOTAL usando um join entre essas tabelas que se relacionam


Responder

23/08/2008

Godzilla_xf

Olá, vc poderia tentar substitur os campos Numeric po DOUBLE PRECISION, eu uso assim, veja se da certo.

espero que ajude. té +++


Responder

23/08/2008

Marco Salles

Olá, vc poderia tentar substitur os campos Numeric po DOUBLE PRECISION, eu uso assim, veja se da certo


bem pensado ...o double precision fica no formato digamos assim do BDE
se quiser apresentar o resultado em duas casas pode-se usar como eu disse antes , o envento OnGetText . Se aumentar tb a Precisão do Campo de numeric vc terá o mesmo efeito

em ambas as situção não precisa atualizar o DbExpress <acredito eu>..


Responder

24/08/2008

Catunda

Eu sugiro que vc deixe de lado esse dialeto 1.
Ele me tirou muitas noites de sono devido esse problema.
Passei todos os meus sistemas pra dialeto 3 com o numeric(15,2) e não tive mais dor de cabeça com isso.


Responder

24/08/2008

Marco Salles

O Dialetos ´existem´ para manter compatibilidade aos novos recursos dos padrões definidos para o SQL que são incorporados as novas versões dos
Bancos . De fato houve uma mudança nos tipos Numeric e Double Precision entre os Dialeto 1 e o Dileto 3 . Porém no caso do [b:f48ad2889f]igorcb[/b:f48ad2889f] , [u:f48ad2889f]´no meu entender´[/u:f48ad2889f] a mudança somente no Dialeto não ira resolver se ele continuar mantendo a precisão do [b:f48ad2889f]Campo Numerico [/b:f48ad2889f], ou não usar um campo [b:f48ad2889f]Double precision [/b:f48ad2889f], como fora lembrado pelo [b:f48ad2889f]GodZilla_XF[/b:f48ad2889f]..


Responder

25/08/2008

Igorcb

pessoal, obrigado pelos os posts, jah me tiraram varias duvidas, achei que isso fosse problema dos tipos de conexoes, pelo o visto o problema realmente eh no banco de dados, entao vou fazer mais testes aki e volto com os resultados.

flw


Responder

Assista grátis a nossa aula inaugural

Assitir aula

Saiba por que programar é uma questão de
sobrevivência e como aprender sem riscos

Assistir agora

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar