A call to action for a new Heterogeneous Sync Framework

B"H

We need a framework to sync separate unrelated data sources . Like LDAP & Outlook, or Outlook and your custom in-house CRM.

I am constantly coming across scenarios that sound exactly like this, and every time it seams like I am re-inventing the wheel and building the entire solution over again. I am actually quite confident that everyone reading this post will have dozens of examples similar to what is described here.

I have come to the conclusion a while ago that this problem domain needs to be abstracted and then we can build a framework to handle some of the recurring themes. I was really excited when I found Microsoft Sync Framework because I thought it was exactly that type of abstraction. However after researching it for about two months now, and implementing it a few times. I have to conclude that it is not what we are looking for.

We need a Heterogeneous Sync Framework. A Framework to sync unrelated (but naturally relatable) Data Sources.

The Microsoft Sync Framework deals too much with the relationship and change tracking. It assumes that you are starting with matching data, and only then, does it changes over time.

We need a Sync Framework that assumes that we have conflicting data at every step, and we have no idea how it got that way. Because the data is coming from two sources that couldn't give a darn about each other.

Enough ranting for now.
If anyone knows of such a framework, or wants to start working on such a framework with me (it would need to be much less complicated than Microsoft's solution), or knows how SyncFX can gracefully handle these scenarios. Please POST A COMMENT!

Thank you

Microsoft Sync Framework Data Provider ignores records where a field in the PK changes

If you update a field in a primary key, the SqlServer Provider does not record a change (or insert-delete). Therefore your change never gets propagated and you are left with an orphan record.

There goes SQL Azures SSL support again

B"H

this morning, I tried accessing some Ms Access reports that have worked just fine in the past, and all of a sudden the gave the error "The certificate's CN name does not match the passed value."

When I checked my c# clients and saw that they were all working fine I remembered seeing this post on MSDN forums. which told me to add "TrustServerCertificate=true" to my ADO.net connection string. I had done that back then, and that was what was making my c# clients work, so I needed a way to add that to my ODBC parameters.

Thank G-D, I recently switched the way that I have my clients specify ODBC parameters on their personal computers.

I destribute a *.reg file which creates a User DSN on their computer.
Then all of my ODBC connections refer to that DSN, knowing that it will definitely exest on their computer or I can just instruct them to run the *.reg file.

So this morning all I had to do was figure out the correct syntaxt for "TrustServerCertificate=true" in ODBC and redistribute the *.reg file and instruct all of my clients to rerun the file.

the file now looks like this:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\NameOfDSN]
"Driver"="c:\\Windows\\system32\\sqlncli10.dll"
"Server"="NameOfMyServer.database.windows.net"
"Database"="NameOfDatabase"
"Encrypt"="Yes"
"TrustServerCertificate"="Yes"
"LastUser"="username@NameOfMyServer"
"Trusted_Connection"="No"
"AutoTranslate"="No"

[HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\ODBC Data Sources]
"NameOfDSN"="SQL Server Native Client 10.0"

replacing NameOfDSN with the actual name of the DSN and NameOfMyServer with the actual name of the server

I hope this helps someone.