Meu modo de trabalho

[JoséQuintas]

Como comentei em outro post, comecei a eliminar meu arquivo multi-tabelas.
Mas havia outro tipo de multitabela, e separar facilitou muito.

Querendo ou não, é vício de DBF: economizar arquivos

Então eu tinha lá num determinado arquivo, um campo com uma lista de códigos.
Isso precisa rotina específica

Código: Selecionar todos

   Encontra( AUX_LICOBJ + StrZero( nIdLicObj, 6 ), "jptabel", "numlan" )
   FOR nCont = 1 TO Len( Trim( jptabel->axParam03 ) ) STEP 6
      cTemp := Val( Substr( jptabel->axParam03, nCont, 6 ) )
      IF cTemp != 0
         AAdd( mlcLicList, { cTemp, Ctod(""), 0, 0 } )
      ENDIF
   NEXT
   FOR nCont = 1 TO Len( mlcLicNum ) STEP 8 // igual data
      cTemp := Val( Substr( mlcLicNum, nCont, 6 ) )
      IF ! Empty( cTemp )
         nNumLic := hb_ASCan( mlcLicList, { | e | e[ LIC_CODIGO ] == cTemp } )
         IF nNumLic != 0
            Encontra( AUX_LICTIP + StrZero( mlcLicList[ nNumLic, LIC_CODIGO ], 6 ), "jptabel", "numlan" )
            mlcLicList[ nNumLic, LIC_DATA ]     := hb_Stod( Substr( mlcLicDat, nCont , 8 ) )
            mlcLicList[ nNumLic, LIC_VALIDADE ] := Val( jptabel->axParam01 )
            mlcLicList[ nNumLic, LIC_PRAZO ]    := Val( jptabel->axParam02 )
         ENDIF
      ENDIF
   NEXT

Então tinha rotina parecida pra mostrar, pra GET, pra salvar, etc.
Sempre todos os códigos de uma vez, afinal, é um campo "linguição" com vários códigos.

Ao dividir essa tabela em duas, troquei a rotina por um simples BROWSE.
E a rotina de edição passou a ser apenas a edição do código atual.
Muito mais simples do que antes.
Até poderia ficar parecido em DBF... mas em DBF a gente tá acostumado a pensar em economizar arquivo, por causa dos tempos do Clipper.
Para SQL, tanto faz, vai ser sempre uma única conexão, um comando e um retorno, tanto faz como isso é dividido pelas tabelas.

Aliás... pra SQL é bem melhor sem esse "linguição", assim a consulta é feita de tudo de uma vez.

[JoséQuintas]

Só aviso:
Não comentei mais sobre MySQL, porque parou naquilo.
Tá tudo rodando tranquilo.
Tá chegando o momento de retirar toda a conversão antiga de DBF pra MySQL, porque não vai ter nada pra converter.

A contabilidade continua em DBF, mas está exigindo MySQL pra funcionar.
Parece que nenhum cliente da contabilidade atualizou aplicativo neste ano.
É o mesmo EXE em todo lugar, não é aplicativo separado.
De qualquer jeito, vou acabar migrando a contabilidade também, porque senão isso deixa o aplicativo preso a DBF.

Como eu digo sempre: sem pressa, tá tudo tranquilo.

Talvez intercalar a migração da contabilidade com as outras mudanças preparatórias pra GUI.
Será ruim se os módulos em DBF atrapalharem isso de GUI, ou precisarem de tratamento diferenciado.

Sem pressa, mas sempre em frente....

[JoséQuintas]

Aproveitando....

Até chamar a atenção nisso:

O aplicativo usa MySQL pra quase tudo: notas, estoque, pedido, financeiro, bancário, etc., só a contabilidade está em DBF.

Não precisei mudar tudo de uma vez, vou alterando conforme dá na telha.

