Hello all!
There is a bug in SQL-2005/2008 Replication system, which may break data integrity, when using @.@.IDENTITY function to update FOREIGN KEY of some table.
When Merge replication is set up, and there is a table article with IDENTITY column in it, after inserting a new row in the table a value of @.@.IDENTITY function does not actually shows just inserted row's identity value.
This issue also generated when performing inserts via ADO.
For details, see my Feedback to Microsoft:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=286165
Also, there are other comments on this problem:
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.data.ado&tid=dcb56477-15fe-413e-a90a-3e1816bc7375&p=1
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=281682
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=284124
SQL Server Katmai July CTP has been released. But the bug described above is not resolved there. It still can be generated the same way! However, the feedback is marked as "Resolved"...
|||it looks like it was resolved as by design. do you have any of the feedback or reasons this was marked by design?
|||You should not rely on @.@.identity and propgram your solution.
You should rather look at using scope_identity.
|||Thanks, Greg and Mahesh!
Now I understand, why it market as "Resolved by Design". But there is another problem: ADO itself uses @.@.IDENTITY instead of SCOPE_IDENTITY when inserts a value to a table. So, it seems impossible to use SQL-clients based on ADO in Merge Replication!
No comments:
Post a Comment