Um select com Float, duas respostas

[Ignez 0]

Colegas, bom dia.Estou enfrentando uma situação muito estranha ao executar uma pesquisa no SQL Server, tanto no 2000 como no 2005. Temos uma tabela de cadastro, cuja chave primária é um campo do tipo FLOAT. Quando executo um select neste campo, as respostas que obtenho são:select ChavePK from Cadastro where ChavePK = 264345971717545.0 ChavePK ---------------------- 264345971717545 (1 row(s) affected)select ChavePK from Cadastro where ChavePK = 264345971717545 ChavePK ---------------------- 264345971717545 (1 row(s) affected)select ChavePK from Cadastro where ChavePK = 8247415505401535.0 ChavePK ---------------------- (0 row(s) affected)select ChavePK from Cadastro where ChavePK = 8247415505401535 ChavePK ---------------------- 8,24741550540154E+15 (1 row(s) affected)Observem que o primeiro e segundo select utilizam o mesmo valor, com a diferença apenas do .0 no final. O terceiro e quarto select também se diferenciam pelo .0 no final do valor. Porém, o terceiro select não retorna a linha. Será que alguém tem alguma idéia do por quê isso ocorre? Ter o .0 no final não deveria influenciar na pesquisa, já que o 1º select utiliza esta dado.Agradeço antecipadamente qualquer ajuda! Ignez

[jothaz 1]

Camarada,

 

Usar Float com PK não sei se é um boa prática.

E não sei se é a melhor abordagem.

Na minha humilde opinião seria melhor gerar um ID (auto-incremento) com chave e usa o valor float como atributo.

 

Porém sei que muitas vezes não é possível alterar o que foi modelado mas é um item a se pensar.

 

Nunca passei por uma situação desta (na verdade a área de AD aqui do serviço nunca permitiria esta modelagem) mas tente assim:

select ChavePK from Cadastro where CONVERT(VARCHAR(15),ChavePK) = '264345971717545.0'

Nem tive tempo de testar mas talvez o CONVERT lhe ajude.

 

t+

[Ignez 0]

Jothaz, bom dia.Obrigado pela rápida resposta. Infelizmente, trata-se de uma base antiga. O problema, na verdade, são problemas:1) Não posso mudar o datatype deste campo.2) O problema ocorre na pesquisa do BD do cliente A, mas a mesma pesquisa no cliente B é executada corretamente.O X desta questão é porque o 3º SELECT não reconhece o valor da cláusula WHERE. Alguma idéia?Obrigada,Ignez

[jothaz 1]

Camarada,

1) Não posso mudar o datatype deste campo.

Suspeitava desde o principio. http://forum.imasters.com.br/public/style_emoticons/default/grin.gif Realmente este tipo de mudança causa uma certa apreensão.Mas a sugestão foi só pq as vezes é melhor retroceder alguns passos e tomar a direção correta do que enveredar por um caminho sem volta. E por favor não tome isto como uma critica é somente um ponto de vista de alguém que já passou vário apuros por para contornar inocorreçoes nao modelagem. Mas lembre-se cada caso é um caso e o bom-senso e a necessidade são os melhores guias.Portanto a opção de mudar a modelagem esta descartada.

2) O problema ocorre na pesquisa do BD do cliente A, mas a mesma pesquisa no cliente B é executada corretamente.

você testou o CONVERT com sugeri no post anterior? Se não testou tenha a bondade de testar e reportat qual o retorno.Fico no aguardo.Vou efetuar uns testes e qq novidade posto ai.E vamos esperar que os amigos aqui do fórum façam suas sugestões.No mais de nada e qq coisa estamos ai.t+

[eriva_br 7]

Olá Ignez,

 

Usar Float com PK não sei se é um boa prática.

concordo com o mestre jothaz

 

já peguei bases com valores monetarios definidos como float, quase tive um infarto .... como PK então eu me mataria ...kkkk zoeira

 

Mas a sugestão foi só pq as vezes é melhor retroceder alguns passos e tomar a direção correta do que enveredar por um caminho sem volt

creio que essa seja a melhor opção, vale a pena estudar isso antes para que tu não venha a ter mais problemas ainda...

 

veja a definição do tipo float no books online:

float and real

Approximate number data types for use with floating point numeric data. Floating point data is approximate; not all values in the data type range can be precisely represented.

se não tiver jeito msm, tenta converter para o tipo: BIGINT, testei aqui com os valores que tu postou e funcionou, veja:

set nocount ondeclare @tabPK table (ChavePK float)insert @tabPK (ChavePK) values (264345971717545)insert @tabPK (ChavePK) values (8247415505401535)select ChavePK from @tabPK where CONVERT(bigint,ChavePK) = 264345971717545.0select ChavePK from @tabPK where CONVERT(bigint,ChavePK) = 264345971717545select ChavePK from @tabPK where CONVERT(bigint,ChavePK) = 8247415505401535.0select ChavePK from @tabPK where CONVERT(bigint,ChavePK) = 8247415505401535

 

 

jothaz, convertendo para varchar ele ficou com um valor muito louco: "8.24742e+015"

 

 

 

t+

abs

[Ignez 0]

Caros colegas,

 

Novamente, obrigada pela ajuda.

 

Fiz os testes conforme vocês orientaram, e realmente consigo o retorno do SELECT . O problema é que este código existe em várias rotinas do sistema, e em apenas no BD de um cliente específico não retorna os dados.

 

Infelizmente, eu não posso solicitar a modificação do código do SELECT :( , conforme as sugestões postadas anteriormente, porque o problema é pontual, em apenas um cliente. Eu preciso descobrir o que pode ter acontecido no banco de dados deste cliente, que o diferencia dos outros clientes, onde a rotina não apresenta o problema.

 

Resumindo, a pergunta de um milhão de dólares é: Existe alguma configuração, função, magia, promessa, etc http://forum.imasters.com.br/public/style_emoticons/default/blush.gif que pode ter sido aplicada ao banco de dados do cliente A e faça com que o select não retorne resultado, já que o mesmo SELECT executa corretamente no BD dos clientes B, C, D, E .... Z?! http://forum.imasters.com.br/public/style_emoticons/default/grin.gif

 

Abraços,

 

Ignez

[eriva_br 7]

Resumindo, a pergunta de um milhão de dólares é: Existe alguma configuração, função, magia, promessa, etc http://forum.imasters.com.br/public/style_emoticons/default/blush.gif que pode ter sido aplicada ao banco de dados do cliente A e faça com que o select não retorne resultado, já que o mesmo SELECT executa corretamente no BD dos clientes B, C, D, E .... Z?! http://forum.imasters.com.br/public/style_emoticons/default/grin.gif

tenta ver quais as diferenças nos bancos, executa a sp_helpdb neles, e compare as informações:

sp_helpdb pubs

verifique também se as configurações regionais, e se os Service Packs do windows e do SQL Server estão iguais em ambos servidores

 

 

t+