PC Toledo

Acabo de ver um problema inusitado (pelo menos pra mim) e embora já tenha resolvido, resolvi compartilhar.

Usando o "DBU32" (e depois o DBUALL, ambos oferecidos por nosso amigo Jairo Maia), ao alterar o nome de um campo caracter, houve corrupção de dados e aumento do número de registros. Com imagens ficará mais fácil visualizar:

Estava assim... ... e ficou assim! Notem que nos 2 casos o posicionamento é no primeiro registro e no mesmo campo. Notem também o total de registros. Só o que fiz foi alterar o nome do campo, de CLIE_CPF para CLIE_DOC1. Como sempre, o DBU confirma a intenção de alterar o nome do campo, executa sem apresentar erros, mas o resultado final fica comprometido. Repeti 3 vezes, restaurando o DBF original, e aconteceu a mesma coisa em todas as tentativas.

Ainda pior, alguns registros abaixo: Não me lembro de ter visto algo assim. Por outro lado, não me lembro quando foi a última vez que alterei o nome de um campo.

Surpreso com o ocorrido, a primeira solução em que pensei foi escrever uma pequena rotina que criaria um novo campo (CLIE_DOC1), copiaria as informações do antigo campo (CLIE_CPF) e depois excluiria esse antigo campo (CLIE_CPF). Mas antes resolvi usar o excelente STRU, oferecido por nosso amigo Pablo César, e funcionou perfeitamente!

Estou curioso... alguém já viu este problema com o DBU, mesmo que compilado pelo Clipper?

Um dia depois, acabo de testar usando a "versão original" do DBU (Clipper) numa máquina com XP: o problema é o mesmo!

Será um bug que atravessou o tempo?

Não vi os código do DBU32 nem do DBUALL, mas acredito que a metodologia de importação de dados são diferentes ao que eu usei com o STRU.

O primeiro registro, até que vem mas quase que certo, mas isso porque procura o nome do campo e vai substituindo em sequência, mas ao final do ultimo campo, o sistema não encontra e desloca pro próximo campo a direita campo e como o seu primeiro campo é do tipo DATA (date) ele se perde por completo. Experimenta transformar tudo em tipo caractere verá o deslocamento.

Isto é normal, tanto em Clipper como em Harbour. Tudo dependerá da metodologia de importação que você irá empregar.

Aproveita o código do STRU e analise o que eu fiz. Eu previ que os nomes dos campos podem ser alterados como também o tipo do campo (não no seu caso aqui). Não sei se você utilizou alguma vez o DBase, quando você altera o nome, ele pergunta se importa mesmo com o nome mudado.

Pablo,

na verdade o primeiro campo desse DBF é numérico. Estas telas do DBU que postei estão deslocadas à direita. Mas o que você mencionou sobre o campo data pode ser igualmente aplicado.

Eu também não depurei nenhuma das 3 "versões" de DBU que usei, apenas fiquei surpreso com o resultado absurdo. Sim, dá pra imaginar porque ele faz essa bagunça, mas pense comigo: aí está um bug que, aparentemente, passou batido ao longo do tempo! Um programa histórico, prestigiado e amplamente utilizado por tanta gente ao longo de tantos anos e até hoje, apresenta um erro bobo e banal! Se pensarmos em tudo o que o DBU oferece e executa com perfeição, esse bug é bizarro, surreal!

E como eu disse, esse é o tipo de problema de fácil solução, com um pequena rotina. Mas resolvi compartilhar porque pode chamar a atenção e ser útil para outras pessoas. Por outro lado, antes de escrever a rotina, resolvi experimentar o seu STRU e adorei: além de bonito e funcional, fez o que eu queria com rapidez e eficiência!

Parabéns e muito obrigado... eu recomendo o STRU!

bom dia

esses stru é um exe fontes ou o que ?

poderiam disponibilizar para verificar

ob

Paiva

Bom dia Paiva,

foi tudo disponibilizado por nosso amigo Pablo César na nossa seção de Downloads:
https://pctoledo.org/forum/fileba ... t=c&page=1

Quando eu citei o STRU na minha primeira mensagem eu informei o hyperlink, acho que você não notou.

Abs!