问题
Our developer has a linq-2-sql project that talks to my database. The database is involved in merge replication. It has been in use for some time and was working fine. A recent table was added to the schema and now is causing problems when new records are added.
The user get's an error message stating that the index related to the guid that merge replication automatically creates is violating a unique constraint.
From what I can tell the table isn't any different than others that are involved. I have recreated the entire replication publication/subscription model from scratch and everything continues to work but that one table.
Anyone have any ideas? The guid being created appears as 00000000-0000-0000-0000-000000000000 which would explain why it's a duplicate. Why is a valid guid not being created by linq?
回答1:
Did you use "new Guid()" somewhere in your code base when what you meant was "Guid.NewGuid()"?
回答2:
I had faced the similar problem. As Mark has mentioned in the comment, the Guid() needs to be properly used.
Guid asm = new Guid(); // gives 00000000-0000-0000-0000-000000000000
Instead use
Guid asm = Guid.NewGuid();
回答3:
When using Linq-To-SQL, make sure the IsDbGenerated property is true and the Database actually is setup to create an ID (by using newid() as the default value).
Otherwise, make sure the .net code is actually generating IDs.
回答4:
What we discovered while researching your suggestions was that this particular table was the only table that included the guid field at all in the DBML class. All the other tables had been added to the DBML prior to publishing the database for merge replication (hence their respective guid fields were not included in the DBML).
So, I manually deleted the guid field from the problem table in the DBML and the problem went away. The problem was in fact caused by LINQ not creating the guid as it should in the generated classes.
In this case it was easiest to simply leave guid creation to the publication triggers and newid() default value as established in SQL. (it's still in the database, just not the dbml)
Nothing in the application uses those guid fields... it's purely for SQL to manage the merge replication scheme we've implemented - so removing from the DBML was the easiest.
来源：https://stackoverflow.com/questions/7001362/guid-of-00000000-0000-0000-0000-000000000000-causing-merge-index-violation