ESPELHO DE REGISTRO

[Eliane]

Tenho um sistema que será necessário criar um espelho de cada registro, ou seja, a cada alteração de um campo ou deleção de um registro terá que ser mantida uma cópia do mesmo. Isto deverá ser feito para vários dbfs e o volume de dados será bastante grande.

Em uma rede com 10 terminais o que ficaria + rápido: gravar em dbf ou em txt com SET PRINTER to arquivo

[alaminojunior]

Boa tarde,
partindo do principio, de que estes dbf´s espelhos, serão apenas abertos para inclusão de registros apagados ( me parece um arquivo morto ), e não haverá manipulação de seus dados, pode ser feito em dbf mesmo.
No momento de deletar algum registro, abre o arq. morto, grava e fecha.
Acredito que separando eles em outra pasta, para melhor organização, fica bem interessante.
A vantagem de se criar em dbf´s, é a facilidade de amanhã, ter de recuperar algum registro.

[Pablo César]

Eu também concordo que deveria ser feito o espelho dos DBFs em outros DBFs com o mesmo nome mas em pasta diferentes. Este processo bem que poderia ser feito nas funções onde ADICIONA_REGISTROS e onde REPLACE_REGISTROS. Isto é, toda vez que é feito um replace, faça uma função onde execute o REPLACE no DBF do diretório corrente e SELEcione no outro DBF ora em outra pasta. Eu colocaria essa função com um parâmetro no qual se soubesse que é para adicionar (uso do APPEND BLANK) ou apenas um REPLACE. Mais ou menos assim:

Código: Selecionar todos

REPASSA({1,6},{1,2,3},{10.00,"NOME JOAO",CTOD("01/12/2007")},.T.) // Quando precise inclusão de registro
REPASSA({1,6},{2,5},{15.00,.T.},.T.) // Quando apenas precisa corrigir o registro


FUNCTION REPASSA(VSELE,VCAMP,VCONT,VINC)
VQSEL:=SELECT()
SELECT(VSELE[1])
IF VINC
   APPEND BLANK
ENDIF
FOR I=1 TO LEN(VCAMP)
     FIELDPUT(VCAMP[I],VCONT[I])
NEXT
SELECT(VSELE[2])
IF VINC
   APPEND BLANK
ENDIF
FOR I=1 TO LEN(VCAMP)
     FIELDPUT(VCAMP[I],VCONT[I])
NEXT
SELECT(VQSEL)
RETURN NIL

[Maligno]

Tenho um sistema que será necessário criar um espelho de cada registro, ou seja, a cada alteração de um campo ou deleção de um registro terá que ser mantida uma cópia do mesmo.

Quanto a questão da velocidade de gravação, acho que é irrelevante se for TXT ou DBF. Uma coisa dessas vai "amarrar" bastante seu programa, de qualquer maneira.

O problema é a possível recuperação disso, se é que essa é uma possibilidade. Como no Clipper é muito mais natural usar DBFs, ficará mais fácil operacionalmente usar DBFs. Até pra uma visualização posterior.

Mas também não dá pra opinar com precisão sem saber pra quê servirá esse procedimento, que não é de back-up, mas de registro histórico.

[vagucs]

Acho melhor averiguar um serviço de sincronismo de diretorio, em linux ou windows, é mais rapido do que fazer seu programa operar 2 gravações em arquivos distintos.

[Maligno]

Depende da necessidade dela. Se for pra algum tipo de histórico em que ela terá de registrar quem fez o quê, não vai adiantar nada.

[vagucs]

mas pela questão, quer manter uma copia do arquivo, se for incluido registro, deve ser incluido nos 2, se for deletado, deve ser deletado nos 2, ai um serviço de sincronismo de diretorio funcionaria de forma simples e sem precisar mecher no sistema.

[Maligno]

Concordo plenamente. Mas se houver mesmo necessidade de manter um histórico (na acepção da palavra), não adianta nada simplesmente copiar. Será necessário registrar o autor da alteração ou apagamento. E isso só mesmo pelo Clipper, infelizmente.

