Meu modo de trabalho

[JoséQuintas]

Ainda preciso rever minha rotina de backup.
Tem milhões de registros, mas é menor que a outra base.

[JoséQuintas]

Ainda não resolvi mas....
Ao invés de um limite de 200.000 registros, coloquei um limite de 50MB.

Fazer testes....
Numa rede 100MB, 100Mb/8 = uns 12.5MB
Talvez melhore se limitar a 10MB.

Alguém já fez esse tipo de teste?

[JoséQuintas]

28 telas de uma vez não é fácil, nem monitor de 40 resolve.
Talvez um de 100 polegadas kkkkk
Na imagem, já tinha fechado vários que concluíram a tarefa, só restaram uns 10.

[JoséQuintas]

Só comentário... pode interessar...

São 28 aplicativos rodando simultâneos.
Todos fazem backup e cadastram STORED FUNCTIONS/PROCEDURES (neste caso).
Tudo no mesmo servidor MariaDB (MySQL), que NÃO É LOCAL.

Muita consulta pra backup, gravação em disco, e vai tudo tranquilo.
CADA um deles usa uma conexão com o servidor, afinal, é o mesmo aplicativo carregado 28 vezes, cada um tem sua própria conexão.

[JoséQuintas]

Sempre esses dois são os mais demorados.
Um deles tem 4.3GB é o maior de todos, tudo bem.
Mas o de 1.3GB é mais demorado do que o de 1.8GB.
A diferença é que o de 1.3GB tem tabelas com milhões de registros, mas o tamanho total é menor que o outro.
É diferente de todos os demais, porque trata-se de outro aplicativo com outras bases (além das mesmas dos outros).
Ainda acho esquisito demorar mais.

[JoséQuintas]

Não tinha olhado esta parte.
O tamanho do backup não é proporcional ao tamanho indicado no MySQL.

O backup da base de 1.8GB deu 83MB
Já o backup da base de 1.3GB deu 144MB.

Pode ser uma pista pra entender porque demora mais - o backup fica maior.

[JoséQuintas]

É tudo muito curioso.
O tamanho é menor, mas a proporção de "zipagem" é diferente.

780 reduziu pra 144
976 reduziu pra 82.

Bom.... só pode significar mais detalhes... tem mais campos com tamanho menor.
Sei lá se isso vale pra TXT na hora de compactar....

[JoséQuintas]

O tamanho do meu EXE no passar dos anos, desde os tempos do Clipper.
A redução maior foi por usar ícones monocromáticos.
A última redução foi por começar a gravar resource diretamente no MySQL, sem passar pelo EXE.

[JoséQuintas]

jpa2021.png (8.85 KiB) Exibido 59539 vezes

Cada vez menor.

[JoséQuintas]

Então vamos lá, ao meu aplicativo atual:

- EXE voltou a ficar com o tamanho dos tempos de 2013, cerca de 2MB
- Continua multithread
- Continua GTWVG
- Continua fazendo backup, de DBF e MySQL, em formato ZIP
- Continua fazendo atualização automática
- Passando a usar mais rotinas em MySQL e menos em Harbour
- Uso de json pra atualizações
- Resource em MySQL, mais do que apenas as bases de dados
- Funcionando no MySQL 5.6 e posteriores, ou MariaDB última versão (é a única que tenho disponível).
- Microsoft ADO + ODBC MySQL 5.3
- Contabilidade indo pra MySQL

Próximas etapas:
- Mais resource em MySQL
- Mais rotinas/funções no MySQL
- Contabilidade no MySQL

[sygecom]

Parabéns Zé.

São ótimas evoluções e, obrigado por compartilhar ajuda muitos que está procurando caminhos para ter um melhor código/sistema estavél.

[JoséQuintas]

Esqueci de dizer....

Quanto às funções no MySQL.....

Em Harbour: rs := cn:Execute( "CALL ze_PedidoCalcula(10)" )

Em ASP: SET rs = cn.Execute( "CALL ze_PedidoCalcula(10)" )

Mas pode ser NET, php, etc.

Todos os cálculos, de impostos, acréscimos, descontos, rateio, etc.., tudo pronto pra qualquer ambiente/plataforma.

E agora, até atualização, caso sejam usados vários locais/sites diferentes.

O troço ficou muito doido mesmo, 1001 utilidades.

[JoséQuintas]

E aí, de repente a contadora avisa que o nome da empresa não vai mudar mais.

Alterando tudo de novo:
FTP, Site, MySQL, Webservices, atualizações do aplicativo, etc.
Acho que consegui, de ontem pra hoje, mas.... vai atrapalhar a atualização de aplicativo nos meus clientes , ainda mais agora com o uso de binários no MySQL.

A atualização do EXE em si não é problema, basta baixar o JPA.EXE com esse ou qualquer outro nome (JPA2.EXE,JPA3.EXE,...), pra pasta do aplicativo e pronto, nada mais a alterar.
O problema pode ser nas partes que dependem de atualizar o MySQL local primeiro...
Vou descobrir nas próximas instalaçòes.

Pois é... eu deveria ter deixado os clientes atualizarem primeiro....
Agora já foi....

[JoséQuintas]

Ressaltar de novo isso, porque considero importante, e até hoje tem perguntas sobre fazer isso:

Tenho um programa pra carga do aplicativo: SJPA.EXE

O que ele faz:

- Ele pega a pasta de onde foi chamado como default
- Ele pesquisa na pasta JPA*.EXE pra ver qual é o mais novo, e chama por ShellExecute(), passando o nome do EXE e o PATH.
- Só isso.

Como funciona meu aplicativo:
Ele trabalha na pasta atual, pode ser C:\, C:\minhoca, \\servidor\mapeamento, tanto faz. Ele apenas trabalha aonde está.
Na atualização on-line, ele baixa como JPA1.EXE, JPA2.EXE, etc. qualquer nome disponível
Se for atualização manual, é salvar o JPA.EXE que baixa do site nessa pasta como JPA.EXE ou JPA1.EXE, JPA2.EXE, qualquer nome

Resultado:
Vai sempre carregar o programa mais atualizado, e sempre na pasta correta.

A única coisa que precisa na máquina, e fazer o atalho pra SJPA.EXE
Pode abrir como \\servidor\jpa ou C:\JPA ou Y:\JPA, tanto faz.
Vai lá encima de SJPA.EXE: enviar para, área de trabalho, criar atalho.

É só essa a minha configuração.
Nada de inventar arquivo INI, ou variaveis indicando drive, etc. é só criar atalho pra SJPA.EXE

Tá funcionando assim desde o Windows 8, que não deixava usar arquivo BAT pra chamar aplicativo.

Até atualizar manual tá fácil, só salvar o EXE na pasta.

Pra que complicar?

[JoséQuintas]

jpaexe.png (8.12 KiB) Exibido 59228 vezes

Acho que vai ficar por aí.
Por volta de 2MB.

São TODOS os meus aplicativos em um único EXE, menos de 2MB.