Foreign key relationships are lost during syncing using MS Sync Framework

I have seen several posts on this site, and on others, stating that the problem is usually caused by the order in which the tables are added to the Configuration of the SyncAgent on the client side, or the SyncAdapter on the provider side. I believe I have my ordering of the tables correctly in both these places (I have an N-Tier architecture - a web service that is providing sync functionality).

Does anyone know of any other potential cause for this behavior?

Also: Sycning works for all tables, except one. For some reason, that table is created on the client but, no records are transferred...even on the initial sync, when the database is created on the client. Any ideas?

Any help would really be appreciated. (getting this sync functionality to work, and then the data entities for the client to use based on the synced data, is turning into a life mission. Don't you just love working with (massive) Frameworks?)

Thanks very much for whatever you can suggest.

[UPDATE: I have found the problem that caused the records for one table to be omitted from the sync, while the records from all the other tables were synced. The InsertId column for the table in question was full of NULL values, and UniqueIdentifier data can't be compared to NULL. The other tables don't have an InsertId colu开发者_如何学编程mn, because they are for download only. Still, the main problem of no Foreign Key relationships persists]

---

OK, I found this statement:

By default, the following constraints are not copied to the client: FOREIGN KEY constraints, UNIQUE constraints, and DEFAULT constraints

in this document: http://msdn.microsoft.com/en-us/library/bb726037.aspx

So, it appears I have to "manually" create the relationships, once the schema is created on the client.

---

It is crucial that you add the adapters to the server side provider in the correct order. You also need to make sure that you avoid all multi-table circular references or you will need to write some complicated multi-pass synchronization logic to sync first the tables without the foreign keys and then the foreign keys after the fact. Perhaps a circular reference is why you are losing just the one table. Good discussion of the issue here http://www.8bit.rs/blog/2009/12/replicating-self-referencing-tables-and-circular-foreign-keys-with-microsoft-sync-framework/.

When I was working on this same problem last month, I found that using the INFORMATION_SCHEMA, you can write a pretty good stored procedure to dynamically determine the relationship hierarchy for use in setting up a generic synchronization provider. Let me know if you are interested in something like this...

---

One workaround for syncing Foreign Key Relationships is explained in my answer here Sync Framework 2.1 Foreign key constraints