Autor
Mensagem
Postado em: 25/5/2011 09:22:37 AM
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
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
Postado em: 25/5/2011 10:17:51 AM
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.
nunca vi isso trabalho ha 7 anos com o firebird.
posta a imagem da tela.
Postado em: 25/5/2011 10:43:20 AM
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?
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?
Postado em: 25/5/2011 11:16:03 AM
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
Postado em: 25/5/2011 11:24:28 AM
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.
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.
Postado em: 25/5/2011 11:26:56 AM
tenta com o IBExpert e tenta fazer essa migração que vc falou, dando o update
Postado em: 25/5/2011 11:34:49 AM
No IBExpert ele ja trouxe o valor sem a dizima ja veio 34,90 o que pode ser então?
Alguma idéia?
Alguma idéia?
Postado em: 25/5/2011 11:44:51 AM
Citação:
No IBExpert ele ja trouxe o valor sem a dizima ja veio 34,90 o que pode ser então?
Alguma idéia?
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
Postado em: 25/5/2011 11:59:47 AM
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.
No IBExpert aconteceu o mesmo..acredito que estava correto mas não está não.
Postado em: 25/5/2011 12:08:06 PM
altera o DOMAIN desse campo, ali na opção de editar DOMAIN
Postado em: 25/5/2011 12:31:35 PM
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?
Agora isso pode ser porque é um banco que foi criado no interbase?
Postado em: 25/5/2011 01:58:25 PM
Citação:
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?
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?
Postado em: 25/5/2011 02:39:35 PM
Uso o Dialect 1
Postado em: 25/5/2011 02:49:15 PM
Citação:
Uso o Dialect 1
Uso o Dialect 1
to achando que o problema vai ser isso
Citação:
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.
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.
Postado em: 25/5/2011 03:04:29 PM
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.
Postado em: 25/5/2011 03:19:41 PM
Citação:
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.
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....
Postado em: 25/5/2011 03:25:28 PM
Citação:
vc cria como DATE, mas vc reparo que, quando mostra ali no IBExpert e no SQL Manager ele mostra com o formato timestamp....
Citação:
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.
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
Postado em: 25/5/2011 03:31:51 PM
Citação:
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
Citação:
vc cria como DATE, mas vc reparo que, quando mostra ali no IBExpert e no SQL Manager ele mostra com o formato timestamp....
Citação:
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.
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
Postado em: 25/5/2011 03:53:03 PM
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.
Postado em: 25/5/2011 04:27:01 PM
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'
Postado em: 25/5/2011 04:31:20 PM
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?
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?
Postado em: 25/5/2011 05:04:02 PM
Citação:
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 faloAhh 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?
Postado em: 25/5/2011 05:15:07 PM
É 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.
Obrigado por tirar todas as minhas duvidas e tenha uma ótima Tarde.
Postado em: 26/5/2011 09:29:36 AM
amigo tenta assim, qualquer coisa me fala
Trocar o "Dialect" de 1 para 3 ::
gfix banco -sql_dialect 3 -user SYSDBA -password masterkey
#Código
Trocar o "Dialect" de 1 para 3 ::
gfix banco -sql_dialect 3 -user SYSDBA -password masterkey
