PC Toledo

Aumentou de tamanho de novo.
Isso enquanto não descobrir qual o problema com arquivos JPG.

De resto, tudo tranquilo, JPBINARY em uso a plena carga, assim como STORED PROCEDURE e STORED FUNCTION.

Agora só questão de ir atualizando a lista.

Então... vamos lá...

Na minha máquina criei a pasta com resources que vão para o MySQL
São tabelas em formato JSON, criação de tabelas em formato de comando SQL, comandos pra criação de STORED PROCEDURE e STORED FUNCTION.
E outros comandos SQL que sejam muito grandes.

Quando peço pra enviar versão pra internet, esses arquivos são atualizados no meu servidor da internet, apenas a tabela WEBBINARY, e isso fica lá, quietinho, apenas salvo na internet.

Nos clientes:

Quando clicam lá pra atualizar versão, uma das coisas é o aplicativo atualizar o JPBINARY local, que contém uma cópia do WEBBINARY.
Se forem STORED PROCEDUREs ou STORED FUNCTIONs, o aplicativo já executa o comando no servidor LOCAL, servidor do CLIENTE.

Resultado: todas as rotinas/comandos SQL são atualizados automaticamente, SEM PRECISAR outro EXE.

Basta eu criar tabelas em json aqui na máquina, e elas chegam ao cliente, também por esse JPBINARY.
O mesmo pode acontecer com imagens, EXEs, DLLs, etc. tudo é enviado automaticamente para os clientes.
Com isso, qualquer atualização chega até o cliente, automaticamente.
Só a instalação de tudo, por enquanto não deixei automática, só mesmo STORED PROCEDURE/FUNCTION.

Simples e prático:
- envio pra minha base SQL da internet o que tiver data mais nova
- no cliente, baixo o que tiver data mais nova, e instalo se for STORED PROCEDURE/FUNCTION

Por enquanto não faço a remoção auomática.
Se alguma coisa deixou de ser usada, ela continua lá.
Ainda pensando na remoção, porque remover antes da hora, ou remover tudo por problema de conexão não seria bom.

Talvez seja interessante colocar um indicativo sobre estar desativado, ou sobre qual versão precisa daquilo.
versão de/até, por exemplo.

Acho que nem precisa dizer, mas, deixei de fora as tabelas de configuração, e a própria tabela BINARY.
Sim, porque essas o aplicativo precisa criar sem depender de BINARY.
Como vou salvar coisas no BINARY se o BINARY não existir?

Também no primeiro uso, a primeira coisa é atualizar esse BINARY, a fim de ter os comandos pra prosseguir.

Pronto.
Toda atualização do aplicativo está automática, no que se refere a levar as informações até a máquina do cliente.
A partir daí, é tudo local, sem mais necessidade da internet.

Dá pra dizer que é como o aplicativo ter um pendrive próprio, só com instalações.

Pois é...
A idéia inicial era apenas reduzir o tamanho do EXE, movendo resource pra MySQL.
E no final... criei isso de transferir arquivos de atualização/instalação.

Não comentei aqui, e até tiram conclusões erradas:

Meu aplicativo de uso geral, tudo em um, faltam poucos DBFs pra converter: contábil e senhas

Mas tem o aplicativo de imobiliária, esse ainda tem muitos DBFs.
O grosso é DBF/CDX, e deve ter uns 40 usuários.

No momento está com problemas de lentidão.
Acho que depois de 2 anos, tá na hora de dar uma passada lá, e reindexar pra eliminar registros excluídos.

No fórum sempre mencionam problemas de índice corrompido ou lentidão, e que eu me lembre, é sempre com DBFNTX.
Nessas horas também mencionam que o compatilhamento windows dá problema.
Sei lá... só vou reindexar pra eliminar registros excluídos...

Em algumas rotinas eu faço reaproveitamento de registros excluídos, só pra não ter que reindexar.
Talvez melhor fazer isso pro aplicativo em geral.
Muito ruim ter que passar no cliente a cada dois anos, só pra reindexar.
Mas o ideal mesmo vai ser passar tudo pra MySQL.

SETEMBRO / 2021.

Meu aplicativo não faz mais nenhuma conta para o pedido, nem decide CFOP, CST, alíquotas, mensagens de lei, etc.
TÁ TUDO POR CONTA DO MYSQL.

Ainda no MySQL: Baixar estoque, gerar estoque, gerar financeiro, etc. o aplicativo + chamadas MySQL

Contente pelo resultado, mas .... seria melhor com a ajuda -w3 -es2 do Harbour.
Precisa muito cuidado por conta disso.

Comparando o fonte Harbour e o fonte SQL....
Nem fiz tanta coisa assim.
Apenas agora é o servidor quem vai fazer isso, e não o aplicativo.

Sinceramente, parece que não mudou... nada

Mas.....
Agora isso vale para o BANCO DE DADOS, não importa se vou usar Harbour, Html, ASP, CELULAR... tá tudo pronto.

erro de hoje:
Lógico.... quando a gente usa programa Linux no Windows dá nisso....

O servidor desse cliente é LINUX.
No Linux o MySQL FUNCIONA DIFERENTE: é case sensitive

Pois é....
A tabela existe, mas com letras maiúsculas.

Então...
Toda a rotina de cálculo foi pro buraco.... porque neste cliente o servidor é LINUX.
Pior que isso... impediu a emissão de nota fiscal.

É MEU ÚNICO CLIENTE COM SERVIDOR LINUX.
Em nenhum outro deu problema.

