SQLServer to SQLServer using Triggers

  • We have a third party software package for our payroll system and it uses its own SQL Server. I am wanting to transfer the data from this server to our production server. For example, the payroll server has the employees name, phone number, working location, etc. I need this information on our production server. I have set up a stored procedure using the appropriate link server commands and it works fine on its own. As soon as I try to call the stored procedure from an update trigger, I get the following error message. "The procedure 'sp_addlinkedserver' cannot be executed within a transaction." Is this the wrong approach? Or is there a work around to this error? Thanks in advance for the help.

  • Hey,

    Can the Linked Server not be a permanent? Or is this an issue for your company?

    If you could have a permanent Linked Server, this would resolve your issue

    If you don't want that permanently you could do it this way...don't know if this a good method or not...comments are appriecate :o)

    Create a DTS to transfer the data between the two servers.

    Within the SP run xp_cmdshell and call the DTSRUN utility. example...

    CREATE PROC MyTestProc

    AS

    EXEC master.dbo.xp_cmdshell 'dtsrun /S<Server> /U<UserID> /P<Password> /N<DTSName>'

    GO

    Of course, others could well have a better solution! :o)

    Clive Strong

    clivestrong@btinternet.com

  • Yes they can be linked permanently. How is this established? If the connection is ever lost between the two servers, how would you recomend to re-establish the connection?

  • Doing this in a trigger essentially implements 2 phase commit between two servers, what DTC does. If your 2nd server is unavailable or the network is slow, you will not be able to do transactions on server1. A BAD idea in most cases.

    I'd implement replication OR some job to move the data periodically (every hour, day, minute, whatever).

    Steve Jones

    sjones@sqlservercentral.com

    http://qa.sqlservercentral.com/columnists/sjones

  • Agree, I've got one dependency left like that it and it truly sucks. Replication is the easiest way to resolve it, the downside is that changes to the source table become a little more difficult.

    Andy

    http://qa.sqlservercentral.com/columnists/awarren/

  • Thanks for the replies. This is what I thought. Currently my approach is to create the appropriate triggers to update a local table (audit table) and then use a stored procedure. This stored procedure can link to the other server and I can fire it off perodically. The problem with using replication is that the payroll server is still on SQL 7.0 and the production server is SQL 2000. I also do not want to risk any security holes by setting up replication.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply