Earlier this year, I began work on a project on which I recommended Microsoft Synchronization Services for ADO.NET for use as our synchronization solution. Our application is a desktop (WinForms, no WPF - maybe more on that decision later) application that needs obtain and work with both reference data and bi-directional data (i.e. data created/updated by the user or the server). The database we are exchanging data with happens to be Oracle, so a solution leveraging SQL Server Merge Replication was out.
Given that my Oracle skills were, at that time, rusty at best, I thought I would check out the example that Rafik posted for using Sync Services with Oracle. Fair enough. Once I got it working as-is, and before I began writing code against our database, I thought I would verify that it worked with ODP.NET.
Why ODP.NET? We were looking to leverage some of the capabilities available in that provider vs System.Data.OracleClient.
I changed out my references, made the necessary code changes and attempted to run. Shortly after I invoke a sync, I receive the following error:
Type ‘Oracle.DataAccess.Types.OpoDatCtx’ in Assembly ‘Oracle.DataAccess, Version=2.111.6.20, Culture=neutral, PublicKeyToken=89b483f429c47342′ is not marked as serializable.
My initial reaction was to wonder what I had done incorrectly, or had forgotten to do. I checked the code. Thrice. Nothing missing. Stymied, I posted to the Sync Services for ADO.NET forum with suspicions that OpoDatCtx was internal to ODP.NET. Sean Kelly from Microsoft replied to my query. In sum, Sync Services was only ever intended for use use against Microsoft-implemented/shipped ADO.NET providers.
As (thank you, Reflector), OpoDatCtx is (as I suspected) an internal type and one I could not convert, this meant I had two option:
1) Return to using System.Data.OracleClient and deal with any ‘shortcomings’ compared to ODP.NET.
2) Dump Sync Services so that we could use ODP.NET, but roll all the sync code from scratch.
As you might have guessed, I chose option 1, and Sync Services is working swimmingly against Oracle.