Sim realmente como as tabelas são pagas ai se você mesmo oferecer elas ‘diretamente’ no seu sistema, pode correr o risco de, ao fazer isso, ser taxado como pirataria.
Mas esta ok, qualquer coisa se precisar estamos por aqui, boa sorte e sucesso ai no seu projeto.
Valeu pessoal.
Acabou que achei isso aqui: http://dbfconv.com/
Vou orientar o usuário a converter por aqui que é uma ferramenta gratuita e pronto…
Trabalho com harbour / dbf, sendo que cada tabela têm portabilidade de 16 TB.
O ERP em harbour têm 300 tabelas, que foram sendo desenvolvidas nestes últimos 27 anos de desenvolvimento.
Nos últimos anos adotei o PostgreSQL para construir um novo ERP, agora com o SC, e a questão também é como converter os dados dos DBF’s para PostgreSQL ?
Desenvolvi um .PRG que lê tabela por tabela e grava um CSV pronto para usar pelo COPY no psql.
No PostgreSQL este ERP foi para pouco mais de 450 tabelas. Algumas tabelas DBF acabaram ficando em várias tabelas no PostgreSQL, e este “tratamento” para exportar os dados dos DBF’s foi feito neste .PRG que desenvolvi. No BD do PostgreSQL criei as tabelas aproveitando o que o mesmo oferece, e os recursos que vou utilizar junto ao SC, então, não há como importar da forma como estão, assim evitamos de deixar de usar recursos que o SC oferece.
Já importei para DBF dados dos mais diversos banco de dados, e o que aprendi nisto é que as informações contidas em um banco de dados devem ser estudas e exportadas da melhor forma possível. Não há milagres, vai ter trabalho para fazer isto, e entender como o BD foi criado é a forma de entender como usar estes dados.
Já fiz importação de dados de empresas importantes onde a estrutura de suas tabelas, mesmo que em SGBD é uma vergonha.
Minha primeira linguagem, em 1991 foi Clipper… to enferrujado pra caramba, mas acho que pegando meus antigos livros consigo montar alguma coisa também kkkkk
Mas esses conversores atendem, valeu…
Sim ai eu adaptei a frase:
“Vão-se os anéis e ficam os dedos” para “Vão-se os anéis e ficam os bancos de dados”.
Iniciei no dbase III plus em 1989/1990, depois clipper summer, clipper 5.x, FlagShip, Harbour, …
Jocimar,
Comecei em 1984 com dBase II e por aí vai… por conta disto foi que criei o DBF2SQL que é um aplicativo que migra os DBFs para MySQL ou PostgreSQL, pra facilitar qualquer migração.
Hahaha só velha guarda por aqui…
Eu baixei o dbf2sql… boa ferramenta.
Já usei Carlos e indico o dbf2sql.
Obrigado Kleyber
Kleyber já brincou até com o ‘ENIAC’. heeheh
kkkkkkkkkkk é bem por aí mesmo… rsrs
O fato de não utilizar outro aplicativo está em “modernizar” a estrutura das tabelas no SGBD, que no meu caso é no PostgreSQL, e não no recurso de fazê-lo “acontecer”. Desenvolvi meu aplicativo para exportar os dados, já fazendo o tratamento para as mudanças feitas no PostgreSQL em vez de utilizar a mesma estrutura que estavam nos DBF’s.
No caso do dbf2sql não consigo entender como ele poderia fazer isto para mim, mesmo que a finalidade como explicado pelo amigo Kleyber seja a de migrar para os 2 banco de dados os dados dos dbf’s, conservando a estrutura dos dbf’s, e depois fazer o tratamento nas tabelas.
Parabéns Kleyber pelo app, pois achei no passado distante referências a ele.
Nas bases legadas DBF que importei eu importava as tabelas e campos inteiras igual estavam em DBF, depois no programa de modelagem de SGDB vou alterando e guardando as ‘META-DADOS’ das alterações,
e quando vejo que já esta certo, crio o script dentro do SC em um form controle que vai executar essas sequências de ‘META-DADOS’ e outras adaptações conversões para normalizar
totalmente a Base de dados antiga no novo padrão exemplo MySQL, migrei 3 clientes antigos que usavam DBF e um MS-ACCESS97 e hoje já rodam anos, claro que com atualizações melhorias, etc
que sempre vamos fazendo.
E faço esse script automático, porque até migrar tudo o cliente não pode parar, ai vou sempre pegando os dados antigos e recolocando no sistema novo e fazendo testes com o cliente, se
esta tudo certo, conforme funcionava no sistema legado, quando esta pronto, só pegar os DBF antigo e colar rodar o script e já liberar para o cliente.
Beleza Mr. Jailton!
Bom compartilhar experiências!
Como experiência a informar, já importei de outros sistemas base de dados também em dbf, access, firebird, mysql, cobol, ms-sql, dataflex e foram de diversas empresas nestes outros formatos, e nestes casos usei “ferramentas” para gerar arquivos csv ou arquivo texto de tamanho fixo, e a importação para minha base de dados foram tratadas campo a campo.
Já no caso do meu ERP, não havia necessidade de todo este trabalho, assim desenvolvi meu próprio .PRG para fazer a exportação para a nova estrutura em PostgreSQL com as novas definições das tabelas, afinal, para que sofrer fazendo manualmente aquilo que pode ser automatizado.
É isso aí, Jailton!!
Scriptcase roda maravilhosamente bem em OS X também…