Dica sobre Lixeira de registros deletados.

[scom]

Ola amigos...

Eu fiz em meu programa um tipo de lixeira tipo quando o cliente deleta um registro ele vai nesse arquivo e grava o numero do Registro, nome do DBF e os CDXS. E por exemplo o cliente quer voltar esse registro deletado ele entra na lixeira e aperta um espaço no registro e ele vai no arquivo DBF da um GO REGI_ANT e da um RECALL.

Bom esse tipo de idéia até funciona beleza mas se o cliente nunca compactar (Pack) o DBF. Porque se ele compactar ai não tem como achar mais esse REGISTRO.

Alguem tem alguma idéia de como Guardar esses REGISTROS deletados de uma oura forma?

Atenciosamente

ROBSON

[sygecom]

Tche, o teu cliente soh vai dar um PACK se vc programar para o sue sistema dar o PACK....certo ? entaum faça algo que use a sua logica..ou seja se vc usa dessa maneira ai a lixeira...vc nunca pode excutar um comando PACK nesse DBF....certo..

Abraços

Leonardo Machado

[Pablo César]

Puxa ! Boa idéia a sua !!!. Parabéns !. Gostei e o meu conselho para contornar esse problema seria:

Temos vários DBFs que são utilizados nos nossos sistemas. Então eu sugiro que para cada DBF que seja deletado um registro, seja creado um BANCO-DE-DADOS com o mesmo NOME mas com a extensão ".DEL". Desta forma, cada registro deletado irá appendar nesse outro arquivo (lixeira, digamos) que conterá o mesmo nome porém extensão .DEL. Daí então a sua rotina entra em ação (lendo o ARQUIVO.DEL) e é claro, deverá ter a MESMA estrutura do DBF que está sendo deletado o registro. Daí mesmo que seja dado um PACK no arquivo DBF, você conterá o registro que tinha sido marcado para exclusão.

O único problema, que como toda cosia RESIDUAL E acumulativa, esse procedimento deverá ter também uma REMOÇÃO FÍSICA dos registros no ARQUIVO.DEL. Assim como a própria lixeira do Windows que tem a opção de "esvaziar lixeira"

Gostei da sua idéia !. Parabéns !

Um clip-abraço :)Pos

[scom]

o Pablo César Obrigado pelo parabens. E realmente acho que sua idéa era o que eu tava precisando.

Vou testar do jeito que vc falo vou criar um clode de cada dbf meu tipo compo CLI.DBF clone= CLI_DEL.DBF e jogar os arquivos deletados mele...

Obrigado...
T+

[Maligno]

Cuidado com a integridade referencial.

[]'s
Maligno
http://www.buzinello.com/prg

[Pablo César]

vou criar um clode de cada dbf meu tipo compo CLI.DBF clone= CLI_DEL.DBF

Digamos que seu arquivo CLIENTES.DBF você pode pegar a estrutura dele assim:

USE CLIENTES
IF !FILE("CLIENTES.DEL")
CAMPOS:=DBSTRUCT()
DBCREATE("CLIENTES.DEL",CAMPOS)
ENDIF

Eu opino que fica melhor com extensão .DEL, assim fica mais fácil de gerenciar, digamos até para deletá-los fazendo DEL *.DEL

e jogar os arquivos deletados nele...

Você queria dizer: REGISTROS em lugar de arquivos, né ?. Também esses arquivos você poderia colocá-los em outra pasta.

Cuidado com a integridade referencial.

Terias alguma sugestão ?. Além desse arquivo .DEL deveria ter um campo que guardasse (Numero_Registro) acompanhado com um arquivo de índice e quando for feito um PACK, limpar o conteúdo desse campo referencial. Terias Maligno alguma idéia melhor ?.

Um clip-abraço :)Pos

[Maligno]

Cuidado com a integridade referencial.

Terias alguma sugestão?

Eu só quis dizer que não se deve querer apagar um fornecedor, se a ele ainda existe alguma conta a pagar vinculada. Ou, se for apagar um pedido de venda, que se tome o devido cuidado de apagar (ou restaurar) todos os registros de ítens a ele vinculados. Normalmente isso reside em outro arquivo. Ou seja, manter íntegro o relacionamento dos registros. Caso contrário,...