Quem está interessado no MySQL pode fazer igual, vai fazendo alguma coisa, vai acompanhando o resultado, não precisa sair igual um doido e passar todo aplicativo pra MySQL de uma vez.
Vai se acostumando com ele, brincando de vez em quando, vai se sentindo confortável, vai usando pras partes mais simples, e vai em frente devagar e tranquilo.
Deixei a contabilidade pra depois por opção minha, porque quero dar uma geral ANTES de salvar no MySQL.
Mas acabo até esquecendo que ela ainda está em DBF.
Talvez seja melhor fazer logo de uma vez só por causa disso, pra não esquecer.... kkkkk

[JoséQuintas]

Só atualizando:

Nenhuma novidade, tudo continua funcionando tranquilo com ADO e MySQL.
Só mesmo a leve mudança de visual, de radical só as cores mesmo.

[JoséQuintas]

Finalmente decidi organizar meu git.

Até agora era a pasta CDROM, e TUDO dentro era controlado.

Agora dividindo em pastas FONTES e DADOS

Mas isso vai longe.... acho que o computador vai ficar trabalhando o dia inteiro nisso, ou até mais de uma semana.
É que não quero perder o histórico do git, e isso é que fica demorado, estou reescrevendo quase 20 anos de história.
E.... fazendo isso pra cada tipo de alteração....
São 3.500 commits no histórico.

Vamos ver se dá certo, tem essa também, só dá pra descobrir no final (de cada etapa).

De tanto mexer na HMG, HMGE, etc. pra reescrever histórico, agora já consigo fazer isso com um pouco mais de tranquilidade.

[microvolution]

agora já consigo fazer isso com um pouco mais de tranquilidade.

um dia quem sabe eu consiga tbm kkk

[JoséQuintas]

Aproveitando....

Não falei mais da minha migração pra MySQL porque não mexi mais.

Continua tudo funcionando perfeito, e só a contabilidade de fora do MySQL.

Nem sei se já esqueci alguma coisa, só vou saber quando voltar a mexer kkkkkk

[JoséQuintas]

Minha conclusão sobre LIB GUI (ou sobre mim) é a seguinte:
Só vou usar LIB GUI se estiver do meu jeito, e vou ficar tentando mexer.

Como HMG não existe mais oficial, e não adianta mandar nada.... tá fora
Como HMG Extended é fechada, e não dá pra contribuir, tá fora
OOHG continuo enviando alterações.
HWGUI continuo enviando alterações.

Enquanto isso...
Tem o detalhe de aplicativo remoto, que tem um comportamento um pouco diferente.
É voltar a testar HWGUI nesse ambiente, agora que ficou definido que determinados antivírus não aceitam compactar o EXE.
E continuar com GTWVG, talvez acrescentando recursos entre GTWVG e HWGUI.

Agora voltei no MySQL, pra encerrar de vez tudo.

Código: Selecionar todos

07/09/2020  22:56         1.254.539 jpcidade.dbf
01/02/2021  17:42            10.279 jpconfi.dbf
07/09/2020  22:56             1.027 jpcontabil.dbf
07/09/2020  22:56             6.723 jpctconta.dbf
07/09/2020  22:56               579 jpctctaref.dbf
07/09/2020  22:56               355 jpcthisto.dbf
07/09/2020  22:56               835 jpctlanca.dbf
07/09/2020  22:56               611 jpctlotes.dbf
07/09/2020  22:56           291.822 jpdolar.dbf
07/09/2020  22:56             5.335 jpempresa.dbf
01/02/2021  17:42             5.923 jpnumero.dbf
30/12/2019  21:52               291 jprefcta.dbf
29/12/2020  09:58           526.406 jpsenha.dbf
10/11/2020  15:02            53.885 jptabel.dbf
30/12/2019  21:52             7.416 jpuf.dbf
              15 arquivo(s)      2.166.026 bytes

Isso é o meu maior cliente (que não usa contabilidade).
Eliminei de vez o jpcidade neste final de semana.
Sobrou menos de 1 MB agora em DBF.
Já não estava usando, estava meio opcional só por causa da contabilidade.

[JoséQuintas]

Só recapitulando a parte de migração.

Comecei apenas salvando os arquivos no MySQL.

