Verificar se houve alguma mudança no DBF

[rubens]

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

[rubens]

Resolvido:

Código: Selecionar todos

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

)

[lugab]

Rubens,

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

[bencz]

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

[alxsts]

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.

[rubens]

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

[ANDRIL]

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.

[asimoes]

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.

Código: Selecionar todos

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

[asimoes]

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

Código: Selecionar todos

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

[asimoes]

Uma modificação:

Código: Selecionar todos

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

[Claudio Soto]

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

[alxsts]

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...).

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.

[asimoes]

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

[alxsts]

Olá!

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