A solução foi alterar a STORED PROCEDURE, colocando o nome em maiúscula.
Nada grave, apenas um contratempo.
Agora funciona em Windows e Linux.

Deixei escapar um único lugar em minúscula, uma única palavra no meio de mais de 400 linhas.

Esta aí um ponto interessante...

O MySQL tem a opção de gravar tabelas em separado, e isso antigamente NÃO ERA o default.
Agora o default é em arquivos separados, CADA tabela num arquivo, usando o NOME DA TABELA, o que em LINUX tem diferença.
NÃO SEI se antigamente fazia diferença maiúscula/minúscula.

Esse default parece uma coisa à toa, mas é importante.
Em 32 bits temos lá o limite de 2GB ou 4GB pra tamanho de arquivos.
Se gravar tudo junto, o limite será 4GB por banco de dados.
Mas gravando separado, o limite passa a ser 4GB POR TABELA, o que pode aumentar em muito o limite do banco de dados.

Pra quem ainda tem servidor MySQL em máquina 32 bits, isso é muito importante, faz muita diferença.

Como faço minhas atualizações.
Na minha máquina chamo a opção de upload.
No cliente, chama a opção de download.

Isso atualiza resources em json, sql, jpg, stored procedures, stored functions, e o EXE.
TUDO que estiver pendente.

Só que com isso de STORED PROCEDURE e STORED FUNCTION...
o caminho agora é sempre em frente, sem opção de voltar versão anterior.

Isso me faz até pensar se volto a embutir pelo menos essa parte no EXE.

Acabei definindo um campo pra versão, e uso "DELETED" quando não precisa mais.
Na prática nem precisa mais disso, mas por enquanto acompanhando as coisas.

O campo BINDELETE foi uma opção anterior que descartei.
Aguardando os clientes ficarem numa mesma versão antes de apagar de vez o que não precisa mais.

Lembrando....

Continua existindo DBF.
Continua existindo atualização de estrutura de DBF e qualquer tipo de atualização em DBF.
Continua existindo atualização de estrutura de MySQL e qualquer tipo de atualizaçào em MySQL.

Pois é...
DBF funciona perfeito... vou adiando a migração.
E também porque não sei como vou fazer certas coisas da contabilidade kkkk
Até lá, vou acabar encontrando alguma solução, já que as opções estão se expandindo.

Aproveitando....

Como eu já disse por aqui: não sou nenhum gênio.
Apenas vou aprendendo, vou testando, testando também na prática direto no cliente, e se deu certo, vou em frente.
Quando comecei a usar MySQL eu disse que era principiante.

Muito tempo depois foi que comecei a tentar usar STORED PROCEDURE e STORED FUNCTION.
Preparei o terreno pra fazer backup disso, pra atualizar isso, só depois comecei a fazer uso.

Acho que esse conjunto é que permite eu tentar novidades mais rápido, porque dá pra consertar rápido também.
Apenas vou aprendendo mais um pouco, e colocando esse pouco em prática.
Comecei nem sabendo se ia realmente dar certo, mas tomando todas as precauções.
E faço testes variados antes de colocar em prática.
Não é que sou experiente, é que sou pessimista, então tento imaginar tudo que pode dar errado kkkk
E testar na prática tudo que pode dar errado.
No dia a dia, é só lembrar do que já deu errado, e não errar de novo.

E como falo sempre: procurar deixar o fonte fácil de mexer, pra quando começar a esquecer, o próprio fonte lembrar.

Até agora tudo tranquilo, apesar de problemas eventuais.

O problema de hoje foi esquecer que o JOIN multiplica resultado.
No pedido, pra confirmar um único produto apareceu 539 mensagens de confirme kkkk

Agora até é engraçado.... mas até resolver.... foi um pouco de pânico.

Cálculos somente em STORED PROCEDURE, outras coisas em STORED PROCEDURE/FUNCTION, etc.

Mesmo assim, pedidos continua sendo o maior fonte, e dividido em dois ainda....
O maior é o de pedidos, depois geração do XML da nota, geração do sped fiscal, geração do sped contábil, e sub-rotinas dos pedidos.
É muita opção/checagem nos pedidos.
Tá difícil reduzir alguma coisa nisso tudo.

Pedidos reduziu de 71.641 pra 68.011
E as sub-rotinas de pedido de 56.006 pra 55.724

o EXE também reduziu, bem pouco, mas reduziu.
Com exceção das alterações de hoje, tá tudo rodando pra valer.
A versão instalada no cliente é 2021.09.08.0827.
Cometi um erro no nome de um campo, no fonte Harbour, e pra corrigir, tive que trocar ainda hoje.

Lembrando:
O que vai para meu cliente é sempre o que estou mexendo, sempre em frente. Só falta instalar as horas de trabalho de hoje, após as 08:30.
É colocar em prática, sempre confirmando se tudo funciona como esperado, assim dá pra saber se devo continuar indo em frente ou não com as mudanças, que agora tem sido em STORED PROCEDURE/FUNCTION.
Como tem funcionado.... vamos em frente reduzindo fonte Harbour aonde possível.

Depois da recente invasão do cliente que percebi uma coisa...

O que se perdeu? DBF
Pra que servem? a maioria pra nada, são da contabilidade, que poucos clientes usam.

Tá na hora de considerar que só tem MySQL aonde não usa contabilidade, e os DBFs vazios que fiquem lá numa pasta, vazios, mesmo que em todos os terminais.
E simbora em frente, pensando nesse novo ambiente.