Depois comecei a usar recursos adicionais pra velocidade, os SELECTs combinados
Isso já mudou um pouco o que tinha pensado inicialmente de fazer um DBF por vez.

Depois fui simplificando os comandos, conforme fui me acostumando com o que poderia fazer.

E agora aprendi a criar função no MySQL, o que pode ser muito útil.

Continua a mesma coisa, e do mesmo jeito que mostro aqui a todos: vou aprendendo, vou testando, faço teste prático, se tudo ok e se vale a pena, vou indo em frente.

Igual a todo mundo:
- teve a época que era novidade e eu nem sabia mexer - o mais recente foi aprender a criar função no MySQL
- teve a época que eu fazia e não dava certo - idem
- teve a época em que usei apenas o básico
- teve a época em que comecei a tentar algo mais - essa não termina nunca

Ainda acho que a mudança principal foi quando comecei a usar -w3 -es2.
Foi algo como voltar atrás, e reaprender todo básico do jeito certo.
Compilar assim não te mostra exatamente o que fazer, mas você acaba entendendo o que fazer pra evitar os erros.
Ao evitar os erros, suas rotinas vão sendo direcionadas a uma forma mais "infalível" e fácil de mexer.
E se básico vai bem... nada impede de tentar os "algo mais" existentes.

O MySQL não tem o -w3 -es2, mas de tanto acostumar com isso no Harbour, já dá pra saber quais são as possibilidades de erro.

No VB6 também tem algo parecido com isso, mas muito mais limitado.
Se me lembro bem, OPTION EXPLICIT, isso faz com que todas as variáveis sejam validadas na compilação.

É curioso, mas coloquei isso no VB6 pra evitar erros meus, por estar começando, e nem imaginei que no Clipper isso já existia há muito tempo, e que ajudaria tanto.

Também não imaginava que usar o ADO do VB6 no Harbour iria dar um resultado tão interessante assim.

As coisas passam pelo nosso nariz, e a gente não enxerga direito kkkk

Pois é... praticamente aconteceu uma revolução no meu modo de trabalho.
E trata-se tudo de coisa antiga....
Vai entender...

ADO é do tempo do VB6, Windows 98.
MySQL é do mesmo tempo, ou até anterior a isso.

Pois é... pra quem acha que estou "avançado", saibam que estou usando coisas de 20 anos atrás !!!

Antes tarde do que nunca....

Nota: convém dizer que agora tá mais fácil do que 20 anos atrás, e com mais recursos que não existiam naquela época, até mesmo no Advantage pra usar DBF através de comandos SQL.

[JoséQuintas]

Iniciei o uso de STORED PROCEDUREs e STORED FUNCTIONs.
Antes eram somente testes, mas agora é pra valer.
Vou começar uma grande migração de fonte Harbour pra MySQL.

Usar compatibilidade com MySQL 5.7, porque é isso que tem em vários clientes.

[JoséQuintas]

Tanta mudança pra stored procedure, e o erro foi faltar espaço em branco, no comando que ainda não está na stored procedure.

Mas detalhes:

Harbour 3.4 usando mingw 10.3
Desta vez está funcionando normalmente.

Me acordaram às 06:30 da manhã por causa desse erro.... faz parte....

outro detalhe:
ALIAS em uso: JPTABEL

Sim... ainda tenho alguns DBFs nos clientes... coisa de uns 4MB só.
Como eu já disse por aqui: comigo os DBFs sempre funcionaram normalmente.
Começar a migrar o contábil pra MySQL, e a parte relacionada, que é o que falta, assim que possível.

[JoséQuintas]

Curiosidade também:

JPTRANSACAO.TRREACAO LIKE '%ULTSAI%'

Nas transações indico o que aquela transação vai causar no aplicativo.
Essa por exemplo, vai alterar a indicação da data da última saída do produto.

Na transação pode ter indicação de qual estoque baixar, se gera financeiro, se entrada ou saída, se baixa na confirmação do pedido ou na emissão de nota, se atualiza o preço de custo, custo contábil, saída de estoque normal ou armazém, se emite nota fiscal, e até parte da regra de tributação a ser usada, pra definir ICMS, IPI, etc.

