Jump to content
Fivewin Brasil

Migrando o dbf para sql


edutraini

Recommended Posts

Boa tarde, Pessoal 

Gostaria de opinao do forum a respeito da conversao de dbf para sql

Se alguem fosse comecar do zero a migrar um sistema de Dbf para Sql 

Usaria o lib externa Sqllib ou iria direto usando o proprio fivewin com as novas funcoes mariadb.

Pois pelo pesquisei a sqllib ja esta descontinuada nao sei se fazer a conversao usando ela seria a melhor solucao.

Talvez mais para frente teria que mudar novamente.

 

 

Link to comment
Share on other sites

 

Boa tarde, Pessoal 

Gostaria de opinao do forum a respeito da conversao de dbf para sql

Se alguem fosse comecar do zero a migrar um sistema de Dbf para Sql 

Usaria o lib externa Sqllib ou iria direto usando o proprio fivewin com as novas funcoes mariadb.

Pois pelo pesquisei a sqllib ja esta descontinuada nao sei se fazer a conversao usando ela seria a melhor solucao.

Talvez mais para frente teria que mudar novamente.

 

 

Edu,

Se você quiser manter a mesma estrutura dos teus DBF e migrar direto pra MySQL ou PostgreSQL, podes usar o DBF2SQL que desenvolvi a tempos atrás e que funciona muito bem (acesse http://www.tkinformidia.net, opção DOWNLOADS).

Se porém tu queres começar do zero já diretamente no SQL, te aconselho a ir logo vendo os comandos SQL de um banco de dados relacional e procurando ver como se deve executar os comandos, pois os conceitos mudam, então uma boa opção nesse caso é usar as funções nativas do Fivewin pra usar com MariaDB (funcionam pra MySQL também).

Link to comment
Share on other sites

Olá,

A grande questão é: você vai migrar todo o sistema para comandos SQL, sem usar nada do DBF ( use arquivo, seek, etc.)? 
Em caso positivo, use as funções do FW ou do Harbour. Porém se o sistema é grande e não dá para migrar tudo, use a SqlLib que você migra para MySql em meio dia de serviço ( migrando as tabelas com o aplicativo que o Grande Kleyber desenvolveu ) e depois migre os pontos mais críticos até completar o processo. Aí fica mais fácil mudar para as funções nativas  do FW ou Harbour.

Link to comment
Share on other sites

Muito obrigado pela opiniao de todos

Mas realmente a opcao seria sqllib para poder migrar logo o sistema e depois mudando as rotina mais demoradas para comandos do sql 

Pois fica muito dificil mudar um sistema de DBF para comandos sql demora muito.

Imagine que vc tenha um sistema em DBF rodando nos seus clientes e começa a migrar para comandos sql ai o cliente pede alteracao no sistema,

ou seja vc teria que alterar em dois lugares, no sistema em dbf e depois o sql

Ai nao termina nunca.

 

 

Link to comment
Share on other sites

Bem, eu uso a SQLLIB até hoje, apesar de ter sido descontinuada e funciona bem. Só que uso com comandos SQL diretamente. Neste caso, meu conselho é que esqueças usar bancos SQL com comandos xBase, seja da SQLLIB ou outro qualquer, pois você não vai usar todo o poder que os comandos SQL tem. Então de fato, leva tempo pra você migrar um sistema em DBF para SQL, pois tem que entender os conceitos de um banco relacional.

Link to comment
Share on other sites

Edú

Boa noite

Este assunto já foi debatido e deve ter um monte de post's por aqui, mesmo assim vou dar meu pitaco, pq eu fiz isso há algum tempo atrás. Peguei um sistema e iniciei a migração de forma direta, sem me preocupar com alterações solicitadas pelo cliente. Tentei  utilizar algumas instruções SQL no inicio, porém, como eu percebi que estava ficando demorado,  resolvi usar os comandos XBASE para não ter problemas e posteriormente, após ter migrado todo o sistema, passar a utilizar as instruções SQL, então e fiz assim:

1o. Converti/Up-Load das tabelas para SQL (postgres), inicialmente tentei o Up-Load com o DBF2SQL, embora ele tenha feito td certo, não obtive êxito pq, como eu havia adquirido a SQLRDD, esta não acessava as tabelas, provavelmente por não ter os controles que ela cria para tal, então tive que criar a rotina de Up-Load na unha, o que não é tão difícil, a qual posso até disponibilizar pra vc.

2o, Após o Up-Load, alterei minha rotina de índice, fazendo com que estes fossem abertos conforme a conexão, se SQL abre/cria os índices de uma forma,  se DBFCDX/NTX, continua abrindo/criando da forma que estava.

3o. Veja que até aí eu não fiz nada de incrível, porém, caso vc tenha índices com cláusulas, terá que mudar , quando a conexão for SQL, criando os índices um a um como se fosse no NTX, caso contrário da forma do DBFCDX.

4o. Daí pra frente, é só definir as aberturas das tabelas de acordo com a Driver RDD e usar a vontade. Quando se sentir confiante, comece as alterações para instruções SQL da própria RDD e quando realmente tiver dominando, já poderá utilizar para SQL puro.

[]s,

 

 

 

Link to comment
Share on other sites

  • 3 months later...
 

Edú

Boa noite

Este assunto já foi debatido e deve ter um monte de post's por aqui, mesmo assim vou dar meu pitaco, pq eu fiz isso há algum tempo atrás. Peguei um sistema e iniciei a migração de forma direta, sem me preocupar com alterações solicitadas pelo cliente. Tentei  utilizar algumas instruções SQL no inicio, porém, como eu percebi que estava ficando demorado,  resolvi usar os comandos XBASE para não ter problemas e posteriormente, após ter migrado todo o sistema, passar a utilizar as instruções SQL, então e fiz assim:

1o. Converti/Up-Load das tabelas para SQL (postgres), inicialmente tentei o Up-Load com o DBF2SQL, embora ele tenha feito td certo, não obtive êxito pq, como eu havia adquirido a SQLRDD, esta não acessava as tabelas, provavelmente por não ter os controles que ela cria para tal, então tive que criar a rotina de Up-Load na unha, o que não é tão difícil, a qual posso até disponibilizar pra vc.

2o, Após o Up-Load, alterei minha rotina de índice, fazendo com que estes fossem abertos conforme a conexão, se SQL abre/cria os índices de uma forma,  se DBFCDX/NTX, continua abrindo/criando da forma que estava.

3o. Veja que até aí eu não fiz nada de incrível, porém, caso vc tenha índices com cláusulas, terá que mudar , quando a conexão for SQL, criando os índices um a um como se fosse no NTX, caso contrário da forma do DBFCDX.

4o. Daí pra frente, é só definir as aberturas das tabelas de acordo com a Driver RDD e usar a vontade. Quando se sentir confiante, comece as alterações para instruções SQL da própria RDD e quando realmente tiver dominando, já poderá utilizar para SQL puro.

[]s,

 

 

 

Jorge, boa tarde.

Eu vou precisar me curvar ao SQL, coisa que o Jackson sabe a quantos anos que venho relutando. Risos

Gostei muito desse seu cronograma e pretendo seguir exatamente esses passos. Adquiri o FWH18.01 e estou com o SQLRDD. Agora quero instalar o gerenciador do banco de dados Maria ou MySQL. Qual versão desses bancos devo instalar? Qual é o gerenciador de banco que devo usar? Peço que, por favor, me disponibilize o máximo de informações que puder. Obrigado.

Link to comment
Share on other sites

 

Jorge, boa tarde.

Eu vou precisar me curvar ao SQL, coisa que o Jackson sabe a quantos anos que venho relutando. Risos

Gostei muito desse seu cronograma e pretendo seguir exatamente esses passos. Adquiri o FWH18.01 e estou com o SQLRDD. Agora quero instalar o gerenciador do banco de dados Maria ou MySQL. Qual versão desses bancos devo instalar? Qual é o gerenciador de banco que devo usar? Peço que, por favor, me disponibilize o máximo de informações que puder. Obrigado.

Oscar, boa tarde

 

Por uma questão de aprendizado, eu instalei vários sgbds: Postgres, Mysql e Mssql, na epóca não instalei o MariaDb (Maria de bôa. ahauahuahau), pq não confiei muito por falta de divulgação. e ignorância.

Como vc sabe que eu migrei usando a SQLRDD, então para uso do MSsql, tem que utilizar uma conexão ODBC, mas diante dos resultados, desisti.

Com o Mysql e Postgres, tive resultados semelhantes, porém me sentir mais a vontade com o Postgres, inclusive com o uso do gerenciador PGADMIN, contudo, ambos são maravilhosos.

Sei que é do seu conhecimento que o FW já tem nativos ambos, mas aconselho a brincar, peque uma tabela que vc usa pra muitos relatórios, importe-a para o SGBD e abuse dos teste.

No inicio eu cometi um  erro Crasso,  após as aberturas das tabelas, submetia o comando DBSETINDEX("arquivo de indice"), que no caso do NTX seria a lista de arquivos de indices e no DBFCDX é um único arquivo, então, todas as vezes que eu abria as tabelas, eram criados todos os índices novamente, fazendo com que eu tivesse N's arquivos de índices nos controles. Do resto é só alegria

[]s,

 

Link to comment
Share on other sites

Ola, Boa noite

 

É o que venho falando pra ele a tempos para mudar para SQL, no inicio usei o MYSQL, pois aqui no forum era o que mais se comentava, mais hoje uso o POSTGRES, por ser mais robusto e considero muito melhor em escalabilidade do SGDB, digo escalabilidade em tamanho do SGDB, pois atualmente tenho um cliente que a base de dados ja esta em torno de 300 Giga, com tabelas com mais de 2 bi de registros, e qualquer consulta é mais rápida que um peido debaixo do lençol kkkkkkk...

Espero ter ajudado.

Link to comment
Share on other sites

Antes eu tivesse dado ouvidos a você Jackson, quando tinha a disposição da juventude, agora os 53 estão pesando e tenho que ir mais devagar. Risos

Bom, meu plano é o seguinte: - Minha aplicação é bem grande, então, no primeiro momento, eu quero mudar o quanto menos possível os meus PRGs e só depois ir mudando tudo para SQL. 

Para atingir esse objetivo, parece ser melhor eu usar no primeiro instante a lib SQLRDD e o banco MySQL que mais testado com essa LIB, estou certo? Posso usar todos os comandos que utilizo hoje com DBF/CDX usando SQLRDD se eu optar por PostGres? Qual banco funciona melhor com a SQLRDD?

 

Link to comment
Share on other sites

Pessoal, 

Estou rodando a minha aplicação inteira com SQLRDD, sensacional!!! Funciona quase tudo... quase tudo.

Quando eu uso o comando:

   _CtFil := DBFILTER()    // grava filtro atual

O SQLRDD retorna    A.`tipo`="R" 

Depois o comando:

   Set Filter To &_CtFil   // volta filtro anterior

Não funciona.

Obs. No DBFCDX esse mesmo comando retorna:   Field->tipo="R" e daí funciona.

Link to comment
Share on other sites

Ola,

 

Amigo Oscar, nem tudo é como queremos, existem algumas situações, que a melhor opção é mudar para o comando SQL, o que EU fiz foi o seguinte, me mudei para o escritorio do cliente e fui modificando tudo para SQL aquilo que era relevante para o sistema, levei em media 15 dias, isso fazendo alguns POGs.

O que você vai se maravilhar é com relatórios, nossa essa parte é muito show de bola em SQL, pode esquecer os MONTES DE DO WHILE... IF...ENDIF SKIP, LOOP

 

Espero ter ajudado

Link to comment
Share on other sites

Valeu a dica.

 

Vou trocar os comandos Set Filter por SR_SETFILTER. Pelo que notei será apenas trocar tirar os pontos do .AND. e do .OR. e o resto é igual no filtro. Esse comando aceita Field-> ou devo remover?

 

Aproveitando, notei que o SQLRDD usa MySQL 4.1 e Postgres 9.0 e o LocalWeb hospeda bancos nas versões:

MySQL 5.6: bases ilimitadas com até 1 GB cada (10 por site) 
PostgreSQL 9.5: bases ilimitadas com até 10 GB cada (3 por site) 

Vou ter problema com essas versões do LocalWeb?
 

Obrigado.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...