BeginTrans se perde

[Claudio Andrade 0]

Olá a todos, postei essa mesma dúvida no tópica de PROGRAMAÇÃO - VB, pois o problema acontece em uma aplicação construida em VB6, contudo estou postanto aqui pois também trata-se de um procedimento de BD.

 

O grande problema é o seguinte:

 

Tenho um processo grande com vários INSERT, UPDATE e DELETE, no inicio desse processo inicio uma TRANSAÇÃO com o objeto de conexão do BD (SQL Server), em um determinado momento dentro de um LOOP há uma chamada de PROCEDURE de inclusão, cujo a tabela utilizada possui uma TRIGGER para startar outro procedimento, tudo acontece normalmente na primeira passagem do LOOP, contudo ao inserir o segundo registro a TRANSAÇÃO é perdida e como o processo no modo geral não foi terminado o procedimento de COMMITE não é executado.

 

O problema maior é que não retorna nenhuma mensagem de erro. Gostaria de uma ajuda o mais breve possivél para resolver este problema.

 

Desde já agradeço!

 

Claudio Andrade

[Dee 0]

Porque você nao faz o Begin Transaction Dentro da instrução SQL ao invés de fazer no VB ??

 

Begin Transaction
  .
  .
  .
  .
Commit

Se ele não der o Commit, automaticamente ele da um RollBack.

[Claudio Andrade 0]

Porque você nao faz o Begin Transaction Dentro da instrução SQL ao invés de fazer no VB ??

 

Begin Transaction
  .
  .
  .
  .
Commit

Se ele não der o Commit, automaticamente ele da um RollBack.

 

Dee,

 

Valeu pelo esforço, mas não posso fazer isso pela procedure, pois o processo é iniciado pelo aplicativo.

 

Descobri que o problema é a com a PROCEDURE chamada pela TRIGGER, ou seja, o SCRIPT dessa procedure possui blocos de comandos de INSERT, portanto se eu isolar apenas o primeiro bloco o aplicativo funciona normalmente, retornando o SCRIPT a TRANSAÇÃO se perde. Esse procedimento é conhecido como execução em LOTE, onde a Microsoft diz que precisa ser separado por GO em outros casos por "ponto e virgula", contudo mesmo com essa separação o problema ainda continua.

 

Estou batalhando para resolver o problema, caso tenha alguma novidade postarei a solução.

[quintelab 91]

Claudio você postou o mesmo tópico em dois lugares diferentes aqui no fórum. Isso não é permitido.

Irei fechar algum tópico. O problema é no VB ou no Banco de dados?

 

Abraços...

[Claudio Andrade 0]

 

Porque você nao faz o Begin Transaction Dentro da instrução SQL ao invés de fazer no VB ??

 

Begin Transaction
  .
  .
  .
  .
Commit

Se ele não der o Commit, automaticamente ele da um RollBack.

 

Dee,

 

Valeu pelo esforço, mas não posso fazer isso pela procedure, pois o processo é iniciado pelo aplicativo.

 

Descobri que o problema é a com a PROCEDURE chamada pela TRIGGER, ou seja, o SCRIPT dessa procedure possui blocos de comandos de INSERT, portanto se eu isolar apenas o primeiro bloco o aplicativo funciona normalmente, retornando o SCRIPT a TRANSAÇÃO se perde. Esse procedimento é conhecido como execução em LOTE, onde a Microsoft diz que precisa ser separado por GO em outros casos por "ponto e virgula", contudo mesmo com essa separação o problema ainda continua.

 

Estou batalhando para resolver o problema, caso tenha alguma novidade postarei a solução.

 

Prezados,

 

Postei em dois lugares diferente pois até o presente não sabia a ORIGEM do problema, contudo como estava precisando resolver logo o problema, o nosso grupo analisamos e descobrimos o problema e a origem:

 

O problema encontrado foi na modelagem de dados entre a tabela PAI e um tabela FILHO. PORTANTO SENDO DE BD.

 

Porem deixo aqui outra pergunta, porque que o SGBD (SQL Server) não reportou a mensagem de erro, que nesse caso foi de "chave PK duplicada" para o aplicativo?

 

É por esse motivo que a transação era "PERDIDA", gerando um ROLLBACK finalizando a TRANSAÇÃO. Lembro que esse processo era desencadeado por uma TRIGGER, que chama várias PROCEDURES e uma dessas que estava inserindo nas tabelas com erro de modelagem.

 

Será que é porque o aplicativo executa uma PROCEDURE que insere dados em uma TABELA que possui uma TRIGGER, que apartir desse ponto o processo? Nesse caso não sendo gerenciado pelo aplicativo!

 

Esse é um mistério que poderiamos conhecer o conceito.