Esse é o detalhe óbvio. Certamente o colega deve ter pensado nisso. O detalhe não tão óbvio é a atenção devida à impossibilidade de restauração de registros cujos relacionamentos já foram quebrados em apagamentos posteriores. Exemplo: apaga-se um pedido. Ele vai para o seu DBF-lixeira. Esse pedido tem um código de cliente. No DBF de trabalho, só se pode apagar um cliente se ele não tiver sido vinculado a nenhum pedido. Como o único pedido já foi apagado, o registro do cliente é apagado também. Se a limpeza da lixeira apagar o cliente, a restauração do pedido será (deveria ser) impossível. Se a lixeira não for zerada, a restauração do pedido só será possível se também for restaurado o cliente apagado. Todos os vínculos de referências devem ser mantidos na lixeira da mesma forma que nos arquivos de trabalho.

Mas a idéia da lixeira é algo relativamente interessante. Tentei usar há muito tempo atrás. Era assim mesmo. Um arquivo DBF à parte, com a mesma estrutura do DBF de trabalho. Nem cheguei a codificar, para falar a verdade. Abandonei a idéia totalmente. Analisei de uma forma bem simples: o clinente apagou? Azar dele. Se quiser recuperar os dados, restaure o back-up ou então recadastre. Sim, eu sou ruim mesmo. Mas tem um motivo. ))

Os benefício da inclusão desse tipo de recurso é inversamente proporcional ao trabalho de mantê-lo funcionando corretamente. Além do que, dependendo do sistema, um erro na implementação dessa lixeira pode causar transtornos consideráveis e até prejuízos financeiros. Portanto, acho que o benefício não compensa o risco. E ainda temos a análise estatística: apagamento é um processo que ocorre eventualmente. Não é de uso contínuo, massivo. Não se faz apagamento o tempo todo. Reversão de apagamento ocorreria com freqüência menor ainda. Na minha opinião o risco e o trabalho não compensam. Pra que queimar a pestana e me arriscar a incorrer em erro em algo que será pouquíssimo utilizado? Seria mais compensador, inclusive financeiramente, direcionar minhas energias para criar funções mais relevantes, e que realmente se revertam em produção para o usuário. Isso é que agrega valor ao software. Uma lixeira agrega valor também, mas é mínimo. Repito: não compensa.

[]'s
Maligno
http://www.buzinello.com/prg

[janio]

Concordo com tudo que o Maligno disse. É muito trabalho pra pouco uso e um risco altíssimo de dar algo errado.

Uma vez um cliente queria pq queria que os produtos ZERADOS no estoque e que ele não pretendia mais vender fossem deletados do sistema. Falei pra ele que se esse produto a ser deletado não tivesse sido lançado em nenhuma venda e não tivesse sido movimentado no estoque... então ele poderia apagar.

Só que ele queria apagar os produtos lançados em vendas. Falei: É IMPOSSÍVEL! Ele retrucou que tudo 'é possível', 'não pode', 'tem que ter um jeito'.

Pra acabar com a conversa resolvi criar um FLAG para dizer se o produto estava em uso (ativo) ou não. Daí nos browses eu filtrava somente os produtos em uso. Somente em um ponto no sistema eu deixava ele ver todos os produtos... até pra depois ele ter que colocar em uso algum 'produto fora de uso'. Resolveu!

Cliente tem dessas coisas!

Jânio

[Luiz]

Pra acabar com a conversa resolvi criar um FLAG para dizer se o produto estava em uso ou não. Daí nos browses eu filtrava somente os produtos em uso. Somente em um ponto no sistema eu deixava ele ver todos os produtos... até pra depois ele ter que colocar em uso algum 'produto fora de uso'. Resolveu!

Tambem acho que essa seja a melhor forma, eu utilizo exatamente esse mesmo esquema, um campo pra identificar a situação do registro.

Mas eu crio duas opções que são usadas em casos diferentes.

Por exemplo: uma para cancelar um cadastro inativo, e outra para excluir um cadastro que tenho sido lançado errado.

No cancelamento eu utilizo um campo para identificar a situação e "filtrar" a exibição, já a exclusão é via delete (sempre com 2 perguntas de confirmação por segurança)

[scom]

