Vantagem(*) do DBF

[JoséQuintas]

Código: Selecionar todos

/*
PTESVOLFIN - VOLTA FINANCEIRO ZERADO

Cliente usa lançamentos zerados em determinada situação
Apagar gerou problema
*/

PROCEDURE PTESVOLFIN

   LOCAL nCont, cnSQL := ADOClass():New( AppConexao() )

   SayScroll( "2020/04/24 - Financeiro faltando" )
   IF ! AbreArquivos( "jpfinan" )
      RETURN
   ENDIF
   SET ORDER TO 0
   GOTO TOP
   GrafTempo( "Financeiro" )
   DO WHILE ! Eof()
      GrafTempo( RecNo(), LastRec() )
      Inkey()
      WITH OBJECT cnSQL
         :cSQL := "SELECT COUNT(*) AS QTD FROM JPFINAN WHERE IDFINAN = " + NumberSQL( jpfinan->idFinan )
         :Execute()
         IF :Number( "QTD" ) == 0
            :QueryCreate()
            FOR nCont = 1 TO FCount()
               :QueryAdd( FieldName( nCont ), FieldGet( nCont ) )
            NEXT
            :QueryExecuteInsert( "JPFINAN" )
         ENDIF
         :CloseRecordset()
      ENDWITH
      SKIP
   ENDDO
   CLOSE DATABASES
   MsgExclamation( "Fim" )

   RETURN

Até mostrei por aqui um problema com DBF estragado, que foi convertido pra MySQL.
A solução, pra que não impedisse mexer na estrutura foi apagar zerados.
Até aí ok.
Mas.... um cliente usava lançamentos zerados.... resultado: apagou dados úteis em outro cliente
Como apaguei só no MySQL, tudo bem, pegar de volta do DBF.

Mas isso me fez pensar: e quando não tiver mais DBF?
Aquilo de registro só ser apagado no PACK em DBFs, pode fazer falta, em determinadas situações....

Será uma doideira, mas pode ser interessante guardar tudo que for excluído/alterado
Com certeza STORED PROCEDURE facilita isso.

Com certeza se torna um ótimo log de tudo que foi alterado/excluído.
Dá pra criar uma opção do usuário desfazer algo que tenha feito errado....
Mas.... será exagero? haja espaço....

Fico pensando....
Isso é só porque estava acostumado a ter isso no DBF, ou realmente é necessário?

[asimoes]

Ai entra o backup do banco, recuperar o backup do dia anterior.

[LDOSISTEMAS]

Eu também já pensei nisso, ai grande questão, eu cheguei a criar um flag nos registros para marcar ao deletar e rotina para excluir como no DBF mas depois vi que era tudo uma questão de aprendizado do usuário.
E mesmo de nós, então acabei removendo as rotinas, instrução de BKP com mais frequência e vamos tocando a vida.

[modalsist]

Boa noite.

Eu preciso dos registros deletados. Frequentemente me pedem, no mesmo dia e antes de fazer backup, para recuperar um pedido, um cliente, etc, que foi excluído indevidamente.
Criei uma tabela chamada "bd_deleted" com os campos: tabela, campo, tipo, valor, etc, onde armazeno cada campo, tipo e valor do registro a ser deletado, antes de ser excluído da tabela original, de modo que posso recuperar este registro "deletado" de volta à tabela original.
Ainda não descobri uma forma mais prática de fazer isto no sql.

Att,
Eduardo Fernandes

[Vlademiro]

No sql o método mais usado é através de triggers. Mas vc pode implementar isso no seu sistema, caso seu bd não tenha triggers.

https://www.google.com/search?q=trigger ... +auditoria

[Kiko Fernandes]

Bom dia pessoal.
Eu trabalho com SQL desde 2006, ano em que fui largando o DBF. Porém esta necessidade me perturbou no início e por ficar encucado desde esta época passei a adotar em todas as tabelas criadas um campo isdeleted que grava valor 1 para os que foram deletados. Então sempre tenho um where isdeleted!=0 como filtro em todas as consultas.
Acabo deixando a opção de excluir (delete) quando necessito fazer uma manutenção no banco de dados.
Não vou dizer que seja a melhor solução mas desde então tenho usado desta forma e tem satisfeito as necessidades em relação a situação ocorrida.

[JoséQuintas]

para recuperar um pedido, um cliente, etc, que foi excluído indevidamente.

De um modo geral é tentar impedir exclusão indevida.
NÃO permito excluir cliente em uso, produto em uso, pedido faturado, pedido confirmado, etc.
No caso de clientes e produtos tenho a opção de desativar, afinal, relatórios anteriores ainda precisam da informação, mesmo que daqui pra frente não usem mais.

É raro precisar de informação excluída, mas já aconteceu.
Se for de dia anterior, o backup ajuda, mas se for do mesmo dia... aí sem opção - no MySQL.

Ao cancelar uma nota, o pedido volta pra situação não confirmado.
Isso permitiria reemitir a nota sem precisar digitar tudo de novo.
Mas certas opções deixo só pro administrador, como por exemplo reutilizar o número de uma nota cancelada.

Aliás... isso depende de cada cliente.
Tem cliente onde quem cancela não é o mesmo usuário que emite.
Tem cliente onde não é qualquer pessoa que pode fazer cadastro.
Tem cliente onde só pode vender pra determinado cliente se houver uma tabela de preços para aquele cliente.
Mas tem exceção onde no cliente não tem controle, mas nesse caso, a própria bagunça não permite conferência, e retornar coisas excluídas poderia ser só mais uma coisa pra não ter controle - por exemplo trazer de volta coisa errada kkkk

[lwinter]

Precisamos nos acostumar trabalhar com banco de dados relacional.
Existem muitas boas praticas que nao usamos em DBF. Eu fazia uso dessas boas praticas na minha empresa mas eu nao botava a mao na massa.
Estou reaprendendo tudo de novo junto com muitos deste forum.
Entre essas boas praticas estao, usar exclusao logica (ativo/inativo) sempre que possivel.
Fazer backup atraves de Sotored Procedures e triggers dos registros deletados em outro banco de dados.
Fazer insert de movimentos em Dateware house ou data lake.

Bom, espaco? Precisamos tirar dessa nossa cabeca a questao de espaco em disco e espaco em memoria. Este paradigma foi impregnado em nos devido ao tempo que estamos no mercado e foi uma heranca do clipper e DBF, querendo ou nao.
Precisamos pensar bola para frente e ficar mais proximos do mercado. Senao nunca teremos clientes novos (novos na sua empresa e de idade...rsrsrs...).
Brincadeiras a parte voces tem a faca e o queijo na mao. Basta ter forca de vontade e reaprender fazendo novos cursos e refaturando ou ate mesmo refazendo do zero seus codigos. Sempre tem uma estrategia que fara mais sentido e trara menos esforco.

[lwinter]

A vida nao é facil.
Programar nao é para qualquer um!
Voce ja sao programadores, tem de ter orgulho do que voces fazem!
Nao desista de querer inovar e se reinventar. Tenho certeza que todos podem e devem!