Clipper On Line • Ver Tópico - Tabela DBF apaga os registros
Página 1 de 4

Tabela DBF apaga os registros

MensagemEnviado: 03 Fev 2018 10:01
por leandrolinauer
Bom dia
Me deparei com um problemão recente, ja ocorreu duas vezes na mesma loja e em uma outra uma vez.
Ocorre do nada, não descobri ainda em que instancia do sistema se é por causa do sistema, ou por causa de outro problema de hardware, mas alguma tabela não especifica, é aleatório, somem os registros dela a mesma fica zerada, vazia ao grosso modo, algo que tinha 15 mil registrou ou mais, do nada, ocorre o apagão e some todos os registros da tabela ficando aí tipo 3, 4 registro apenas, os iniciais, e abro a tabela, ela esta perfeita sem nenhum defeito prontinha para receber novos dados, os indices tbem todos perfeitos.
Agora como que ocorre isto, não sei, só sei que ocorre e tudo rodando normalmente, alguem sabe me informar?
Se a tabela tivesse vazia totalmente sem nenhum registro, eu pensaria primeiro que alguem apagou ela, mas ela tem registros iniciais de muitos anos atrás intactos e o resto tudo foi para as cucuias.
Sorte que todos os bancos de dados são replicados instantaneamente na matriz, mas se ocorrer de sumir quando não tiver replicado, aí perco as ultimas atualizações.
Se alguem já passou por isto, me informe o que pode ser.
Sei que preciso migrar para SQL urgente, mas a falta de tempo não me permitiu ainda.
Grato a todos.

Tabela DBF apaga os registros

MensagemEnviado: 04 Fev 2018 11:02
por sygecom
Será que você não tem alguma rotina em loop ai, que deleta registro ?

Tabela DBF apaga os registros

MensagemEnviado: 04 Fev 2018 16:21
por asimoes
Recomendo usar HbNetio, evita acessos indevidos, não sei me entende ?

Tabela DBF apaga os registros

MensagemEnviado: 06 Fev 2018 08:15
por leandrolinauer
Bom dia
Obrigado pelos retornos.
Será que você não tem alguma rotina em loop ai, que deleta registro ?
Não, nenhuma rotina desta forma, esquisito mesmo o problema, pode até ser um problema no HD mas não detectei isto.

Recomendo usar HbNetio, evita acessos indevidos, não sei me entende ?
Sim, entendo. Já fiz teste primeiro com LETO, mas não fiquei contente e abandonei, lentidão absurda ao pesquisar no dbf por exemplo, pesquisar cliente, pesquisar nomes para localizar, onde a rotina faz um SEEK no banco de dados a cada variável.
Quanto ao NETIO, fiz teste e gostei mais, não executei ainda, porque eu tenho dois servidores de dados, um de DBFs iniciais do sistema e outro servidor com o banco de dados maior dos dados principais, e eu pelo menos não descobri como usar o netio desta forma.
Mas realmente pretendo usar, fiz até um programa em HWGUI só para gerenciar o netio no servidor, pretendo juntar o banco de dados exatamente para poder usá-lo, esta divisão do banco de dados, é só na MATRIZ, nas filiais todos estão juntos em um único servidor, não me pergunte porque fiz isto, hhhehe, na verdade foi uma ideia mediocre que tive, kkkk.
Creio que tomarei o projeito netio pelo menos nas filiais aonde ocorre este problema, vou ajustar o programa para ver se consigo implantar.

Uma pergunta: o HBNetio funcionaria como se fosse um SGDB, pelo que entendi, me corrijam:
O DBF abriria somente no servidor, funcionaria como CLIENTE / SERVIDOR?
Ganharia uma performance melhor em velocidade?
Segurança, quanto a falhas de índices ou até mesmo oque esta ocorrendo comigo, falha no DBF?

Grato a todos.

Tabela DBF apaga os registros

MensagemEnviado: 06 Fev 2018 08:24
por asimoes
HbNetio,

No exemplo a função de conexão é NetIO_Connect( ip,porta, timeout, "senha" )

Vai te dar mais segurança com relação a corrupção de dbf e indices e de quebra ficará oculto aos olhos do usuário, o acesso as tabelas é feito por uma função do hbnetio ip + porta e senha (opcional)

Um exemplo de acesso na aplicação cliente
METHOD TConectaNetIO()

   BEGIN SEQUENCE WITH __BreakBlock()
      IF ! ::lConecta
         IF ! oASAPREV:pConnection := NetIO_Connect( ::cIpAddServer, Val( ::cPortaNetIO ), 5000, "senha" )
            ::cServidorDB := [NetIO\SERVER5\DB\]
         ELSE
            ::cServidorDB := [net:] + ::cIpAddServer + [:] + ::cPortaNetIO + [:db/]
         ENDIF
         ::lConecta := .T.
      ENDIF
      oGuiProc:oThisFormMain:Caption := "ASAPREV - Versão 32 bits | " + ::cServidorDB
   RECOVER
     SaidaSistema()
   END
   
RETURN ::cServidorDB


Para abrir a tabela

DbUseArea( .T., cRDD, ::cServidorDB + cDataBase, cDataBase, .T. )

No servidor a aplicação ou agente servidor vai usar funções do hbnetio para disponibilizar o acesso.

Eu uso a mais de 5 anos e nunca tive problemas com dbf e indices corrompidos.

Tabela DBF apaga os registros

MensagemEnviado: 06 Fev 2018 14:58
por JoséQuintas
FUNCTION PathAndFile( cFileName )

   IF AppDatabase() == DATABASE_HBNETIO
      cFileName := "net:" + AppEmpresaApelido() + "/" + cFileName
   ENDIF
   cFileName := Lower( cFileName )

   RETURN cFileName


Para hbnetio, basta acrescentar NET: no nome do arquivo.

Tabela DBF apaga os registros

MensagemEnviado: 07 Mar 2018 19:26
por Itamar M. Lins Jr.
Ola!
mas não fiquei contente e abandonei, lentidão absurda ao pesquisar no dbf por exemplo, pesquisar cliente, pesquisar nomes

