Dica para quem usa DBF.
Enviado: 17 Jul 2020 19:50
Ola!
Livre-se do protocolo SMB.
O protocolo SMB é usado para compartilhar a PASTA onde estão os DBF's.
Esse protocolo sempre foi o vilão dos DBF's
Quem usa ADS/LetoDb[f] e outros produtos que permitem trabalhar com DBF na arquitetura cliente/servidor não tem problema nenhum de velocidade, quebra de índices, corrupção dos dados.
Uso LetoDbf desde sua criação, peguei os problemas os bugs, agora não tenho mais nenhum chamado técnico para indexar, restaurar, etc isso tudo ficou no passado.
Melhor ainda que temos o ADS com sintaxe SQL, facilitando a migração para quem deseja usar SQL.
O importante é entender que quem adota o LetoDbf se livrou de todos esses problemas está de fato usando a arquitetura de qualquer SGBD, pq o importante não é o SGBD(MySql/MariaDb/PGSql,etc) mas a arquitetura a forma de mandar e receber requisições para o servidor.
Em SQL.
CREATE TABLE...
Com DBF
CREATE <X> FROM <X> ou usamos funções DBCREATE()
Na forma tradicional para o programador xBase estamos criando uma "TABELA" no nosso computador ou em uma pasta(compartilhada) isto é, vista como um arquivo local. Precisa ver lá no HD o arquivo, tamanho, data, hora da criação!
Então sempre com o raciocínio LOCAL. Sempre com a cabeça pensando, "EU FAÇO ISSO, EU FAÇO AQUILO"...
Quando usamos SGBD(MySQL...) começa a mudança "EU PEÇO ISSO, EU PEÇO AQUILO", já não sou eu que faço, eu solicito que algo faça por mim.
Está tudo lá(dentro de alguma coisa), nada aqui. Que eu vou colocar o cursor em cima e teclar DEL.
É o raciocínio do comportamento CLIENTE/SERVIDOR é diferente. Algo está fazendo, temos um intermediário, pode ser LetoDbf/MySql/MariaDb...
Não tem nada compartilhado, é TCP/IP conversando direto com o SERVIDOR, sem os intermediários(protocolo SMB) que vai pedir para outro processo SO, gravar no HD... Não estamos empurrando e puxando arquivos de 40 mil registros em uma rede com 5, 6 usuários, para cada estação que solicita incluir/alterar.
Com o servidor os arquivos estão "GUARDADOS" não ficam indo e vindo pela rede.
Saudações,
Itamar M. Lins Jr.
Livre-se do protocolo SMB.
O protocolo SMB é usado para compartilhar a PASTA onde estão os DBF's.
Esse protocolo sempre foi o vilão dos DBF's
Quem usa ADS/LetoDb[f] e outros produtos que permitem trabalhar com DBF na arquitetura cliente/servidor não tem problema nenhum de velocidade, quebra de índices, corrupção dos dados.
Uso LetoDbf desde sua criação, peguei os problemas os bugs, agora não tenho mais nenhum chamado técnico para indexar, restaurar, etc isso tudo ficou no passado.
Melhor ainda que temos o ADS com sintaxe SQL, facilitando a migração para quem deseja usar SQL.
O importante é entender que quem adota o LetoDbf se livrou de todos esses problemas está de fato usando a arquitetura de qualquer SGBD, pq o importante não é o SGBD(MySql/MariaDb/PGSql,etc) mas a arquitetura a forma de mandar e receber requisições para o servidor.
Em SQL.
CREATE TABLE...
Com DBF
CREATE <X> FROM <X> ou usamos funções DBCREATE()
Na forma tradicional para o programador xBase estamos criando uma "TABELA" no nosso computador ou em uma pasta(compartilhada) isto é, vista como um arquivo local. Precisa ver lá no HD o arquivo, tamanho, data, hora da criação!
Então sempre com o raciocínio LOCAL. Sempre com a cabeça pensando, "EU FAÇO ISSO, EU FAÇO AQUILO"...
Quando usamos SGBD(MySQL...) começa a mudança "EU PEÇO ISSO, EU PEÇO AQUILO", já não sou eu que faço, eu solicito que algo faça por mim.
Está tudo lá(dentro de alguma coisa), nada aqui. Que eu vou colocar o cursor em cima e teclar DEL.
É o raciocínio do comportamento CLIENTE/SERVIDOR é diferente. Algo está fazendo, temos um intermediário, pode ser LetoDbf/MySql/MariaDb...
Não tem nada compartilhado, é TCP/IP conversando direto com o SERVIDOR, sem os intermediários(protocolo SMB) que vai pedir para outro processo SO, gravar no HD... Não estamos empurrando e puxando arquivos de 40 mil registros em uma rede com 5, 6 usuários, para cada estação que solicita incluir/alterar.
Com o servidor os arquivos estão "GUARDADOS" não ficam indo e vindo pela rede.
Saudações,
Itamar M. Lins Jr.