Duvida com campos Numeric(15,2)

Firebird

25/05/2011

Bom dia pessoal.
Estou procurando uma explicação e até agora não encontrei.
Defini no meu banco de dados campos numeric(15,2) quando fui acessar reparei que os valores estavam com dizima ai me surgiu a duvida, um campo numeric(15,2) não deveria conter 15 digitos antes da virgula e somente 2 no caso um valor de 33,33 e não 33,3300018310547.
Por favor se estiver errado me corrijam como esse campo deve ser usado? Isso é um bug do firebird? porque no sql server não tenho esse problema.
E até onde conheço ele deveria respeitar os 2 campos e fazer o arredondamento caso venha alguma dizima correta?
Agora o que fazer?
Desde ja Obrigado pela ajuda.
Leandro Santos
Leandro Santos

Leandro Santos

Curtidas 0

Respostas

Rafael Mattos

Rafael Mattos

25/05/2011

como vc ta vendo esse valor, vc ta dando um select ou um SUM alguma coisa?
nunca vi isso trabalho ha 7 anos com o firebird.
posta a imagem da tela.
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Segue abaixo a Imagem:

Porém me surgiu um outra duvida agora, o mecanismo de acesso ao banco poderia estar ocasionando este bug? O dialeto do banco poderia estar influenciando nisso tambem?
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011



pode ser esse RDB$262 que não ta com as casas certa
vc alterou o tipo desse campo? ultimamente?





faz esse update aqui

update RDB$FIELDS set
RDB$FIELD_SCALE = -2,
RDB$FIELD_PRECISION = 15
where RDB$FIELD_NAME = 'RDB$262'

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

se não resolver faz o backup restore
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Este comando não resolveu o problema, não foi feito nenhum tipo de alteração, esse campo existe desde a criação do banco e um backup e restore não resolve o problema tambem.
Nem se eu criar um campo novo do tipo numeric(15,2) e migrar o valor do campo antigo para o campo novo não resolve.
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

tenta com o IBExpert e tenta fazer essa migração que vc falou, dando o update
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

No IBExpert ele ja trouxe o valor sem a dizima ja veio 34,90 o que pode ser então?
Alguma idéia?
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

No IBExpert ele ja trouxe o valor sem a dizima ja veio 34,90 o que pode ser então?
Alguma idéia?


talves seja o SQL Manager, essa é a ultima versão dele? talves ele esteja com problema.
é q sempre usei o IBExpert
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Na verdade não é não veja só a imagem abaixo:

No IBExpert aconteceu o mesmo..acredito que estava correto mas não está não.
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

altera o DOMAIN desse campo, ali na opção de editar DOMAIN





GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Nada altera o Domin o tamanho do campo numeric para 9,2 e nada de resolver.
Agora isso pode ser porque é um banco que foi criado no interbase?
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

Nada altera o Domin o tamanho do campo numeric para 9,2 e nada de resolver.
Agora isso pode ser porque é um banco que foi criado no interbase?


vc ta usando qual DIALECT?
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Uso o Dialect 1
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

Uso o Dialect 1


to achando que o problema vai ser isso



DIALETO 1
Usando o dialeto 1, as características de transição se comportam como no Interbase 5:
Constantes alfanuméricas podem ser delimitadas por aspas simples e duplas. O dialeto 1 não reconhece
identificadores delimitados.
O tipo DATE não está disponível, mas é substituído pelo tipo TIMESTAMP, que contém informações sobre
data e hora. Quando um banco de dados versão 5 é gravado/restaurado na versão 6, os campos DATE são
automaticamente atualizados para o tipo TIMESTAMP.
Os tipos DECIMAL e NUMERIC com precisão maior que 9 são gravados como ponto flutuante.

------------
DIALECT 2
Os Clientes podem ser configurados para utilizar o dialeto 2. Nesse modo, eles reportam erros quando
encontram aspas duplas, tipos DATE, ou campos NUMERIC/DECIMAL com precisão maior que 9. Esse
dialeto é utilizado para alertar o desenvolvedor para potenciais problemas durante a migração e não deve ser
utilizado para uso normal no dia a dia. Para detectar áreas problemáticas na definição de um banco de dados
que você está migrando, extraia a METADATA e rode-a através de um cliente utilizando o dialeto 2. Por


exemplo :

isql -i v5metadata.sql
Lembre-se de NÃO utilizar o dialeto 2 para uso normal dos bancos de dados.