Tem alguma coisa errada ai. O Letodb é mais rápido que NetIo. Agora o LetoDbf é mais rápido ainda que este dois últimos.
O LetoDB tem BUGS que foram corrigidos com o Letodbf que inclusive RODA CLIPPER/SAMBA/Harbour tudo misturado. tem uma conversa enorme no grupo de usuários o Elch adaptando o LetoDBf para compartilhar o LOCK do DBF com o SAMBA.
O Samba é um "software servidor" para Linux (e outros sistemas baseados em Unix) que permite o gerenciamento e compartilhamento de recursos em redes formadas por computadores com o Windows. Assim, é possível usar o Linux como servidor de arquivos, servidor de impressão, entre outros, como se a rede utilizasse servidores Windows (NT, 2000, XP, Server 2003).


Saudações,
Itamar M. Lins Jr.

Tabela DBF apaga os registros

MensagemEnviado: 25 Set 2018 11:28
por leandrolinauer
Bom dia a todos.
Só voltando ao assunto, do banco de dados sendo apagado os registros sozinhos do nada, voltou a ocorrer agora mesmo em uma filial em anexo como ficou a tabela de registro dos caixas.
Notem, que apenas o primeiro registro com ano 00, foi o que sobrou de mais ou menos 9.000 registros.
o ultimo foi que o usuário registrou novamente, notem que esta logo no recno 2, entao só sobrou no arquivo o recno 1 e o recno 2

Observações:
-Não há no sistema em nenhum fonte que faço um WHILE deletando todos os registros;
-Não há como deletar o caixa já fechado e registrado;
-Não tem usuários que saibam manipular o DBU;
-A pasta do banco de dados fica OCULTA;
-É instantâneo o problema, ocorre do nada e rapidão esta tudo zerado;
-Não há no sistema o comando ZAP, mesmo se tivesse, o primeiro registro não ficaria no banco de dados;
-É um arquivo compartilhado, vários computadores abrem juntos ao mesmo tempo;

Já verifiquei se houve alguma coisa anormal, e sim, o computador reiniciou sozinho, mas isto ocorre muitas vezes e não deveria afetar.

Sei que deveria já ter migrado para SQL, mas não consegui mudar ainda, visto que terei que mudar tudo.
Grato a todos
:)Pos

Tabela DBF apaga os registros

MensagemEnviado: 25 Set 2018 11:37
por asimoes
Será que tem alguém sabotando o seu sistema ? muito estranho isso, o dbf pode ser acessado pelo excel, dbu etc...

Desconfia também do usuário, eu faria um testes, a cada x registros faria uma cópia para um dbf imagem, tipo de TABELA.DBF -> TABELAT.DBF a cada 100 registros.

Somente uma ideia.

Tabela DBF apaga os registros

MensagemEnviado: 25 Set 2018 22:28
por Itamar M. Lins Jr.
Ola!
-É um arquivo compartilhado, vários computadores abrem juntos ao mesmo tempo;

Ta mapeado ? Se sim, use o LetoDbf. A pasta com os DBF só é acessado via TCP, não existe compartilhamento para se preocupar.
Não vai mudar nada só precisa acrescentar alguns códigos no inicio.
Um chute: Alguém move um arquivo para cima desse ai

Saudações,
Itamar M. Lins Jr.

Tabela DBF apaga os registros

MensagemEnviado: 28 Set 2018 15:00
por leandrolinauer
Boa tarde a todos.
Grato pelo retorno.
Já desconfiei de tudo, mas nada ocorre de anormal do cotidiano.
Já ocorreu com tabela grande e com tabela pequena.
Estes arquivos são compartilhado com várias maquinas na rede, e quando esta em uso pelo sistema, não tem como ser apagada acidentalmente.
Detalhe, sempre sobra o primeiro registro de anos atrás, este sistema e o banco de dados é usado desde 1994, claro, vem sendo alterado o banco de dados de acordo com novas opções do sistema, mas tudo é feito pelo sistema aos meus olhos, mas o ato de perder registro não ocorre na estruturação do banco de dados e sim no uso rotineiro.
É aleatório entre as lojas, não é direto, são esporádicos os dias.
Quanto a fazer copia do banco de dados, já faço instantaneamente replicando os dados para a MATRIZ.
Aí eu tenho que apenas pegar o banco de dados daqui e colocar novamente na filial , reordenar e funcionar.
Outro detalhe, este banco de dados quando desaparece o conteúdo os índices também são atualizados, tanto que ninguém nota diferença e tudo esta funcionando normalmente, só notam quando não localiza alguma coisa já registrada porque sumiu, não da erro no sistema, nadinha nadinha.
É muito estranho mesmo.
Eu desconheço como limpar um banco de dados, sumir com os registro, sendo que o banco esta em uso no momento do ocorrido.
Para efetuar um ZAP nele, o arquivo tem que estar exclusivo e demoraria uns par de minutos, isto logo alguém iria descobrir e me falar.
:)Pos

Tabela DBF apaga os registros

MensagemEnviado: 28 Set 2018 18:49
por Itamar M. Lins Jr.
Ola!
O windows tem um recurso que sobrepõe qualquer arquivo com uma cópia anterior.
Verifique a opção "versões anteriores" no botão propriedades. Algo está ativando(voltando) algum ponto de restauração ou backup ai.

Saudações,
Itamar M. Lins Jr.

Tabela DBF apaga os registros

MensagemEnviado: 29 Set 2018 23:01
por JoséQuintas
leandrolinauer escreveu:Para efetuar um ZAP nele, o arquivo tem que estar exclusivo e demoraria uns par de minutos, isto logo alguém iria descobrir e me falar.


deve estar se referindo a ficar exclusivo, porque o ZAP é instantâneo.
O que confunde é ficar sempre o primeiro registro, a não ser que ele seja gerado automaticamente pelo aplicativo.

Tem criação automática do arquivo?
o Windows poderia retornar que o arquivo não existe, e ele ser criado do zero.

Tem algum tipo de proteção/prazo de validade?
Às vezes a gente pode colocar isso e esquecer que colocou... rs

