Hi all, I have the following scenario. We have a database on a 2005 box, which we need to keep in sync with one on a 2014 box (until we can turn off the one on 2005). The 2005 database is still being updated with changes that must be applied to the 2014 database, given the nature of the data (medical documents) we need to ensure updates are applied to the 2014 database in very near real time (these changes are - for example - statuses, not the documents themselves). Cunning plan #1, ulgy - not at all a fan of triggers - but use an after update trigger to run a sp on the remote box via a linked server in this format, with a SQL Server login for the linked server with permissions to EXEC the remote proc.CREATE TRIGGER [dbo].[SourceUpdate] ON [dbo].[SourceTable] AFTER UPDATEAS SET XACT_ABORT ON; SET NOCOUNT ON; IF UPDATE(ColumnName) BEGIN DECLARE @Value1 VARCHAR(25), @Value2 INT; SELECT @Value1 = Value, @Value2 = OtherValue FROM inserted; EXEC [WIBBLE].Target.dbo.Proc @Param1 = @Value1, @Param2 = @Value2; END However, while the sp can be run against the linked server as a standalone query OK, when running it in a trigger it's throwingOLE DB provider "SQLNCLI" for linked server "WIBBLE" returned message "The transaction manager has disabled its support for remote/network transactions.".Msg 7391, Level 16, State 2, Procedure TheAfterUpdateTrigger, Line 19The operation could not be performed because OLE DB provider "SQLNCLI" for linked server "WIBBLE" was unable to begin a distributed transaction. I've googled a bit, and while I can find a number of people with the same issue no effective fix or definitive statement that it can't be done. Does anyone know whether it actually possible to call a proc on a remote box via a trigger and if so what additional hoops need to be jumped through (like I said, it'll run OK called via SSMS)? If not, wandering further down the path labelled Grim Kludge, anyone know if this would work in a <Shudder> CLR Trigger? Other than that, the only thing I can think of is replication to the remote and updating based on the changes to the replicated table - I have no idea which I reckon's worse ... :pinch: If anyone has any less horrible suggestions, they'd also be welcome
↧