----------------------
DIALETO 3
As seguintes características são específicas do DIALETO 3, e são incompatíveis com o dialeto 1 e todos os
BDs e clientes antigos:
Constantes alfanuméricas devem ser delimitadas por aspas simples (apóstrofe). Aspas duplas (") são usadas
somente em identificadores delimitados.
O tipo de dado DATE armazena somente a DATA. Dois novos tipos de dados estão disponíveis : TIME que
armazena somente a informação de HORA, e TIMESTAMP que armazena ambos DATA e HORA. O tipo
TIMESTAMP substitui a funcionalidade do tipo DATE das versões anteriores do IB. O Dialeto 3 também
inclui os operadores funcionais CURRENT_DATE, CURRENT_TIME, e CURRENT_TIMESTAMP.
Tipos DECIMAL e NUMERIC com precisão maior que 9 são gravados utilizando inteiros de 64 bits se
forem criados no dialeto 3. Note que todas os campos desse tipo continuam sendo armazenados como float
se o BD foi trazido de alguma versão anterior do IB.
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Bem provavel que seja isso então, agora o estranho é que na hora de criar um campo data como está nas informações que vc passou o IBExpert não disponibiliza a opção timestamp e sim somente date que armazena data e hora sendo que ele reconhe meu banco omo dialect 1.
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

Bem provavel que seja isso então, agora o estranho é que na hora de criar um campo data como está nas informações que vc passou o IBExpert não disponibiliza a opção timestamp e sim somente date que armazena data e hora sendo que ele reconhe meu banco omo dialect 1.



vc cria como DATE, mas vc reparo que, quando mostra ali no IBExpert e no SQL Manager ele mostra com o formato timestamp....
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Bem provavel que seja isso então, agora o estranho é que na hora de criar um campo data como está nas informações que vc passou o IBExpert não disponibiliza a opção timestamp e sim somente date que armazena data e hora sendo que ele reconhe meu banco omo dialect 1.



vc cria como DATE, mas vc reparo que, quando mostra ali no IBExpert e no SQL Manager ele mostra com o formato timestamp....


Repara no campos DT_CR_PEDIDO ele está com formato que seria de timestamp, porém quando eu crio sou obrigado a criar com DATE e nas propriedades do campo está como DATE ele não mostra TIMESTAMP
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

Bem provavel que seja isso então, agora o estranho é que na hora de criar um campo data como está nas informações que vc passou o IBExpert não disponibiliza a opção timestamp e sim somente date que armazena data e hora sendo que ele reconhe meu banco omo dialect 1.



vc cria como DATE, mas vc reparo que, quando mostra ali no IBExpert e no SQL Manager ele mostra com o formato timestamp....


Repara no campos DT_CR_PEDIDO ele está com formato que seria de timestamp, porém quando eu crio sou obrigado a criar com DATE e nas propriedades do campo está como DATE ele não mostra TIMESTAMP


mas vc viu q isso é do IB e do MANAGER, ele ta considerando como DATE, isso na hora de criar

mas na hora de visualizar ele fica como TIMESTAMP
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Da uma olha ele tambem mostra como DATE o tipo, não que critério ele ta usando o dado ele mostrar timestamp mas tanto no meu sistema quanto nos consoles gerenciadores (IB,MANGER) ele mostra como está na figura.
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011


o que eu to tentando te dizer é que por estar com DIALECT 1, ali no IB ou no SQLMANAGER, ele se mostra como DATE, pq ele é só um gerenciador, na hora de vc criar ele vai aceita vc colocar DATE.

mas depois na hora que vc vai ver internamente ele na verdade está com TIMESTAMP, olha o formato de um DATE para um formato de TIMESTAMP

DATE           = 'dd.mm.yyyy'
TIMESTAMP = 'dd.mm.yyyy hh:ss'



GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

Ahh ta entendi....
Agora, vc teria alguma idéia de como posso resolver este tipo de problema com o campo numeric?
Será que mudando o dialec da banco para 3 resolveria?
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

Ahh ta entendi....
Agora, vc teria alguma idéia de como posso resolver este tipo de problema com o campo numeric?
Será que mudando o dialec da banco para 3 resolveria?
sim, pq trabalho com a 3 e não ocorre isso. agora a questão de mudar de DIALECT não é tão simples assim. vou dar uma pesquisada depois qualquer coisa que eu achar eu te falo
GOSTEI 0
Leandro Santos

Leandro Santos

25/05/2011

É eu andei caçando e realmente não é coisa simples, se achar algo por favor, poste aqui.
Obrigado por tirar todas as minhas duvidas e tenha uma ótima Tarde.
GOSTEI 0
Rafael Mattos

Rafael Mattos

25/05/2011

amigo tenta assim, qualquer coisa me fala

Trocar o "Dialect" de 1 para 3 ::


gfix banco -sql_dialect 3 -user SYSDBA -password masterkey

GOSTEI 0
POSTAR