Sugestão:
Coloque algum tipo de aviso para quando o arquivo ficar com menos de 3 registros.
Pelo menos começa a ter o horário de quando isso acontece.

Tabela DBF apaga os registros

MensagemEnviado: 30 Set 2018 19:58
por asimoes
Até agora não mostrou a rotina que ocorre o erro e as funções que trabalham com o dbf, pode ter erro ai, mas só saberemos se mostrar o código

Estamos só na imaginação e suposições

Tabela DBF apaga os registros

MensagemEnviado: 01 Out 2018 08:08
por JoséQuintas
asimoes escreveu:Até agora não mostrou a rotina que ocorre o erro


O problema é que justamente ele não sabe o que pode estar causando isso.

Tabela DBF apaga os registros

MensagemEnviado: 01 Out 2018 13:19
por Itamar M. Lins Jr.
Ola!
É tão fácil resolver isso, é só parar de mapear a rede.
Usar NetIO ou LetoDbf.
Enquanto a pasta estiver compartilhada na rede, pode botar arquivo oculto, etc... Só se tiver usando WTS tambem é uma boa opção.
Windows Terminal Server.
Mas se dar acesso a pasta via compartilhamento, é pedir para ter problemas... quando tudo é novo etc... blz, mas quando os arquivos crescem, ou o fluxo aumenta, começam os problemas.
Inclusive já comecei a trocar os servidores por Linux/Ubuntu, é muito rápido. Arquivos enormes, fluxo de NFE etc... tudo voando baixo...
Tem até umas conversas minhas com o Elch(criador do LetoDbf) sobre DNS nas estações Windows para o servidor Linux. Nem pisca as aberturas dos DBF's, porque eu abro e fecho vários por setores. Não abro todos os DBF's de vez no inicio.
No inicio da conversar ele afirma que o letodb ficou com "lentidão absurda", nunca vi, inclusive tenho clientes usando via TCP+ADSL de 5Mib baixando até XML e jogando(gravando) em DBF's de outras lojas.
Inclusive desligando na "TORA" abruptamente os servidores, não corrompeu "ainda" os dados.

Saudações,
Itamar M. Lins Jr.

Tabela DBF apaga os registros

MensagemEnviado: 01 Out 2018 19:14
por asimoes
Estamos aqui para tentar ajudar, mas se não ver o código tudo ficará no mundo do achismo.

Tabela DBF apaga os registros

MensagemEnviado: 01 Out 2018 19:47
por JoséQuintas
E o que sugere? que ele poste os fontes do aplicativo inteiro?

Tabela DBF apaga os registros

MensagemEnviado: 01 Out 2018 19:49
por JoséQuintas
Mais outra suposição, pode estar faltando após a gravação:

REPLACE ...
SKIP 0
UNLOCK

Já vi outras alternativas, e muitas fora de ordem, que atrapalhariam tudo.

Tabela DBF apaga os registros

MensagemEnviado: 03 Out 2018 16:33
por Itamar M. Lins Jr.
Ola!
Com rede mapeada "tudo" pode acontecer. A má fama do DBF vem desse uso.
Mas vai comprar o ADS que usa DBF+SQL só o preço assusta. Temos isso gratuitamente. Não com todos os recursos, garantias,... porem o LetoDb/Netio resolve nossos problemas.
Esta usando RDD(DBF/CDX/NTX) do Harbour, porque não usar o NetIO ? foram feitos pela mesma pessoa.

Saudações,
Itamar M. Lins Jr.

Tabela DBF apaga os registros

MensagemEnviado: 09 Out 2018 17:56
por Dudu_XBase
Boa tarde Nobres Colegas.

Leandro vi que comentou sobre lojas....mês passado implantei uma solução da TOTVS para o PDV aqui... que opera mesma forma que nos softwares que dava manutenção e suporte na decada de 90 rs....tempo sofrido...usando pcanywhere para conectar na Loja Marisa lá no Acre e pedindo "para preparar o modem" kkkk....hj temos banda larga...VPN...Teamviewer....Anydesk kkkk

Os Ckeckouts operam offline se necessário e usam uma software que sincroniza informações com o servidor...essa tabela que grava as informações não poderia ser alimentada por outra app que pega as vendas dos caixas e juntava tudo....tipo um select com insert ....a gravação a essa base ficaria isolada por um unico app...mas seus caixas teriam que ter uma base de dados on-premise ....como aqui eles instalaram o Oracle Express ....se perder a comunicação com o servidor ele continua vendendo....

Tínhamos isso naquela época pq os servidores "Novella" as vezes davam umas nhaca....e não poderia parar de vender uma loja de shopping pq o servidor resolveu tirar férias abruptamente...pode se pensar nessa solução também....

E como vc faz o sincronismo com a Matriz importação de arquivos com insert (append neh) ou usa alguma aplicação para isso ?

Sei que o esforço para mudança pode ser grande não sei qtas linhas tem seus fontes.... mas vc deve analisar as soluções comentadas pelos colegas...e definir uma estratégia e montar um ambiente para homologar...eu tenho uma frase que meus colaboradores e ex colaboradores até hoje me comentam kkkk "Quando o problema é sério a solução é radical." ...rs...

Mês passado conseguimos migrar meu sistema ...meu filho pródigo ....xharbour/mysql inicialmente foi criado em clipper/dbf para a nova plataforma....tenho ERPS da TOTVS e BENNER rodando nas empresas bem como bancos de dados SQL SERVER (tenho certificações 2008 até 2012 até ficar preguiçoso e contratar uma empresa DBA) e Oracle....na época qdo decidi migrar para o Mysql eu já meti o pé na jaca comecei logo nas maiores tabelas....rs seguindo o principio da solução é radical..e gradativamente fui migrando as outras....essa solução legada ficou quase 20 anos em operação...Desde 2015 tenho me empenhado em exterminar os software legados nas empresas...inclusive os que eu desenvolvi....para manter a empresa em dentro da linha sucessória...um dia eu irei para minha chácara no fds e não voltarei mais para Capital rs....

