December 9, 2001 at 6:07 pm
Is there a method with which to allow the transactions performed by specific users to not be replicated in an environment with one publisher and multiple subscribers?
I want to create a user on the database who can perform INSERT/UPDATE/DELETEs without having them replicated to the subscribers.
One thing I've thought of is to use stored procedure replication and alter the replication procedures to ignore the particular user. Unfortunately, this is a lot of procedures to modify. Is there an alternative?
Is there a command within INSERT/UPDATE/DELETEs that can be used so they will be ignored for replication? That would be ideal, but I don't think it exists from what I've read through so far. Thanks
December 10, 2001 at 4:44 am
If you store the user that makes the modification in the table, then you could use a filter. One simple option might be to use a trigger on the table to set a flag that indicates if it should be replicated or not.
Modifying the replication stored procedures on the client would work. The down side (in addition to the work to modify all of them) is that you will not be able to validate your subscription. Row counts will not match and unless you have the user id stored as part of the record, how would you know which records should be where to try to validate it yourself. Another flaw is that when you reinitialize, either because of a problem with a subscription or to set up a new one, it's going to get all the data and create the standard stored procs, not the modified ones. You can avoid some of this by running a post snapshot script that would modify the original procs and maybe remove the data that shouldnt have been sent over (if you can identify it!).
Depending on how you identify the data, you could also just run a subscriber side job that would delete any matching rows out of all the concerned tables. Would save modifying the procs anyway.
Andy
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply