• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1137
  • Last Modified:

SQL 2005 Replication and NOT FOR REPLICATION attribute

I am not a DBA or an SQL expert, but I’ve been around long enough to understand things (specially if you treat me like if I were Forest “Dumb”  ja,ja )

Background:
• SBS Box running SQL 2005 (Workgroup Edition – Processor License) holding a DB in SQL 2000 compatible mode
• Third party development company develop and app that uses that DB through a web site hosted on the same box
• Application is being in use since Dec. 2005
• Snapshot replication was set to produce a daily COMPLETE snapshot of the DB with the respective publication. On an another SBS box, running SQL 2000, a subscription is created to daily pull the snapshot

Problem:
• Suddenly, update to tables started to fail. Developer review code and DB structure and pointed out the only visible difference : there was a “column property” for the table primary key called “Not for replication” that was set to YES. Developers said that his affect the IDENTITY and caused the application not to update the table contents.
• We focus primarily on the most important table and never checked if the update problem happened on other tables as well.

Current Situation:
• In sake of time, we drop replication and change that property to NO in all tables. The update works now.

QUESTIONS:
1. Does this make sense to you experts?
2. Could replication cause all this and if so, what measures need to be taken in consideration for the application to work with replication?

Thanks in advance
0
phermi
Asked:
phermi
1 Solution
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
>Suddenly, update to tables started to fail.
what error messages?
0
 
phermiAuthor Commented:
angelIII,

thanks for your reply. None, no error messages ... just data input was not recorded. Developers stated this attribute affected that the way they "invoke" (maybe wasn't even that the term) the IDENTITY in the code.

0
 
lokeshgm7Commented:
Hi,

Technically we set “Not for replication” to yes if we have a Parent - Child relationship between tables that are a part of replication.

In the above case suppose “Not for replication” is set to false, If the child table is updated first at the publisher which is dependant on a parent table and this needs to be replicated, at the subscriber the child table recieves the data and instantly a trigger gets fired at the child table(of the subscriber) to check the constraints corresponding to parent table. During that time if the parent table(At the subscriber) has not recieved the replicated data it is supposed to, it throws a "Primary Key Violation" which will roll back the transaction (I mean to say replication in your case). The distribution agent will be one to throw primary key violation error. Inorder to aviod this We set “Not for replication” to true on some tables and triggers that may have Parent child relationship so that in case the child table at the subscriber recieves the data before the parent table, we dont want the triggers to be fired to check the constraints.

I hop this asnwer is satifactory. For more info check "Not for replcation" in SQL Server 2000 books online.
0

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now