Quando migrei também para Mysql já estava na época o crescimento de software BI....e aproveitei tb fizemos a integração ao BI e em consultas WEB....melhorou muito nossa gestão....
Mas o tempos mudam esse ano já fiz varios cursos de PowerBI tenho ele até no meu celular onde acompanho os KPis....e tem o QLIK tb que já vi que é bom....não parei de programar...sigo vários canais no Youtube de programação....se tivesse isso na decada de 90....só aqueles livros imensos da Makron books kkkk....

Já aconteceu de eu ter um baita problema e sair para comer uma torta de maçã..... como fez o Agente K (Tommy Lee Jones) no filme MIB 3....vou narrar esse trecho o Agente J (Will Smith) com o C na mão pq a Terra ia ser aniquilada por uns alienígenas enfurecidos ...e pergunta pro mais velho o Agente K "O que faremos agora ?"....ele sabiamente responde "Preciso comer uma torta" ....kkkk......o agente J embravecido com a decisão...depois escuta a explicação do seu superior....“Em certos momentos de caos, eu apenas preciso comer uma torta” ....é claro que ele salvaram o mundo no final kkk....no meu caso eu fui pescar no pesqueiro depois voltei para empresa kkkk....e resolvi a bucha...kkkk....tem situações que devem ser analisadas friamente e em modo offline....mês retrasado viajei e fiquei 3 dias sem usar o celular kkkk....ainda bem que minha namorada não me matou e estou aqui ainda podendo digitar essas asneiras kkk...

Você já deve ter revirado seu sistema de cima abaixo e até ter sonhado com possíveis soluções mas ainda não achou a luz no fim do túnel...pode ser que esse ocorrido venha a estalar a mudança que faltava...pode ser que vc consiga até descobrir a causa desse incidente....mas ainda continuará usando DBFs....

Avalie as soluções apresentadas por todos e qual será de mais fácil aplicação dentro do tempo que você dispõem....

Tabela DBF apaga os registros

MensagemEnviado: 08 Jan 2019 08:39
por leandrolinauer
Bom dia a todos, um feliz 2019 assim espero.
Bom, sim, já analisei muito mas sempre me emperro no "falta de tempo", mas vou me dedicar a mudança para sql mesmo sem dúvida, mas terei que fazer isto de forma menos dolorosa para mim e para os usuários, que não deverão sentir nada.
Quanto a LETODB e NETIO, fiz teste com LETODB primeiro e me deparei com uma absurda lentidão, já com NETIO, foi igual pra igual, velocidade normal, passei a fazer uma xmudança para NETIO, mas como na MATRIZ eu utilizava dois servidores para o sistema, isto implicou na implantação do NETIO, mas já eliminei este problema passando a ser apenas um servidor agora e primeiramente devo implantar NETIO para dar uma amenizada nos problemas, e após isto migrarei para sql, já que o problema do DBF não tem cura mesmo.

Grato a todos pela ajuda.
um abraço a todos.
:)Pos

Tabela DBF apaga os registros

MensagemEnviado: 08 Fev 2019 07:59
por Eduardo Pinho
Uma pergunta: o arquivo perde o tamanho e fica pequeno ou continua do mesmo tamanho? Os registros estao lá deletados, ou nao estao na tabela?
Tive um problema semelhante uma vez, porque os usuarios desligavam o pc no botao antes de fechar o sistema. E os registros recem appendados sumiam, porque por incrivel que pareça, descobri que no summer, o commit escrevia os registros no arquivo mas nao atualizava fisicamente o header do dbf e ai a contagem de registros falhava e no dia seguinte, embora os registros sumidos estivessem escritos, eram sobrescritos. Pra solucionar, a cada gravacao eu fechava as tabelas e abria de novo. Velhos tempos, velhos gatilhos. Quanto ao seu problema, estou aventando a possibilidade de os registros estarem lá e o header foi corrompido pelas quedas do PC. Nesse caso, quando um usuario appenda um registro, todos os posteriores sao eliminados do arquivo. Voce tem que ver o tamanho do arquivo antes de alguem gravar o proximo registro, se estiver grande, mas sem a grande massa de registros, o problema é no header.

Tabela DBF apaga os registros

MensagemEnviado: 08 Fev 2019 08:22
por Eduardo Pinho
Outra possibilidade é sobre o servidor de dados. Se nao for um Windows Server voce terá sempre problemas porque XP, 7, 8 ou mesmo 10, nao sei se estão preparados para muitos acessos e gravacoes simultaneas e dão pau. Já tive outros problemas parecidos, e quando botei Windows Server 2012 no servidor, os problemas pararam. Só outra ideia de possivel causa.

Tabela DBF apaga os registros

MensagemEnviado: 08 Fev 2019 10:19
por leandrolinauer
Bom dia Eduardo.
Sim, todos ocorreram com windows de servidor WINDOWS 7 somente, já em 3 lojas diferentes.
Quanto ao arquivo em todos os casos, sumiam todos os registros dele, por inteiro, ficando um, dois ou três iniciais de anos atrás, o tamanho do arquivo de mega passava para kbytes, ou seja, alterava o tamanho dele totalmente.
A estrutura do arquivo, tudo certinho nada errado, exceto pela inexistência do conteúdo que deveria estar lá.
Indices, tudo certo, só com o resto dos registros que sobraram.
Não há possibilidade de ser apagado o arquivo, pasta escondida, arquivo em uso não permite exclusão.
Estes arquivos são aleatórios, uma vez um outra vez outro.
Ocorrem sempre quando estão todos usando, durante o movimento do dia, então os arquivos estão em uso e não teria como deletar.
O conteudo dos arquivos, somem tudo, não ficam la como deletados.
Já faz um tempinho que não ocorre mais.
Eu creio que seja algo do windows, que da pau e some com os dados visto que só ocorreu com windows 7, nos servers não ocorreu isto nenhuma vez.
Este software já roda desde 1995, claro com melhoras durantes estes anos, são as mesmas tabela com modificações estruturais.
Alguns destes arquivo que ocorreu o erro eram grandes, mas não maiores do que alguns já existentes, e tbem ocorreu com um pequeno, que não tem tamanho pouco.
Realmente tenho que migrar para SQL urgente, ainda chego lá.

