Sim, isso sabemos, analisando por tudo que é óbvio, não faz sentido o problema.

Quanto a transação eu posso iniciar transação, fazer vários comentaos, depois o commit.

ou, conexao.execute "um ou vário comandos sql separados por ;" que executa direto

então

conn.execute "comando de log"

conn.execute "comandos inclusao nota"

emissao danfe

transmissao xml

conn.execute "comando log de finalizaçao da nota numero x"

fecha tela do sistema

nota não está,, log´s estão.

lembrando isso acontece 1 em cada 200 ou mais notas, 1 vez ao mes. 2 em 50 clientes.

então, 99,9% das vezes funciona.

a lógica é bem simples, como acima não tem erro de codigo senão aconteceria com muito mais frequencia.

caso a gente ache a solução, vou postar no fórum


Em 07/02/2017 07:46, Ivo Sestren Junior escreveu:
Não entendi esta situação da transação.
Todos os comandos devem ser executados dentro de transação, nem que sejam autocommit. Não pode ter acontecido dos logs estarem em uma transação e os registros da nota em outra, e exatamente o da nota ter dado rollback?

Porque é bem estranho, porque se houve perda de dados, normalmente há corrompimento da base de dados, já que a integridade dos dados foi perdida.
Ou realmente alguém ou algum processo deu rollback ou excluiu os dados.

Em 7 de fevereiro de 2017 06:54, Forsell - Erlon <fors...@forsell.com.br <mailto:fors...@forsell.com.br>> escreveu:

    O log é gravado em uma tabela no postgres, e a função é chamada em
    todo lugar no sistema

    no caso da nota fiscal, chama ao incluir a nota, ao importar os
    dados de uma venda, ao finalizar a nota, enviar para receita, está
    tudo no log

    foi retirado uso de transação substituido por disparar vários
    comandos sql de uma vez no banco de dados, o que é praticamente
    igual a uma transação e o problema voltou a acontecer mesmo assim.

    gravou a nota, gerou xml, transmitiu a receita, fechou a tela  do
    sistema o dado não permaneceu gravado.

    porém os registros do log indicando a gravação da nota estavam lá

    não tem erro no sistema pessoal, isso acontece em um cliente 1 vez
    por mês, uma nota em 200.

    mas entendo que se realmente ningúem viu esse tipo de situação
    acontecer fica dificil ajudar mesmo.

    o mesmo sistema é usado em 50 clientes, e só em 2 locais que
    acontece, estamos apostando em tentar verificar a rede ou mudar o
    servidor para outra máquina. mas é muito estranho o dado ter
    existido banco de dados e não permanecer lá após fechar o sistema
    (mesmo sem usar transação).



    Em 06/02/2017 17:56, Euler Taveira escreveu:

        On 06-02-2017 15:02, Forsell - Erlon wrote:

            Só sabemos que os dados estavam lá, porque temos uma
            tabela de log
            nosso, nessa tabela indica a criação da nota daquele número
                 o cliente possui o pdf do danfe impresso e enviado
            via email ao
            cliente - danfe gerado com os dados da base de dados.
                 fechou a tela de emissão de nota, a informação deixou
            de estar
            gravada no banco de dados
                em ambas situações, com transação (devidamente
            concluida) e retirado
            transação feito por comando normal.

        Você precisa responder algumas perguntas:

        (i) como é gravado esse log? Gatilho? Aplicação? Na mesma
        transação?
        Antes dos dados? Depois dos dados?
        (ii) vocês auditam DELETE? É possível que alguém tenha
        removido um registro?
        (iii) quais os parâmetros reportados pela consulta [1].
        (iv) a sua aplicação usa alguma camada de persistência? Se sim, já
        verificaram se ele por acaso não persistiu os dados por algum
        erro?
        (v) a sua aplicação usa blocos de transação explícitos? Há
        verificação
        de erros de transação nesse trecho de código?

        A última vez que vi o postgres perder dados por falha do
        software foi na
        7.0 (a mais de 15 anos atrás) -- onde não existia WAL ainda.


        [1]
        https://gist.github.com/eulerto/450501d8ef00404e665b46a2f2a6e8e2
        <https://gist.github.com/eulerto/450501d8ef00404e665b46a2f2a6e8e2>



    _______________________________________________
    pgbr-geral mailing list
    pgbr-geral@listas.postgresql.org.br
    <mailto:pgbr-geral@listas.postgresql.org.br>
    https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
    <https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral>




_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a