• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1153
  • 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 )

• 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

• 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.

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
1 Solution
Guy Hengel [angelIII / a3]Billing EngineerCommented:
>Suddenly, update to tables started to fail.
what error messages?
phermiAuthor Commented:

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.


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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

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