Grato a todos.
:xau :)Pos

Tabela DBF apaga os registros

MensagemEnviado: 08 Fev 2019 15:48
por asimoes
Eu tentaria usar o letodbf, estou usando a mais de 1 anos e não tenho problemas, as tabelas do sistema são grandes.

Tabela DBF apaga os registros

MensagemEnviado: 09 Fev 2019 17:41
por Eric.Developer
Leandro,

Se desejar, contate-me pelo meu site, poderei fazer uma breve análise.

Mudar para SQL ou seja lá o que for, que seja motivado apenas por querer investir em melhores técnicas, mas nunca por problemas que não conseguiu solucionar, analisar adequadamente. É muito radicalismo essas manias de sugestões, inadequadas. Casos reais:

1-No cliente da empresa que trabalhei, o sistema (DBF) aleatoriamente apresentava erro na abertura das tabelas, reclamava há mais de 14 meses, ameaçava cancelar o contrato. Viajei até o cliente, depois de uns dois dias, consegui sintetizar o problema, então em menos de 30 minutos criei uma solução via código, mesmo sem saber qual a causa. Tempos depois, outro cliente de outra software house (ex-sócio), ocorreu o mesmo problema.

2-Meses depois, viajei para outro cliente, apenas para ajustar o sintegra, tive que parar, pois o sistema estava lento e travava quando usuários externos se conectavam via conexão WTS. Haviam chamado um técnico de rede e hardware, ao qual queria trocar peças ou levar o serviços, argumentei e ele ficou aguardando. Depois de tanto debugar, descobri a causa.
Enfim, casos e mais casos...problemas ou situações inesperadas acontecem em qualquer ferramenta.

Quando quiser mudar, sugiro que migre para qualquer banco de dados, evitar qualquer recurso harbour (dados), motivos:
você esta restrito ao ambiente harbour.
contribuições, não há uma disciplina, suporte, é informal, tem versão separada (típico do universo [x]Harbour)

Migrando para SQL...
você aumenta a possibilidade de integrações com outros sistemas de mercado.
Se no futuro você decida migrar de linguagem de programação, o seu banco de dados já esta pronto (ou quase).
etc etc etc

leandrolinauer escreveu:Bom, sim, já analisei muito mas sempre me emperro no "falta de tempo", mas vou me dedicar a mudança para sql mesmo sem dúvida, mas terei que fazer isto de forma menos dolorosa para mim e para os usuários, que não deverão sentir nada.
Quanto a LETODB e NETIO, fiz teste com LETODB primeiro e me deparei com uma absurda lentidão, já com NETIO, foi igual pra igual, velocidade normal, passei a fazer uma xmudança para NETIO, mas como na MATRIZ eu utilizava dois servidores para o sistema, isto implicou na implantação do NETIO, mas já eliminei este problema passando a ser apenas um servidor agora e primeiramente devo implantar NETIO para dar uma amenizada nos problemas, e após isto migrarei para sql, já que o problema do DBF não tem cura mesmo.


o sr esta enganado, isso não é para ajudar na gravação, mas o oposto. Skip 0 é lento e deve ser usado somente em lógica necessária, é raro alguém precisar, mas já precisei.
JoséQuintas escreveu:Mais outra suposição, pode estar faltando após a gravação:

REPLACE ...
SKIP 0
UNLOCK

Tabela DBF apaga os registros

MensagemEnviado: 09 Fev 2019 23:14
por JoséQuintas
Eric.Developer escreveu:o sr esta enganado, isso não é para ajudar na gravação, mas o oposto. Skip 0 é lento e deve ser usado somente em lógica necessária, é raro alguém precisar, mas já precisei.


Se quer pegar trabalho, ganhar dinheiro, tudo bem.

Ou você é incompetente, sem conhecimento, ou é puro golpista, porque falou merd. nesse ponto.

Quer tirar vantagem ok, fod.-se, mas não às minhas custas.

Tabela DBF apaga os registros

