DBF pra MySQL

[JoséQuintas]

Eu ainda não sei como vou fazer o acesso simultâneo pesado, mas enquanto isso... fazer mais algumas alterações.
Até agora, passei pra MYSQL e eliminei de DBF, mas.... chegando nos que isso complica e/ou deixaria lento.
Ainda não sei se vou duplicar TUDO, ou se continuar movendo...

Fazer agora o de notas fiscais, porque é o que menos é acessado pra gravação/atualização por usuários.
Mas pode ser muito usado em relatórios, e outras rotinas....
Vou começar e ver o que dá, dependendo do que acontecer, decidir o que fazer.

Vou começar agora.
Mostrar o passo a passo, conforme for fazendo.
A intenção é..... SEMPRE poder atualizar no cliente, não importa se terminei ou não.

Primeira alteração:

Confirmar se a base está criada no MySQL, e se tem a estrutura adequada.
Faz tanto tempo, que não faço idéia de como isso está no MySQL.
Para isso, usar os backups de cliente que tenho aqui, pra comparar.

No cliente... tanto faz se existir ou não a tabela no MySQL, então, antes ou depois da alteração, continuará tudo funcionando normalmente.
Com certeza no MySQL vai ter o campo incremental como chave principal, campo que não existe no DBF.

[JoséQuintas]

Recebo backup por ftp de alguns, vão ser os cobaias para o teste.
O Backup inclui DBF e MySQL.

[JoséQuintas]

Do FTP para a pasta de backups, da pasta de backups instalando na pasta de trabalho de cada empresa.

Antes de restaurar no MySQL.... pausa pro almoço.... rs

[JoséQuintas]

Backup restaurado também no MySQL.
Tudo pronto.
São backups de cliente, neles está assim: parte DBF e parte MySQL.
Retomando a migração.
Talvez melhor fazer logo tudo que falta de uma vez.... vamos ver...

[JoséQuintas]

Fugindo um pouco do assunto inicial...
Registrando o imposto dos XMLs que passam pelos aplicativos.

Alguns fornecedores já vém usando o tal código de beneficiamento.
Apenas curiosidade, talvez agora comece a olhar isso com outra finalidade.

[JoséQuintas]

Pois é... como pode CST 20, com redução, não ter redução? sefazclass não estava pegando....

Interessante.
Parece que podemos padronizar TODOS os aplicativos e não vimos antes.
E mostra que o CEST foi uma invenção furada, que agora poderia ser jogado no lixo.
O CBENEF substitui muito bem o CEST, apesar que o governo pode manter pra validação, ou pra não admitir que cagou.

[JoséQuintas]

Mas ainda tem alguma coisa errada...
CEST não é pra produto com substituição tributária? cadê ela?

[JoséQuintas]

"Atualizando versão" na minha máquina.
Faltam essas empresas.

Carregou o aplicativo, já simultâneo com notas em DBF e MySQL.
Tanto faz consultar notas em DBF ou MySQL.

Agora dá pra dar uma olhada em cada módulo que usa, já alterar pra MySQL.
Se não der pra usar sem relacionamento com outras tabelas, a saída vai ser fazer o mesmo com outras tabelas.
Se instalar nos clientes agora.... não vão usar as notas do MySQL, mas vai estar tudo salvo em DBF + MySQL.

Tem alguma vantagem duplicar tudo?
Sim.
Vou ter tempo de sobra pra atualizar o aplicativo.
E em caso de problemas, vai ser apenas salvar novamente no MySQL (depois de corrigir o possível problema, lógico).

Pensando bem.... avaliar em fazer isso logo com tudo que é tabela, assim acelera o processo, e não precisa fonte intermediário.

[JoséQuintas]

Não tinha reparado nisso antes.
240MB de DBF ocupando 61MB de MySQL.
É lógico... no MySQL podemos usar o campo VARCHAR, e com isso não grava espaço em branco.
Pois é... mais outra vantagem... economiza disco, rede, internet, etc.

Fico imaginando se a RDDSQL ou similares tiram proveito disso ao trabalhar igual DBF....

[JoséQuintas]

Como não estava usando essas tabelas, faltava ajustar estrutura...
Ao contrário de DBF.... só acrescentar campos...