Agora, a questão inicial não ficou clara, mesmo que a Elaine tenha usado o termo "espelho". Às vezes, seja pela pressa ou distração, a questão não fica bem formulada. Por isso, repito o que disse no meu primeiro post: sem saber pra quê servirá esse espelhamento, qualquer idéia será especulação. Mas é bom que as idéias surjam. Uma delas deve se encaixar no problema.

[vagucs]

vamso esperar que a necessidade seja esclarecida então.

Se for um hiostorico das modificações concordo que seja assim, mas se for espelhamento melhor fazer com sincronismo de diretorio.

[rochinha]

Amiguinhos

Nunca usei sincronismo de diretórios nem replicação de dados, mas mesmo que não seja para efeito de historico sua importancia é muito util para efeitos de backup.

Talvez a idéia da Elaine seja criar um backup de segurança usando a técnica de espelhamento, propriamente dita, ou as idéias postadas até agora.

Ou até uma auditoria de dados onde é necessário saber o porque que dados desaparecem ou não são encontrados.

Uma auditoria leva em consideração aspectos como hora, data, usuario que efetuou um movimento em um registro portanto deve ser feita de forma programada pelo desenvolvedor.

Um sincronismo de diretórios implica na copia de arquivos que foram modificados num certo periodo de tempo e tudo isto deve ser gerenciado pelo S.O. sem causar travamentos no momento da copia ou da abertura no sistema.

Uma replicação pode ser feita dentro do proprio sistema, desta forma o controle fica nas mãos do usuário, comumente conhecido como backups ou cargas de terminais, ja que isto também é uma replicação.

Minha seguestão é que a colega monte um pequeno aplicativo que rode em outra maquina e que de tempos em tempos abra os arquivos e verifique uma modificação, seja por modificação de data, tamanho do arquivo(antes e depois), total de registros, etc.

Eu senti uma necessidade identica quando um cliente meu começou a ter problemas de corrupção causados pelo DEAVAST.

Montei um pequeno programa que de tempos em tempos faz um total backup dos dados zipando tudo num arquivo.

Mas vou modifica-lo para efetuar esta rotina somente com os arquivos que foram modificados nos ultimos minutos e para monitorar talves eu enxerte no comando Commit() uma chamada a uma função que grave um pequeno arquivo com o nome do .DBF aberto e quando o monitor passar por ele saiba qual arquivo deverá ser backupeado, sem ter de abrir e testar todos.

Em tempo vou postas este meu aplicativo na sessão codigo fonte para apreciação.

[vagucs]

pois é rochinha, um replicador de diretorio faria o que vc está fazendo com este programa, mas seu sistema copia o arquivo inteiro, ja um replicador copia apenas a parte modificada, refazendo todas as funções que escreveram no arquivo. o que é mais rapido no caso da rede, já que nao precisa de tempos em tempo copiar todo o arquivo.

[rochinha]

Amiguinho

Com toda a razão.

E como postei, o método de replicação, fica a cargo do desenvolvedor programar o método de carga, escolha do conteudo, etc.

No meu caso eu optei por levar todo o conteudo pois se trata de uma copia de fim de tarde, pois o usuário, sempre preguiçoso, nunca faz backups e automatizar algo assim no sistema provoca perda de tempo.

Estou trabalhando para fazer desta rotina algo mais seletivo, seguro, rápido usando algo como semáforos e avisos e ai posso fazer isto enquanto usam o sistema.

Logico que se eu fosse a colega usaria a maioria das dicas de uma vez, pois com segurança não se brinca e quando os dados somem ou são desconfigurados a culpa, hehe, é sempre do desenvolvedor.

[Maligno]

pois com segurança não se brinca e quando os dados somem ou são desconfigurados a culpa, hehe, é sempre do desenvolvedor

Taí uma coisa que não aceito. Todos os meus clientes já sabem: dou a ferramenta de back-up mas usá-la é responsabilidade deles. Avisados estão. Se algo der errado e eu tiver de interceder, cobro por isso. E se o back-up não estiver em dia, cobro mais caro ainda. Meu pensamento é: se o sujeito quer usar informática tem de aprender a usá-la, e com responsabilidade.