MensagemEnviado: 30 Ago 2019 14:43
por leandrolinauer
Desculpem-me, não acompanhei mais este tópico, mas decidi migrar para SQL, não irei continuar com DBF.
Grato a todos.
:{

Tabela DBF apaga os registros

MensagemEnviado: 30 Ago 2019 22:08
por JoséQuintas
log real de um cliente.
Faço quando dá na telha, só porque tenho acesso ao servidor.
Provavelmente alguma atualização de versão que apagava/modificava muita coisa.

reindex.png


As duas últimas: abril do ano passado e abril deste ano.
Não me pergunte porque na última foram 2 vezes seguidas... talvez eu tenha feito antes e depois de atualizar versão, pra comparar o que foi excluído ao trocar versão.

Nos demais clientes... não sei.. nunca reindexei... e não faço idéia se eles reindexaram algum dia...

Minha reindexação NÃO USA PACK.
A última vez que usei o PACK foi na época do computador 386SX, mais de 20 anos atrás.
Justamente foi detectado problema de duplicar e sumir registros ao usar o PACK, então nunca mais usei, nem no Harbour.
Era parecido no tempo do Clipper....

Aliás... descobri um bug na Rede Novell nesse sentido, justamente porque um outro aplicativo usava PACK.
O servidor Novell se perdia com o tamanho do arquivo, se não fosse reiniciado de tempos em tempos.
Como o PACK mantinha o mesmo arquivo.... o problema aparecia... já na reindexação copiando arquivo... nunca.

Tabela DBF apaga os registros

MensagemEnviado: 30 Ago 2019 22:19
por JoséQuintas
Faltou dizer:

NUNCA USEI COMMIT, nem dbcommit(), apenas SKIP 0 antes do UNLOCK.
Não tive problema nem com Visual Basic 6 acessando simultâneo.
SIXCDX no Clipper 5.2, SIXCDX no início de uso do Harbour, DBFCDX depois.

Tabela DBF apaga os registros

MensagemEnviado: 03 Set 2019 15:13
por leandromilersantana
vou começar a testar desta forma. Vamos ver os resultados !!!

Tabela DBF apaga os registros

MensagemEnviado: 04 Set 2019 11:03
por Fernando queiroz
JoséQuintas escreveu:Faltou dizer:

NUNCA USEI COMMIT, nem dbcommit(), apenas SKIP 0 antes do UNLOCK.
Não tive problema nem com Visual Basic 6 acessando simultâneo.
SIXCDX no Clipper 5.2, SIXCDX no início de uso do Harbour, DBFCDX depois.


Quintas como você faz a limpeza dos registros deletados no DBF?? ( ainda uso o pack)

Tabela DBF apaga os registros

MensagemEnviado: 04 Set 2019 13:42
por JoséQuintas
Fernando queiroz escreveu:Quintas como você faz a limpeza dos registros deletados no DBF?? ( ainda uso o pack)


Como eu disse, minha reindexação faz COPY/APPEND e não PACK.
Mas... como eu também disse.... fica por conta do cliente, que pode nunca fazer a reindexação.

Eventualmente, numa atualização de versão/estrutura, isso acaba sendo feito ao atualizar estrutura.

Pensando bem....
Excluir alguma coisa é uma exceção, e não algo que se faz o tempo todo.

Então temos uma nova pergunta:
Porque a preocupação de limpar os excluídos?
Porque tem tanta coisa excluída?

Tabela DBF apaga os registros

MensagemEnviado: 04 Set 2019 19:38
por Ranier
Senhores.
https://harbour.github.io/doc/harbour.html#dbcommit
IF Updated()
dbAppend()
test->first := cName
test->age := nAge
dbCommit()
ENDIF

dbCommit para no meu entendimento, é o correto a ser usado em append/replace.

dbSkip(0)
"A dbSkip( 0 ) will flush and refresh the internal database buffer and make any changes made to the record visible without moving the record pointer in either direction."

Uso para reler (refresh) os dados do registro em disco (dbf) para a memória.

Quanto ao problema, use mapeamento somente em Windows Servers (2003, 2008, etc) ou em SAMBA (linux),
nunca com windows normal, pq esses têm limitações impostas pela própria Microsoft, para não canibalizarem os
servers.

Tabela DBF apaga os registros

MensagemEnviado: 04 Set 2019 22:57
por JoséQuintas
Ranier escreveu:dbSkip(0)"A dbSkip( 0 ) will flush and refresh the internal database buffer and make any changes made to the record visible without moving the record pointer in either direction."


Vamos destacar uma parte:

make any changes made to the record visible


Deixa qualquer alteração visível para outros.

Foi exatamente nisso que me baseei desde sempre.
Se está visível para os outros da rede.... logicamente está salvo.

Tabela DBF apaga os registros

MensagemEnviado: 05 Set 2019 10:54
por Ranier
"make any changes made to the record visible"
Com relação a parte destacada, as alterações a que se refere o manuel é a respeito das alterações
feitas por outros processos/usuários, do arquivo dbf.
A intenção do programador que fez o comportamento de dbSkip(0) é bem clara, lhe traz as possíveis
alterações feitas pela rede.
Com certeza é um efeito colateral, gravar possíveis alterações feitas pelo seu processo, porquê
nas funções do driver rdd (dbfcdx), toda e qualquer rotina, chama a rotina que grava possíveis
alterações feitos pelo processo atual.
Mas a rotina feita para somente gravar e desmarcar o flag que sinaliza alterações é a dbCommit.

Pelo menos, é o que eu entendi debruçando sobre o código do DBFCDX para fazer o DBDRDD,
e esse é o comportamento adotado de quando chama dbCommit (grava todas as alterações feitas, no SGDB).

em tempo:
O DBDRDD não é copy/paste do DBFCDX, eu aroveitei somente a lógica (api) para fazer total compatibilidade.
O DBDRDD faz exatamente o que DBFCDX faz mas com SGDB (Banco de Dados).

Tabela DBF apaga os registros

MensagemEnviado: 05 Set 2019 13:43
por JoséQuintas
dbCommit() causes all updates to the current work area to be written to disk. All updated database and index buffers are written to DOS and a DOS COMMIT request is issued for the database (.dbf) file and any index files associated with the work area.


faz com que TODAS as atualizações na área atual sejam gravadas em disco. Todas as atualizações em banco de dados e índices são gravados para o DOS, e uma requisição de gravação 's solicitada para o banco de dados e índices associados com a área atual.

Me parece um negócio bem mais pesado.
Se não me engano, no Clipper ainda vinha o extra de "força a gravação".
Algo como gravar em disco pra não perder nada.

Em todo caso, acho que já fiz isso antes, vou olhar o manual.

Tabela DBF apaga os registros

MensagemEnviado: 05 Set 2019 14:10
por JoséQuintas
IMG_20190905_141413572.jpg


IMG_20190905_135619979.jpg


IMG_20190905_135626444.jpg


IMG_20190905_135640010.jpg


Na verdade confundiu.
Um arquivo exclusivo, ao usar COMMIT fica visível aos outros usuários? Mas como? deixa de ser exclusivo?

Se seguir ao pé da letra, não precisa nem COMMIT nem SKIP 0.
Alguém se habilita a isso?

Se as rotinas de incluir/alterar são únicas pra compartilhado/exclusivo, melhor o SKIP 0.
COMMIT poderia retirar o arquivo de modo exclusivo, seria isso?

Se seguir ao pé da letra, só vale pra DBF/NTX.

Conclusão:
TODOS concordam que o manual está errado, porque somente UNLOCK causa problemas.
Sendo assim, continuarei usando SKIP 0, e vocês continuarão usando COMMIT.

Tabela DBF apaga os registros

MensagemEnviado: 05 Set 2019 14:31
por JoséQuintas
JoséQuintas escreveu:TODOS concordam que o manual está errado, porque somente UNLOCK causa problemas.


Correção:

O manual diz que é só pra DBF/NTX, mesmo assim, o manual é do Clipper 5.0, que inicialmente nem tinha DBF/CDX, e também os drivers foram substituídos depois pelos de outra empresa, o próprio manual já diz que pode não ser válido para os demais drivers.

O manual diz que não precisa nada... com certeza é mentira.
O manual diz que COMMIT, SKIP, GOTO, todos atualizam.

No simultâneo com Visual Basic, no Clipper só UNLOCK não ficava visível, precisava do SKIP 0.
NUNCA usei COMMIT, nem mesmo pra um teste sequer, só posso dizer que com SKIP 0 funciona.
COMMIT funciona? não faço a menor idéia.

Tabela DBF apaga os registros

MensagemEnviado: 05 Set 2019 14:55
por Ranier
Afinal estamos falando do Harbour/DBFCDX?

HB_FUNC( DBCOMMIT )
{
AREAP pArea = ( AREAP ) hb_rddGetCurrentWorkAreaPointer();

if( pArea )
SELF_FLUSH( pArea );
else
hb_errRT_DBCMD( EG_NOTABLE, EDBCMD_NOTABLE, NULL, HB_ERR_FUNCNAME );
}

Que chama SELF_FLUSH( pArea )

Que em DBFCDX eh:
static HB_ERRCODE hb_cdxFlush( CDXAREAP pArea )
{
LPCDXINDEX pIndex;
HB_ERRCODE errCode;

HB_TRACE( HB_TR_DEBUG, ( "hb_cdxFlush(%p)", ( void * ) pArea ) );

if( SELF_GOCOLD( &pArea->dbfarea.area ) == HB_FAILURE )
return HB_FAILURE;

errCode = SUPER_FLUSH( &pArea->dbfarea.area );

if( hb_setGetHardCommit() )
{
pIndex = pArea->lpIndexes;
while( pIndex )
{
if( pIndex->pFile && pIndex->fFlush )
{
hb_fileCommit( pIndex->pFile );
pIndex->fFlush = HB_FALSE;
}
pIndex = pIndex->pNext;
}
}

return errCode;
}

Que chama SUPER_FLUSH,
que em dbf1.c:

static HB_ERRCODE hb_dbfFlush( DBFAREAP pArea )
{
HB_ERRCODE errCode;

HB_TRACE( HB_TR_DEBUG, ( "hb_dbfFlush(%p)", ( void * ) pArea ) );

errCode = SELF_GOCOLD( &pArea->area );
if( errCode == HB_SUCCESS )
{
if( pArea->fUpdateHeader && ( pArea->uiSetHeader & DB_SETHEADER_COMMIT ) != 0 )
errCode = SELF_WRITEDBHEADER( &pArea->area );
}

if( hb_setGetHardCommit() && errCode == HB_SUCCESS )
{
if( pArea->fDataFlush )
{
hb_fileCommit( pArea->pDataFile );
pArea->fDataFlush = HB_FALSE;
}
if( pArea->fHasMemo && pArea->pMemoFile && pArea->fMemoFlush )
{
hb_fileCommit( pArea->pMemoFile );
pArea->fMemoFlush = HB_FALSE;
}
}

return errCode;
}

enfim, que chama hb_fileCommit(), que finalmente escreve em disco.

Acho que tem bastante da palavra "flush", que pode significar descarga.
Afinal, para que o programador da RDD iria chamar commit se não é para que grave os dados.

Usando DBSkip(0), o programa está sujeito a seguinte falha, rara, mas possível.
Processo A Processo B
update buffer Y update buffer Y
dbskip(0), reload buffer from disk dbcommit, write buffer to disk

Após dbSkip(0), o buffer será relido, que possivelmente, pode ter sido modificado pelo processo B,
entao o programa do Processo A, agora tem os dados gravados pelo Processo B, e não os dados que ele
pensa ter acabado de gravar.

Tabela DBF apaga os registros

MensagemEnviado: 05 Set 2019 15:41
por Ranier
Vou tentar resumir a questão:
Ao chamar dbSkip(0), implicitamente, também está sendo chamado dbCommit (flush).
Dessa forma, o sistema é penalizado e fica sujeito a erros (raros).

Usar dbSkip(0) para gravar as alterações é mesmo que:
update -> flush -> reload

em sql
update -> select

Assim, toca-se disco, subsistema de rede duas vezes. Péssimo para performance em geral.
Acredito que ao criarem a RDD e (dbfcdx), o princípio KISS não foi seguido, talvez, pela fragilidade
do sistema de rede da época (DOS/NOVELL).
Afinal cada função deveria fazer uma única coisa e só.
Talvez nunca aconteça, pq quase ninguém mexe no código do Harbour agora, mas alguém poderia
mudar o comportamento da API e fazer cada função fazer somente o que deveria fazer.

dbSkip(0), reler o buffer do disco para a memória, pronto.

Tabela DBF apaga os registros

MensagemEnviado: 05 Set 2019 19:56
por Itamar M. Lins Jr.
Ola!
Se não me falha a memória já li alhures o Przmek dizendo que skip(0) não faz o que o commit faz. Vou ver se acho isso.
Mas quem já usa LetoDbf não se preocupa com isso. Rede mapeada é só problema.

Saudações,
Itamar M. Lins Jr.

Tabela DBF apaga os registros

MensagemEnviado: 09 Set 2019 13:44
por JoséQuintas
Itamar M. Lins Jr. escreveu:Se não me falha a memória já li alhures o Przmek dizendo que skip(0) não faz o que o commit faz. Vou ver se acho isso.


Se não me engano, isso foi depois de um post meu, recomendando a mesma coisa no harbour-users.
Mas.... 30 anos usando sem problemas.
Sempre que alguém posta sobre problema está usando COMMIT, então nunca me preocupei em testar se o resultado vai ser o mesmo.

FUNCTION RecUnlock()

   SKIP 0
   UNLOCK

   RETURN NIL


Pra alterar TODOS os meus aplicativos, seria alterar apenas essa linha acima.
Opções:
deixar assim, continua tudo funcionando
Alterar: pode não ter diferença, mas pode dar problema
Então... deixar assim, e me preocupar com coisas mais importantes.

Usar numa única função, isso sim é vantagem, porque nunca inverte a ordem, nunca esquece de nenhum, e substitui dois comandos por um único, reduzindo o tamanho do EXE.

Quem está com problemas pode testar usando COMMIT ou SKIP 0, e até trocando pra uma única função, assim pode alterar depois sem ter que passar por cada fonte novamente.

Mas acho que dá pra fazer um teste simples.... vou ver aqui.

Tabela DBF apaga os registros

MensagemEnviado: 09 Set 2019 14:19
por JoséQuintas
kkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkk

Num teste simples, qualquer um atualiza: UNLOCK, COMMIT; SKIP 0

#include "inkey.ch"

PROCEDURE Main

   LOCAL mNome, GetList := {}, mSalva

   SetMode(40,100)
   CLS
   IF ! File( "test.dbf" )
      dbCreate( "test.dbf", { { "NOME", "C", 30, 0 } } )
   ENDIF
   USE test SHARED
   IF Eof()
      APPEND BLANK
      REPLACE field->NOME WITH "1111111111"
      APPEND BLANK
      REPLACE field->NOME WITH "2222222222"
   ENDIF
   GOTO TOP
   DO WHILE .T.
      mNome  := test->Nome
      mSalva := " "
      @ 2, 1 SAY "Nome:" GET mNome
      @ 3, 1 GET mSalva PICTURE "!"
      @ Row(), Col() + 2 SAY "(C=Commit, S=Skip 0, U=Unlock, N=Nenhum)"
      READ
      IF LastKey() == K_ESC
         EXIT
      ENDIF
      IF mSalva $ "CSUN"
         RLock()
         REPLACE NOME WITH mNome
         DO CASE
         CASE mSalva == "C"; COMMIT; @ 5, 5 SAY "COMMIT"
         CASE mSalva == "S"; SKIP 0; @ 5, 5 SAY "SKIP 0"
         CASE mSalva == "U"; UNLOCK; @ 5, 5 SAY "UNLOCK"
         OTHERWISE         ;         @ 5, 5 SAY "      "
         ENDCASE
      ENDIF
      SKIP 0
   ENDDO
   CLOSE DATABASES

   RETURN


kkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkk

Mas aposto que este vocês não sabiam, e NÃO serve COMMIT.
E deve ser esta a causa de seus problemas !!!!!!

RLOCK()
SKIP 0

Tabela DBF apaga os registros

MensagemEnviado: 09 Set 2019 15:25
por Jairo Maia
Olá Pessoal,

Em 2013, publiquei essa mensagem. Chamo atenção para a última linha da mensagem. Tudo continua funcionando, mesmo depois que mudei para o RDD LetoDBf: http://www.pctoledo.com.br/forum/viewtopic.php?p=83708#p83708

Tabela DBF apaga os registros

MensagemEnviado: 11 Set 2019 20:35
por Itamar M. Lins Jr.
Ola!
Com vcs a palavra de quem fez o RDD do Harbour.

Hi,

Just to clarify some myths about Clipper and Harbour behavior
presented on different Clipper related forums.

In Harbour and Clipper:

1. When record or table is unlocked then just before this
operations RDD writes all local modifications in table and
index files.
2. DBSKIP(0) just like DBGOTO( RECNO() ) writes all local
modifications (if any) and then discards local record
buffer so record has to be read again when any field is
accessed.
3. DBCOMMIT() writes all local modifications in table and
index files then it sends to system or file server request
to flush (write) its disk buffers to physical device (HARD
COMMIT). It's out of application control what OS (or FS)
do with such request.

The locking and buffer flushing in Clipper and Harbour RDDs
is safe and user cannot desynchronize data using different
instruction order, i.e. DBSKIP(0)/UNLOCK/COMMIT,...
The only problems which can appear are in OS or FS, i.e. the
infamous opportunistic locks is MSDN networks which may completely
break applications using concurrently the same files and synced
by file range and file access locks. This is the most common
reason of problems in concurrent file access in current days.

If OS (or FS) does not ignore COMMIT request then using it
reduces the time when new data exists only in file server
buffers and can be lost by server power off event so in some
cases it's good to use it. Anyhow it strongly reduce performance
so the whole operation is much longer and the chance for sudden
write process interrupt bigger. Usually the best effects can be
reached when user group some write operation and then commit them
to force buffer updates.
In harbour COMMIT can be temporally disabled by
SET( _SET_HARDCOMMIT, .F. )
and then enabled by
SET( _SET_HARDCOMMIT, .T. )
Harbour remembers which RDD files where modified with
SET( _SET_HARDCOMMIT, .F. ) so when user reenable hard commits
and call dbCommitAll() commit requesta are sent for all modified
RDD files.

best regards,
Przemek


The only problems which can appear are in OS or FS, i.e. the
infamous opportunistic locks is MSDN networks which may completely
break applications using concurrently the same files and synced
by file range and file access locks. This is the most common
reason of problems in concurrent file access in current days.

Então é tudo culpa do OS. Use Linux e seja feliz! Ou LetoDBf! E manter o DropBox atualizado!

Saudações,
Itamar M. Lins Jr.

Tabela DBF apaga os registros

MensagemEnviado: 11 Set 2019 20:56
por Itamar M. Lins Jr.
Ola!
Outra atualização em abril de 2019 que afeta a gravação do DBF.

2019-04-11 17:23 UTC+0200 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
  * include/dbinfo.ch
  * src/rdd/dbf1.c
    + added DB_SETHEADER_EOL flag, it's used to force setting EOL marker
      when header is written. In Harbour's DBF* RDDs is set in CLOSE()
      method so just like in Clipper when DBF is closed and header has to
      be updated the EOL() marker is set.
      As side effect reducing header updates to minimal level (in such
      case DBF header is not updated after APPEND what is safe for Harbour,
      Clipper and compatible RDDs because they use file size to calculate
      number of records but some other DBF drivers may be confused)
      increase the APPEND speed and also forces EOL setting in all cases
      when CLOSE() method is called. Header updates can be reduce to minimal
      level by:
         hb_rddInfo( RDDI_SETHEADER, DB_SETHEADER_MINIMAL )

  * src/rdd/usrrdd/usrrdd.c
    ! fixed GPF in UsrRDD redirector for DROP(), EXISTS() and RENAME() methods



Saudações,
Itamar M. Lins Jr.