olha pessoal no meu caso a lixeira ja funciona perfeitamente. e eu somente quero aperfeisoa-la.

É que por exemplo no meu sistema o dono da loja que tem acesso para deletar registro (pedido,contas a receber,contas a pagar, lançamento bancário, etc...) e por um descuido o funcionários faz um processo errado e pede pra ele deletar, um determinado registro e por sua vez o dono sem querer deleta o registro errado. e ai. lasco! então por sua vez tem que saber o que ele deletou de quem era esse pedido ou contas a receber porque ele deletou achando que tava deletando o que foi pedido. e agora? então ele tem essa opção de apertar o F3 e abrir a lixeira e voltar esse determinado registro sem complicação. sem precisar ligar pra mim para que eu me desloque até a loja dele para fazer isso.

então no meu caso é muito viavel e importante ter essa opção. porque todos nós somos sujeitos a erros. e nesse caso tem com consertar.

obrigado a todos.

e vou aperfeiçoar minha lixeira com a idéia de criar um arquivo tipo clone de todos os meus banco de dados em uma pasta especifica e assim jogando os dados nelas.

atenciosamente
ROBSON

[Pablo César]

É isso aí Robson !!! Não dê ouvidos para esses caras !!! hihihihi
:-Y (tou brincando eihnn pessoal, acho válido o objetivo em geral de seus comentários). Ja no meu caso, sistema de locadora, quando é deletado um filme, eu re-utilizo o número daquele DVD e guardo para efeitos de manter os títulos e suas caracterisiticas com fim histórico, o sistema possue uma espécie de lixeira, só que não possibilito a recuperação do registro deletado. Embora tenho outro arquivo de clientes INATIVOS que sim possibilita a recuperação. Mas como disse o Maligno, temos que ter cuidado com a integridade referencial ou integridade relacional com outros registros que estejam vinculados ao registro em questão.

Em sintese, eu acho que todo programador tem manias de impor ao usuário certa disciplina, mas temos que pensar que o usuário é humano, errar é humano. Ja sei, que quanto mais recursos der para o usuário, maiores vão ser os nossos desafios. Pelo menos é assim que eu também avalio a qualidade do software e do programalista.

Um clip-abraço :)Pos

[Maligno]

Em tempo:
Sou realmente contra o uso de uma "lixeira", mas a favor do registro de atividades em log. E tenho isso. Assim, se amanhã ou depois alguém fizer algo errado e vierem pra cima de mim dizendo que o programa tem bug (já aconteceu), posso apontar o "pai da criança" no ato. E, claro, os registros de log são autenticados individualmente. Ninguém pode alterá-los sem que eu saiba.

[]'s
Maligno
http://www.buzinello.com/prg

[Dudu_XBase]

Boa Noite.
Tenho um sistema em um plano de sáude que utilizo a lixeira, denomino ela de arquivo morto uso há anos junto com os logs de usuários e erros, como o Maligno falou é mto bom saber quem fez o que e quando, gravo usuário, data, hora e nome da estação.
Deixei um módulo de consulta e possível recuperação dependendo do nivel de acesso no sistema.
O Arquivo morto ou lixeira foi criado como uma solução de enxugar os planos cancelados que acumulavam no sistema, afetando a performance de outros processos, inicialmente eu usava um campo "flag" como o volume era pequeno mas com o tempo procurei essa forma.

[Maligno]

utilizo a lixeira, denomino ela de arquivo morto

Também uso o conceito de arquivo morto, mas dele nunca um registro volta "ressuscitado". Também uso para tirar do caminho o que está fora de uso. Mas o conceito de lixeira a que o OP se referiu (e ao que eu conheço por lixeira) é de apagamento mesmo. Não tem nada a ver com "arquivamento". O que foi arquivado morreu. Tem algumas funções para visualização. Para os casos de notas fiscais, por exemplo, é essencial uma forma de visualização e exportação para o SINTEGRA. Aliás, por coincidência, esta semana um cliente meu precisou exportar para a Receita Estadual o arquivo morto e enterrado desde 2003. Mas recuperar isso, jamais. Tá morto!

[]'s
Maligno
http://www.buzinello.com/prg

[Dudu_XBase]

Entaum vou mudar o nome que o identifico para "quase morto"...rs...

Bom Final de semana a todos )