Depois que fiz isso, acabaram-se versões personalizadas, porque praticamente tudo pode ser configurado.
Até se inventaram novos impostos, tá relativamente fácil.

[JoséQuintas]

Outra coisa:
Pra evitar problema de espaço em branco, adotei deixar o espaço no INÍCIO de cada linha.
Assim fica visível se falta algum espaço (apesar que acabei deixando passar no erro que mencionei)"

É por essas coisas que se torna interessante usar stored procedure, porque o comando SQL fica exatamente com o comando SQL, sem as aspas, e não tem esses imprevistos.
Ao invés desse comando "monstrinho", seria apenas call jpimpostos_select(), por exemplo.

No programmers notepad eu configurei pra pesquisar também nos meus arquivos .sql, então, isso ajuda quando precisar alterar alguma coisa, pra encontrar não só nos fontes, mas nos comandos SQL que não fazem parte dos fontes.

Pois é... pensei nisso também.
De nada adianta separar o comando SQL do PRG, se eu não puder controlá-lo igual aos PRGs.
E não preciso "lembrar" sobre pesquisar neles, ficou automático desse jeito, tanto faz se o comando SQL está dentro ou fora do fonte PRG.

[JoséQuintas]

Há 3 meses atrás, eu não conseguia nem criar uma rotina pra somar 1 + 1.

https://pctoledo.org/forum/viewto ... 07&start=0

Pensei que fazia mais tempo, mas em apenas 3 meses deu pra aprender muito.

Então.... aproveitar pra reforçar isso:

Estou testando/treinando criar functions e procedures no MySQL.
Não comecei fazendo coisas pra serem usadas nos clientes.
Comecei testando, instalando nos clientes, FORA DE USO, mas no banco de dados.

Não é sair fazendo e colocando em prática, é primeiro ir se acostumando com o que pode acontecer, o que pode dar errado.
O teste prático foi tão somente cadastrar as rotinas automaticamente nos clientes, pra ver se tinha algo pra tomar cuidado.
Usei em opção que SÓ EU USO, pra ver o comportamento.
Facilitei a forma de cadastrar automático.

Montei a rotina de fazer backup das STOREDs.

Agora sim, dá pra pensar em começar o uso prático disso tudo.

Então....
Eu trabalho assim...
Vou aprendendo brincando...
É ir aumentando o tamanho da brincadeira, e quando colocar pra funcionar nos clientes, é só alegria...

Agora sim, NÃO TENHO NENHUM CLIENTE SEM MYSQL.
Agora é converter tudo que restou.

A propósito, já comentei em outro post:

A cliente tem folha de pagamento em MySQL. O aplicativo cria tudo com senha própria, e não dá acesso ao MySQL.
A minha saída vai ser.... instalar MariaDB, em outra porta.
Já fiz os testes de instalação, devo instalar amanhã.

Código: Selecionar todos

mysql_install_db --datadir=d:\temp\mariadb-10-3-30 --service=mariadb --password=nenhuma --port=3307

Com o MariaDB descompactado, é só digitar o comando acima pra ter o servidor no ar.
E ajustar a pasta de dados, senha, porta, e nome do serviço que vai aparecer no Windows.
A versão 10.3.30 só tem em arquivo ZIP, e é uma das que funciona no Windows 7.
A última é só pra Windows 10.

[JoséQuintas]

Meu batzinho de teste.
Carregando o aplicativo 28 vezes de uma vez, um pra cada empresa.
Faz backup e atualização de todas.

Só testando se nos clientes vai dar tudo certo....

Nem são tantos clientes assim.
É que no caso de escritório de contabilidade, isso envolve "sub-clientes".

Faz tempo que eu não fazia esse tipo de teste.
o Windows 10 ainda deixa fazer isso, a Microsoft ainda não estragou de vez.
TODOS usando MySQL, mesmo que ainda existam DBFs.
MySQL agora é obrigatório.

Agora, além do meu servidor, tem um cliente com MariaDB, o resto é MySQL ainda.