Array
(
)

Campo origem decimal não aparece como tal no SQL

Jorgeolimpia
   - 13 dez 2004

Olá pessoal, tudo bem?
Estou com o seguinte problema:
tenho em uma tabela-origem (arquivo do tipo ISAM / Cobol) que ligo ao meu banco de dados SQL através do ODBC.
Nas tabelas-origem onde tenho campos decimais (ex: taxafinanc = 1,30) o SQL mostra como destino somente o valor 1. Eu estou usando DTS para a cópia das informações, mas mesmo antes de realizar este processo o valor já está errado no SQL. Existe alguma função ou algo parecido que possa trazer este valor, mesmo que inteiro (130)?
Obrigado pelas dicas.
Abraços...

Jorgeolimpia
   - 15 dez 2004

Caros amigos,
só para acrescentar, fiz um teste importando os mesmos dados do ODBC para uma planilha do Excel (Dados / Importar Dados Externos / Importar Dados) e, pasmem, os valores vieram corretos!!!
Realmente ficou mais difícil saber o que acontece, mas estou vasculhando... Espero que um de vocês encontrem a resposta para este enigma também.
Agradeço pelas dicas.

Citação:
Olá pessoal, tudo bem?
Estou com o seguinte problema:
tenho em uma tabela-origem (arquivo do tipo ISAM / Cobol) que ligo ao meu banco de dados SQL através do ODBC.
Nas tabelas-origem onde tenho campos decimais (ex: taxafinanc = 1,30) o SQL mostra como destino somente o valor 1. Eu estou usando DTS para a cópia das informações, mas mesmo antes de realizar este processo o valor já está errado no SQL. Existe alguma função ou algo parecido que possa trazer este valor, mesmo que inteiro (130)?
Obrigado pelas dicas.
Abraços...


Jorgeolimpia
   - 16 dez 2004

Olá pessoal, tudo bem?
Bom, não teve jeito, tive que apelar... mas consegui dar um jeito de puxar o valor correto no SQL e vou explicar a vocês como fiz isso.

Na versão do Cobol que usamos aqui na empresa (AcuCOBOL) existe uma definição para campos numéricos, que são de que todos eles tem o formato FLOAT. Quando criamos a FD (file description) de um arquivo, definimos o campo numérico da seguinte maneira:
VALOR_R$ 9(011)V99
Isso significa que o campo é numérico com 11 posições e o seu ponto flutuante fica nos dois últimos campos.
Dentro do arquivo criado o valor deste campo é como um número inteiro mas na exibição deste em qualquer programa (COBOL) associado a este arquivo é entendido como um campo decimal.
Quando queremos fazer a conexão deste arquivo COBOL com um banco de dados, utilizamos um driver ODBC para isso e este driver irá se conectar a uma outra FD, que chamamos de XFD(eXtension File Description), que informa para qualquer banco de dados quem são os campos, tamanhos, etc... Seguindo o exemplo do campo criado na FD, dentro da XFD ele aparece da seguinte maneira:
00036,00011,01,00011,-02,000,000,VALOR_R$
Aqui, nos campos que estão após a 3a. e 4a. vírgula são referentes ao tamanho do campo, só que reparem neste -02, que é semelhante ao V99. No Excel, o seu importador entende que este -02 é referente ao ponto flutuante do campo mas no SQL ele ´corta´ esta parte do campo quando usamos o DTS para importá-lo. Como não encontrei outra solução a saída foi deixar este campo -02 como +00 e dentro da DTS dividir este valor inteiro por 100.

Bom, eu não entendi o motivo de o SQL não pegar este campo como deveria mas se alguém souber de uma dica que possa sanar este problema de forma menos ´traumática´ serão bem vindas!

Obrigado pela atenção de todos e até a próxima.

Citação:
Caros amigos,
só para acrescentar, fiz um teste importando os mesmos dados do ODBC para uma planilha do Excel (Dados / Importar Dados Externos / Importar Dados) e, pasmem, os valores vieram corretos!!!
Realmente ficou mais difícil saber o que acontece, mas estou vasculhando... Espero que um de vocês encontrem a resposta para este enigma também.
Agradeço pelas dicas.

Citação:
Olá pessoal, tudo bem?
Estou com o seguinte problema:
tenho em uma tabela-origem (arquivo do tipo ISAM / Cobol) que ligo ao meu banco de dados SQL através do ODBC.
Nas tabelas-origem onde tenho campos decimais (ex: taxafinanc = 1,30) o SQL mostra como destino somente o valor 1. Eu estou usando DTS para a cópia das informações, mas mesmo antes de realizar este processo o valor já está errado no SQL. Existe alguma função ou algo parecido que possa trazer este valor, mesmo que inteiro (130)?
Obrigado pelas dicas.
Abraços...