locked
Trigger for insert for replication RRS feed

  • Pergunta

  • Comunidade!

    Possuo replicação transacional com assinantes atualizaveis.

    Um dos assinantes possui uma trigger for insert for replication.

    Outro assinante efetua um insert na tabela em uma transação. Após, em outra transação efetua um update.

    A tabela "inserted" da trigger for replication, quando ativada pela replicação (e não pelas ações do próprio assinante) possui dois registros.

    Ratifico que quando o mesmo processo é executado no próprio assinante da trigger este problema não acontece. Apenas acontece quando a trigger é ativada por algum assinante. É como se a trigger fosse for insert, update. Entende?

    Utilizo SQL 2005 Standard em todos os membros da replicação.

    Alguem tem alguma ideia do que pode estar acontecendo?

    Muito obrigado pela atenção!

    Thiago.

    • Movido Gustavo Maia Aguiar segunda-feira, 3 de maio de 2010 16:47 (De:SQL Server - Desenvolvimento Geral)
    • Movido Gustavo Maia Aguiar segunda-feira, 3 de maio de 2010 18:13 (De:Gerenciamento, Configuração, Instalação, e Segurança)
    segunda-feira, 3 de maio de 2010 14:33

Todas as Respostas

  • Thiago,

    Desculpe-me, mas não consegui entender o seu problema!!!!


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    segunda-feira, 3 de maio de 2010 17:37
    Moderador
  • Hehehe, Junior, por favor, me desculpe por não ser claro o suficiente!

    1) Existe um processo em um aplicativo que insere um registro em uma tabela publicada, e, logo em seguida o atualiza. (insert seguido de update).

    2) Em apenas um membro da replicação, existe uma trigger for insert for replication.

    3) Esta trigger, passa as pks mantidas na tabela lógica "inserted" por meio de um cursor e as loga em outra estrutura.

    4) Quando os dados são inseridos via replicação (dados dos outros assinantes) este log das pks que me refiro no item 3 fica duplicado. (Como se a tabela inserted tivesse 2 registros de mesma pk, ou, a trigger fosse disparada duas vezes para a mesma pk).

    5) Quando o mesmo processo é executado no membro que possui a trigger (portando não vem via replicação) o log que me refiro no item 3 está correto.

    Ratifico que a trigger em questão é apenas para insert. O que no meu ponto de vista não fundamenta a hipotese que há 2 registros na tabela inserted (diferente se fosse for insert, update).

    Volto a agredecer a atenção Junior e comunidade que anda acompanhando a thread!

    Thiago.

    segunda-feira, 3 de maio de 2010 18:10
  • Thiago,

    Mas como você esta utilizando um trigger for insert replication o SQL Server esta realizando a duplicação da transação, fazendo que o mesmo registro seja inserido e reconhecido como duplicado.

    O que você deseja fazer? É realmente necessário fazer este transporter dos códigos das Pks para a outra table?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quarta-feira, 5 de maio de 2010 18:38
    Moderador
  • Minha vez de não enteder Junior!

    "Duplicação da transação" por culpa de trigger for insert for replication?

    Ah, esqueci de comentar. O processo estava ok até a tabela sofrer uma alteração de estrutura.

    alter table table add column c1 bit not null constraint df_table_c1 default 0.

    A partir desta alteração o problema começou. Acredito que houve alguma falha interna durante a criação das triggers de sistema do sql server ou algo do tipo.

    Alguem possui alguma dica, ou já passou por algo parecido?

    segunda-feira, 10 de maio de 2010 18:18
  • Thiago,

    Você disse que a table sofreu alteração na estrutura, mas qual table? A table da base Subscription?


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    segunda-feira, 10 de maio de 2010 18:23
    Moderador
  • Junior,

    A table sofreu altaração no publicador da replicação, aplicando (via replicação) aos assinantes como previsto e de costume. Porem,  a partir daí, a trigger for insert for replication, passou a disparar para updates também, porém apenas quando o update tem origem da replicação (comportamento errado). Nunca quando o update é feito no proprio assinante (comportamento correto).

    O que quero é que a trigger for insert não dispare com updates, independente da origem (se replicação de dado, ou update local).

    terça-feira, 11 de maio de 2010 13:58
  • Thiago,

    Entendi, então trigger você configurou para que o mesmo seja executado quando ocorrer algum Update na Table?

    Por se tratar de um trigger de replicação seu comportamento esta relacinado com a base do publicador.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quarta-feira, 12 de maio de 2010 18:00
    Moderador
  • Junior,

    Não quero que a trigger for insert seja disparada quando ocorre um update.
    Isto passou a ocorrer após o add column comentado em outra resposta.

    Cenario:

    Em outra instancia assinante (e apenas nesta instancia) há uma trigger for insert for replication:
    - create trigger tr1 on tabelaA for insert for replication as select 'a'

    Na instancia publicadora não há trigger de usuáio alguma na 'tabelaA'. Nesta instancia ocorre o comando sql:
    - update tabelaA set campo = 'campo' where id=1

    O que ocorre é o disparo da trigger do assinante quando o update executado no publicador é replicacao. Se rodar o mesmo update localmente no assinante com a trigger, a trigger não é disparada.

    Problema continua. Espero não terque apelar para a redistribuição dos assinantes. Tarefa muito onerosa pela distancia fisica entre os assinantes e tamanho das bases.

    Thiago.

    terça-feira, 18 de maio de 2010 13:31
  • Thiago,

    Sinceramente não imagino, estou procurando diversas fontes de informação e até agora nada, o que me deixa confuso é essa situação de um trigger ser disparado, sendo que, o trigger é um recurso realizado somente quando ocorre algum tipo de manipulação de dados, na table ao qual ele esta vinculado.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    terça-feira, 18 de maio de 2010 17:40
    Moderador
  • Junior,

    Muito bacana esta troca de conhecimento e hipoteses que o forum proporciona!

    E para dar sequencia no caso, não se foi consequencia do add column, ou o comportamento ja existia antes e ninguem se deu conta, mas peguei outra tabela replicada, tabela que não sofreu nenhuma alteração estrutural desde a publicação. Veja o resultado:

    Quando o update ocorre no proprio assinante: ok, ocorre apenas o update.

    Quando update feito em um terceiro membro da replicação: ocorre o delete do registro nos outros assinantes, e a re-inserção do registro.

    Não sei se esta é uma opção configuravel, ou alguma falha não percebida durante a agregação dos assinantes da publicação.

    Se você tiver alguma dica, mesmo de conciliação de configurações, sou todo "ouvidos"!

    terça-feira, 25 de maio de 2010 11:41
  • Thiago,

    Se você esta trabalhando com replicação merge é normal este comportamento, pois o SQL Server tem o objetivo de manter a mesma versão dos dados disponíveis entre os servidores.

    Em relação a configuração você terá que acessar as configurações da sua replicação e seus respectivos artigos!!!!


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário]
    quarta-feira, 26 de maio de 2010 18:39
    Moderador