none
Create Trigger - Banco de dados Diferentes.. RRS feed

  • Pergunta

  • Boa tarde

    Preciso criar uma trigger, que realize o seguinte :-

    Quando ocorrer um INSERT no banco de dados "BD-A" na tabela "TABLE-A", essa Trigger deve criar um outro INSERT no banco de dados "BD-B" na tabela "TABLE-B".

    Os nomes dos campos são diferentes, exemplo :-

    No Banco de dados BD-A na tabela TABLE-A, existe o campo : SEQUENCA(N10)

    No Banco de dados BD-B na tabela TABLE-B, existe o campo : SEQ(N10 )

    Preciso gravar os dados de SEQUENCIA em SEQ.

    Observação :- são um total de 40 campos, que preciso fazer isso... todos com nomes diferentes...

    Obrigado

    terça-feira, 26 de junho de 2012 20:45

Respostas

  • André,

    Suas bases estão na mesma instância?
    Se estiverem crie uma trigger de insert na "TABLE-A" que insira os dados no banco de dados "BD-B", tabela "TABLE-B".

    Abaixo segue um exemplo bem simples:

    ALTER TRIGGER TriggerExemplo
       ON  TabelaA
       AFTER INSERT
    AS 
    BEGIN
    	SET NOCOUNT ON;
    	INSERT INTO BD_B..TabelaB
    	(Seq)
    	SELECT Sequencia FROM inserted
    END
    GO

    A "tabela inserted" é a que possui os dados, no momento da inserção, do seu BD-A. Sendo assim, você faz um select nela, dos campos que quiser (Sequencia) e insere no BD-B, também nos campos que quiser (desde que sejam do mesmo tipo ou que você faça a conversão dos dados)

    Espero ter ajudado.

    []'s


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */


    terça-feira, 26 de junho de 2012 21:25

