DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

Fórum DevMedia


Autor
Mensagem
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 9: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
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 10:17:52 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.

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 10:43:21 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?

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 11:16:04 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

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 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.

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 11:26:57 AM
tenta com o IBExpert e tenta fazer essa migração que vc falou, dando o update

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 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?

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 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?


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

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 11:59:48 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.

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 12:08:07 PM
altera o DOMAIN desse campo, ali na opção de editar DOMAIN






 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 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?

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 1: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?


vc ta usando qual DIALECT?

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 2:39:35 PM
Uso o Dialect 1

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 2:49:15 PM

Citação:
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.

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 3: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.

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 3:19:42 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.



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

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 3:25:28 PM

Citação:

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.



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

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 3:31:51 PM

Citação:

Citação:

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.



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

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 3:53:04 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.

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 4:27:02 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'




 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 4:31:21 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?

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 25/5/2011 5:04:03 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 falo

 
Leandro Santos
 

País: Brasil
Estado: SP
Cidade: Mogi das Cruzes
Mensagens: 25
 Postado em: 25/5/2011 5:15:08 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.

 
rafmattos
 
 


País: BRASIL
Estado: MS
Cidade: Campo Grande - MS
Mensagens: 440
 Postado em: 26/5/2011 9:29:37 AM
amigo tenta assim, qualquer coisa me fala

#Código

Trocar o "Dialect" de 1 para 3 ::
gfix banco -sql_dialect 3 -user SYSDBA -password masterkey


 
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2013 - Todos os Direitos Reservados a web-03