Código: Selecionar todos

      IF ! :FieldExists( "NFFCPVAL", "JPNOTA" )
         :AddField( "NFFCPVAL", "JPNOTA", "DOUBLE(14,2) NOT NULL DEFAULT '0'" )
      ENDIF
      IF ! :FieldExists( "NFAVENUM", "JPNOTA" )
         :AddField( "NFAVENUM", "JPNOTA", "VARCHAR(40) NOT NULL DEFAULT ''" )
      ENDIF
      IF ! :FieldExists( "NFAVEPRO", "JPNOTA" )
         :AddField( "NFAVEPRO", "JPNOTA", "VARCHAR(40) NOT NULL DEFAULT ''" )
      ENDIF
      IF ! :FieldExists( "NFMODFIS", "JPNOTA" )
         :AddField( "NFMODFIS", "JPNOTA", "VARCHAR(2) NOT NULL DEFAULT ''" )
      ENDIF
      IF ! :fieldExists( "NFCADEMI", "JPNOTA" )
         :AddField( "NFCADEMI", "JPNOTA", "VARCHAR(6) NOT NULL DEFAULT ''" )
      ENDIF
      IF ! :FieldExists( "IPPEDCOM", "JPITPED" )
         :AddField( "IPPEDCOM", "JPITPED", "VARCHAR(6) NOT NULL DEFAULT ''" )
      ENDIF
      IF ! :FieldExists( "IPFCPALI", "JPITPED" )
         :AddField( "IPFCPALI", "JPITPED", "DOUBLE(6,2) NOT NULL DEFAULT '0'" )
      ENDIF
      IF ! :FieldExists( "IPFCPVAL", "JPITPED" )
         :AddField( "IPFCPVAL", "JPITPED", "DOUBLE(14,2) NOT NULL DEFAULT '0'" )
      ENDIF
      IF ! :FieldExists( "IPNUMLAN", "JPITPED" )
         :AddField( "IPNUMLAN", "JPITPED", "VARCHAR(6) NOT NULL DEFAULT ''" )
      ENDIF

[JoséQuintas]

E transferir tabela para o MySQL.
Como precaução, caso misturem versões, ou carreguem o aplicativo trocando versão, testo se a base está vazia antes de começar a transferir.

Código: Selecionar todos

STATIC FUNCTION jpnotaToMySql()

   LOCAL cnMySql := ADOClass():New( AppcnMySqlLocal() )

   IF AppcnMySqlLocal() == NIL
      RETURN NIL
   ENDIF
   WITH OBJECT cnMySql
      :cSql := "SELECT COUNT(*) AS QTD FROM JPNOTA"
      IF :ReturnValueAndClose( "QTD" ) == 0
         CopyDbfToMySql( "JPNOTA", .T. )
      ENDIF
   ENDWITH
   CLOSE DATABASES

   RETURN NIL

Pronto, notas fiscais em MySQL, sendo atualizadas em simultâneo.

Agora decidir se começo a remover esse DBF do aplicativo, ou se transfiro outros também, assim já removo vários de uma vez.

Porque o arquivo de notas?
Pouca atualização simultânea, ou quase nenhuma, e é um dos maiores DBFs.

Como eu já disse antes, ainda não sei como vou fazer o simultâneo no MySQL, então deixando pro final o que vai precisar de um "algo mais".

Também não decidi sobre relacionamento entre tabelas, e nem pesquisei como fazer.

[JoséQuintas]

Tanta discussão sobre como acessar o MySQL e esqueci um detalhe importantíssimo:

Se o backup do MySQL chegar a 4GB, não tem como fazer pelo Harbour 32 bits.
Compilar com 64 bits não é problema, o problema é se todas as máquinas vão aceitar isso.

[Itamar M. Lins Jr.]

Ola!
Pq vc não replica os dados ?
Espelhamento ?
https://imasters.com.br/data/replicacao ... -5-minutos

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Pq vc não replica os dados ?

A idéia é boa, mas só vale pra quando temos acesso total ao servidor por internet, e ao servidor MySQL.

[JoséQuintas]

Até agora tudo tranquilo.
Tive problemas, mas por outras alterações que fiz junto.

É que antes guardava cópia de XML na pasta do aplicativo: aplicativo\xml\anomes
São inúteis agora, porque já estão salvos em outro lugar.

Como sou meio paranóico com isso....
Se estão lá até há mais de um ano, porque eu preciso ter pressa em apagar?
Acrescentei pro próprio aplicativo ir pegando esses XMLs, conferindo se realmente estão salvos, e ir apagando do disco.
Um pouco por vez.
Se vai demorar um mês ou mais... tanto faz... vai ser automático, vai ser seguro e não vai atrapalhar o usuário.