Todas as Respostas

  • André,

    Suas bases estão na mesma instância?
    Se estiverem crie uma trigger de insert na "TABLE-A" que insira os dados no banco de dados "BD-B", tabela "TABLE-B".

    Abaixo segue um exemplo bem simples:

    ALTER TRIGGER TriggerExemplo
       ON  TabelaA
       AFTER INSERT
    AS 
    BEGIN
    	SET NOCOUNT ON;
    	INSERT INTO BD_B..TabelaB
    	(Seq)
    	SELECT Sequencia FROM inserted
    END
    GO

    A "tabela inserted" é a que possui os dados, no momento da inserção, do seu BD-A. Sendo assim, você faz um select nela, dos campos que quiser (Sequencia) e insere no BD-B, também nos campos que quiser (desde que sejam do mesmo tipo ou que você faça a conversão dos dados)

    Espero ter ajudado.

    []'s


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */


    terça-feira, 26 de junho de 2012 21:25
  • Mariana

    Ótimo, obrigado.....

    André Daniel

    quarta-feira, 27 de junho de 2012 16:25
  • André, por favor classifique a resposta para que o post possa ajudar outras pessoas!

    []'s

    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */

    quarta-feira, 27 de junho de 2012 17:24
  • André,

    Suas bases estão na mesma instância?
    Se estiverem crie uma trigger de insert na "TABLE-A" que insira os dados no banco de dados "BD-B", tabela "TABLE-B".

    Abaixo segue um exemplo bem simples:

    ALTER TRIGGER TriggerExemplo
       ON  TabelaA
       AFTER INSERT
    AS 
    BEGIN
    	SET NOCOUNT ON;
    	INSERT INTO BD_B..TabelaB
    	(Seq)
    	SELECT Sequencia FROM inserted
    END
    GO

    A "tabela inserted" é a que possui os dados, no momento da inserção, do seu BD-A. Sendo assim, você faz um select nela, dos campos que quiser (Sequencia) e insere no BD-B, também nos campos que quiser (desde que sejam do mesmo tipo ou que você faça a conversão dos dados)

    Espero ter ajudado.

    []'s


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */


    Boa tarde Mariana,

    o meu caso é idêntico, só que as bases estão em máquinas diferentes, como eu faria?

    Obrigado.

    sexta-feira, 27 de julho de 2012 15:21
  • André,

    Suas bases estão na mesma instância?
    Se estiverem crie uma trigger de insert na "TABLE-A" que insira os dados no banco de dados "BD-B", tabela "TABLE-B".

    Abaixo segue um exemplo bem simples:

    ALTER TRIGGER TriggerExemplo
       ON  TabelaA
       AFTER INSERT
    AS 
    BEGIN
    	SET NOCOUNT ON;
    	INSERT INTO BD_B..TabelaB
    	(Seq)
    	SELECT Sequencia FROM inserted
    END
    GO

    A "tabela inserted" é a que possui os dados, no momento da inserção, do seu BD-A. Sendo assim, você faz um select nela, dos campos que quiser (Sequencia) e insere no BD-B, também nos campos que quiser (desde que sejam do mesmo tipo ou que você faça a conversão dos dados)

    Espero ter ajudado.

    []'s


    Mariana Del Nero /* Se a resposta foi útil, não esqueça de marcá-la */


    Boa tarde Mariana,

    o meu caso é idêntico, só que as bases estão em máquinas diferentes, como eu faria?

    Obrigado.

    sexta-feira, 27 de julho de 2012 15:21
  • Boa Tarde,

    Sintaticamente a solução está correta. Para máquinas diferentes, você precisaria apenas criar um Linked Server e faz referência. Ex:

    INSERT INTO <LinkedServer>.<Banco>.<Esquema>.<Tabela> SELECT <Colunas> FROM Inserted

    Agora avalie a viabilidade dessa solução. Imagine por exemplo que a outra máquina esteja fora do ar ou sofra indisponibilidade de algum componente como rede por exemplo. A solução da trigger irá impedir que novos registros sejam inseridos, pois, a trigger irá falhar e a transação será revertida. Amarrar as bases com triggers pode não ser um bom negócio.

    Seria bom verificar o uso de mensageria, cargas agendadas, replicação ou concentrar o serviço em uma única base ao invés de criar cópias. Seria uma solução mais robusta, escalável e com percentuais de disponibilidade teóricas maiores.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    sexta-feira, 27 de julho de 2012 18:00
  • Boa Tarde,

    Sintaticamente a solução está correta. Para máquinas diferentes, você precisaria apenas criar um Linked Server e faz referência. Ex:

    INSERT INTO <LinkedServer>.<Banco>.<Esquema>.<Tabela> SELECT <Colunas> FROM Inserted

    Agora avalie a viabilidade dessa solução. Imagine por exemplo que a outra máquina esteja fora do ar ou sofra indisponibilidade de algum componente como rede por exemplo. A solução da trigger irá impedir que novos registros sejam inseridos, pois, a trigger irá falhar e a transação será revertida. Amarrar as bases com triggers pode não ser um bom negócio.

    Seria bom verificar o uso de mensageria, cargas agendadas, replicação ou concentrar o serviço em uma única base ao invés de criar cópias. Seria uma solução mais robusta, escalável e com percentuais de disponibilidade teóricas maiores.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    Boa tarde Gustavo!

    Agradeço pela resposta, desconhecia LinkedServer!

    Mas você acertou o ponto, acho que vai ser péssimo amarrar as bases por triggers, deixe eu expor meu problema:

    O meu projeto é de um sistema de PDV, o que eu preciso fazer é que de forma agendada os BDs dos PDVs recebam um update das tabelas produtos e clientes do servidor e por sua vez também de forma agendada os PDVs vão enviar as informações de vendas de suas bases para o servidor ...

    Qual seria a melhor solução na sua opinião?

    Obrigado.


    sexta-feira, 27 de julho de 2012 18:39
  • Boa Tarde,

    Não sei precisar qual é a melhor estratégia (há vários fatores envolvidos), mas certamente a trigger seria a pior de todas, pois, para funcionar todos teriam que estar conectáveis sempre. Eu analisaria os seguintes pontos para tentar propor:

    • Quantidades de PDVs
    • Quantidade de tabelas envolvidas
    • Quantidade de dados envolvidos

    A Microsoft costuma recomendar a replicação para esse cenário, mas não acho que ela seja sempre a melhor alternativa.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    sexta-feira, 27 de julho de 2012 19:48
  • Boa Tarde,

    Não sei precisar qual é a melhor estratégia (há vários fatores envolvidos), mas certamente a trigger seria a pior de todas, pois, para funcionar todos teriam que estar conectáveis sempre. Eu analisaria os seguintes pontos para tentar propor:

    • Quantidades de PDVs
    • Quantidade de tabelas envolvidas
    • Quantidade de dados envolvidos

    A Microsoft costuma recomendar a replicação para esse cenário, mas não acho que ela seja sempre a melhor alternativa.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    Entendo, no caso é um projeto pequeno, no máximo 10 PDVs, o update servidor -> PDV envolverá 2 tabelas e o PDV -> Servidor também 2 tabelas, replicação seria recomendado?

    Obrigado.

    sexta-feira, 27 de julho de 2012 20:07
  • Boa Noite,

    Sinceramente não sei dizer qual é a melhor solução. Olhando esse cenário, a replicação cai como uma luva, mas vejo problemas em potencial. Se o número de PDVs crescer, o uso da replicação poderá ser um grande complicador, pois, gerenciar tantas assinaturas pode ser bem complexo além do que mesmo com a quantidade atual não sei a sua expertise no assunto replicação.

    Utilizar estratégias como o Service Broker e a mensageria são úteis e mais fáceis de escalar no quesito gerenciamento, mas ainda assim você terá um trabalho inicial maior, pois, é necessário codificar um pouco mais.

    A trigger não se encaixa no seu caso, pois, se os PDVs se desconectarem (propositalmente ou não), o sistema inteiro irá falhar.

    O uso de rotinas de ETL pode ser uma boa saída, mas também envolverá a confecção de pacotes DTSX. Vejo como a mais fácil, mas ainda assim vai depender de uma certa codificação e da sua expertise em SSIS ou algum outro mecanismo usado para tal.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    terça-feira, 31 de julho de 2012 22:37
  • Boa Noite,

    Sinceramente não sei dizer qual é a melhor solução. Olhando esse cenário, a replicação cai como uma luva, mas vejo problemas em potencial. Se o número de PDVs crescer, o uso da replicação poderá ser um grande complicador, pois, gerenciar tantas assinaturas pode ser bem complexo além do que mesmo com a quantidade atual não sei a sua expertise no assunto replicação.

    Utilizar estratégias como o Service Broker e a mensageria são úteis e mais fáceis de escalar no quesito gerenciamento, mas ainda assim você terá um trabalho inicial maior, pois, é necessário codificar um pouco mais.

    A trigger não se encaixa no seu caso, pois, se os PDVs se desconectarem (propositalmente ou não), o sistema inteiro irá falhar.

    O uso de rotinas de ETL pode ser uma boa saída, mas também envolverá a confecção de pacotes DTSX. Vejo como a mais fácil, mas ainda assim vai depender de uma certa codificação e da sua expertise em SSIS ou algum outro mecanismo usado para tal.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    Bom dia Gustavo,

    Eu havia entendido a replicação como uma boa solução para os Updates Retaguarda->PDV mas para os Updates das vendas PDV->Retaguarda não funcionaria pois as bases seriam sempre diferentes então estava atrás de uma outra opção, pesquisei sobre as soluções que você citou gostei muito de mensageria, creio que ela se enquadre perfeitamente ao que preciso fazer, você pode me indicar algum material de estudo sobre mensageria, seja livro ou link?

    Obrigado.

    quarta-feira, 1 de agosto de 2012 13:21
  • Boa Noite,

    Eu já fiz alguns webcasts, apresentações e escrevi sobre soluções de mensageria. Por uma questão de copyright não posso publicar as matérias escritas e quanto as apresentações, acredito que você poderá encontrar no MSDN Experience (procure por Service Broker).

    Pretendo disponibilizar no meu canal do Youtube em breve a apresentação que fiz sobre Service Broker (do SQL Server DF e o SQL Saturday), mas isso ainda vai algum tempo

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    quarta-feira, 1 de agosto de 2012 21:55
  • Boa Noite,

    Eu já fiz alguns webcasts, apresentações e escrevi sobre soluções de mensageria. Por uma questão de copyright não posso publicar as matérias escritas e quanto as apresentações, acredito que você poderá encontrar no MSDN Experience (procure por Service Broker).

    Pretendo disponibilizar no meu canal do Youtube em breve a apresentação que fiz sobre Service Broker (do SQL Server DF e o SQL Saturday), mas isso ainda vai algum tempo

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos:http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível

    Bom dia,

    vou dar uma pesquisada no MSDN Experience, obrigado por todas as respostas, me ajudou muito! Vou acompanhar seu canal e seu blog.

    Abraço.

    quinta-feira, 2 de agosto de 2012 12:00