You are a database administrator for AIOTestKing.com. Your company owns a chain of 10 retail stores. Each retail store maintains point-of-sale transactions on its own SQL Server 2005 computer, in a database table named Sales. The Sales table also contains sales data from other stores to enable customer returns to any of the 10 retail stores. The sales data is refreshed from the main office to each retail store hourly. A trigger named trg_Coupon on the Sales table is used to generate sales coupons based on customer sales and buying patterns. You need to configure replication between the server in each retail store and a central server in the main office by using the fewest number of steps. Replication does not have to be in real time. What should you do?
A.
Use transactional replication between the server in each retail store and the central server in the main office.
B.
Set up multiple merge publications, one at each retail store and one on the central server in the main office.
C.
Use snapshot replication. Configure the trg_Coupon trigger on the server in each retail store to use the NOT FOR REPLICATION option.
D.
Use merge replication. Configure the trg_Coupon trigger on the server in each retail store to use the NOT FOR REPLICATION option.
Explanation:
Merge replication, like transactional replication, typically starts with a snapshot of the publication database objects and data. Subsequent data changes and schema modifications made at the Publisher and Subscribers are tracked with triggers. The Subscriber synchronizes with the Publisher when connected to the network and exchanges all rows that have changed between the Publisher and Subscriber since the last time synchronization occurred. Merge replication is typically used in server-to-client environments. Merge replication is appropriate if Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers. In some cases, it is desirable for user activity in a replication topology to be treated differently from agent activity. For example, if a row is inserted by a user at the Publisher and that insert satisfies a check constraint on the table, it might not be required to enforce the same constraint when the row is inserted by a replication agent at the Subscriber. The NOT FOR REPLICATION option allows you to specify that some database objects are treated differently when a replication agent performs an operation: