Autor
Mensagem
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
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.
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.
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....
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
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
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'
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?









