Verificar se houve alguma mudança no DBF

por **rubens** » 28 Out 2018 09:16

Bom dia...

Alguém se sabe ou se lembra de alguma função/forma de verificar se houve alterações no dbf.
Eu estou carregando minha tabela de produtos na memória, em uma tabela temporária na memória. Daí a cada orçamento gravado eu faço uma leitura no arquivo dbf. Isso toma alguns segundos.
Quero verificar se houve alguma alteração no dbf desde a última leitura, se houver carrego de novo para o arquivo em memória senão continuo normalmente.

Obrigado
Rubens

por **rubens** » 28 Out 2018 11:03

Resolvido:

aFiles := Directory( 'PRODUTOS.DBF')
cHoraUltAlteracao := aFiles[1,4]

:))

por **lugab** » 28 Out 2018 14:19

Rubens,

Tem casos em que o DBF nao é alterado, mas o seu CDX/NTX é

por **bencz** » 28 Out 2018 18:47

Calcule o MD5 dos DBFs e NTX, isto é uma forma mais segura de verificar se houve alterações

por **alxsts** » 28 Out 2018 19:25

Ola!

the last modification date of a database (.dbf) file
------------------------------------------------------------------------------
Syntax

LUPDATE() --> dModification

Returns

LUPDATE() returns the date of the last change to the open database file
in the current work area. If there is no database file in USE,
LUPDATE() returns a blank date.

Description

LUPDATE() is a database function that determines the date the database
file in the current work area was last modified and CLOSEd. By default,
LUPDATE() operates on the currently selected work area. It will operate
on an unselected work area if you specify it as part of an aliased
expression, as shown in the example below.

Examples

. This example demonstrates that the modification date of the
database file is not changed until the database file is closed:

? DATE() // Result: 09/01/90
USE Sales NEW
? LUPDATE() // Result: 08/31/90
//
APPEND BLANK
? LUPDATE() // Result: 08/31/90
CLOSE DATABASES
//
USE Sales NEW
? LUPDATE() // Result: 09/01/90

. This example uses an aliased expression to access LUPDATE()
for a database file opened in an unselected work area:

USE Sales NEW
USE Customer NEW
? LUPDATE(), Sales->(LUPDATE())

Files Library is EXTEND.LIB.

por **rubens** » 29 Out 2018 08:28

Bom dia..

Tem casos em que o DBF nao é alterado, mas o seu CDX/NTX é

Vou verificar isso nos testes Gabriel.. obrigado pelo alerta..

Calcule o MD5 dos DBFs e NTX, isto é uma forma mais segura de verificar se houve alterações

Vou verificar isso também... mas acho que não precisa ser uma informação tão precisa, é só para evitar de ficar carregando o dbf toda hora.. obrigado

LUPDATE() --> dModification

Alxsts LUPDATE() não serve, ele só mostra a data de modificação, eu preciso verificar isso várias vezes no dia..

Inclusive, acho que minha regra de negócio aí tá falha, porque não vai haver modificação na tabela de produtos só quando houver uma inclusão ou exclusão ou quando mudar um preço... etc... Toda vez que efetuar uma venda vai acontecer mudanças no dbf.. Toda venda dá baixa no estoque e salva data/hora da última venda.

Mas obrigado pelas dicas..
Tô estudando aqui a melhor forma de fazer isso..

Obrigado
Rubens

por **ANDRIL** » 29 Out 2018 17:33

rubens escreveu: porque não vai haver modificação na tabela de produtos só quando houver uma inclusão ou exclusão ou quando mudar um preço... etc...

Neste caso poderia criar um TXT apenas quando houver uma destas operações e buscar a data e hora de gravação deste TXT ao invéz do DBF.

por **asimoes** » 29 Out 2018 21:31

Rubens,

Usando o artifício de uma THREAD STATIC

Só uma ideia:

A função GravaHora() será usada somente quando o DBF físico for atualizado (commit), enquanto isso você fica testando se LerHora() retorna .T., caso retorne Carrega a tabela novamente.

THREAD STATIC cUpdate 

FUNCTION MAIN

   GravaHora() 
   
   LerHora()
   
   GravaHora()
   
   IF LerHora()
      CarregaTabela()
   ENDIF  

ENDIF

FUNCTION GravaHora()   
    StrFile( Time(), "LUPDATE.TXT", 0, .T. )
RETURN Nil   

FUNCTION LerHora()
LOCAL lUpdate := .F.
   
   IF cUpdate = Nil
      cUpdate := FileStr("LUPDATE.TXT")
   ELSE
      IF cUpdate != FileStr("LUPDATE.TXT")
         lUpdate := .T.
      ENDIF   
   ENDIF   
      
RETURN lUpdate

por **asimoes** » 29 Out 2018 21:39

Sugestão para a função GravaHora()

FUNCTION GravaHora()   
    StrFile( DataHora(), "LUPDATE.TXT", 0, .T. )
RETURN Nil   

FUNCTION DataHora( cSeparador )
LOCAL cDataHora

   Hb_Default(@cSeparador, ' ')

   cDataHora := Hb_TTOC( Hb_DateTime(), 'DD/MM/YYYY', 'HH:MM:SS')
   cDataHora := StrTran(cDataHora, ' ', cSeparador)
      
RETURN cDataHora

por **asimoes** » 29 Out 2018 22:16

Uma modificação:

FUNCTION LerHora()
LOCAL lUpdate := .F.
   
   IF cUpdate = Nil
      cUpdate := FileStr("LUPDATE.TXT")
   ELSE
      lUpdate := cUpdate != FileStr("LUPDATE.TXT")
   ENDIF
      
RETURN lUpdate

por **Claudio Soto** » 29 Out 2018 23:17

Aquí hay un ejemplo en HMG oficial de como monitorear los cambios en un archivo, tal vez pueda ser útil:

http://hmgforum.com/viewtopic.php?f=15&t=1411

por **alxsts** » 30 Out 2018 11:10

Olá!

Pessoalmente acho que é muito esforço só para usar DBF em memória. Creio que este recurso seja bom e rápido mas deve ser usado de forma apropriada, ou seja, para dados que sofram poucas atualizações. Por exemplo: tabelas para carregar list boxes ou combo boxes (UF, Cidades, Contas contábeis, centros de custo, etc...).

rubens escreveu:Inclusive, acho que minha regra de negócio aí tá falha, porque não vai haver modificação na tabela de produtos só quando houver uma inclusão ou exclusão ou quando mudar um preço... etc... Toda vez que efetuar uma venda vai acontecer mudanças no dbf.. Toda venda dá baixa no estoque e salva data/hora da última venda

Neste ponto creio que a normalização das tabelas deveria ser outra:
- Cadastro de produtos deve conter dados cadastrais.
- Estoque seria outra tabela com os estoques por produto. Isto permite controlar vários estoques em vários locais diferentes.
- Preço seria outra tabela, contendo preços por produto, permitindo cadastrar várias tabelas com preços diferenciados por produto.

por **asimoes** » 30 Out 2018 16:13

Pensei em uso de trigger, lembro que tinha uma lib pra isso, o Letodb tem.

por **alxsts** » 30 Out 2018 16:28

Olá!

É o Six RDD. Não sei se veio para o Harbour. No xHarbour tem a lib HbSix.

Quem está online