As those of you who have read any of my papers on synchronizing SQL Server CE (now SQL Mobile) and SQL Server 2000 know - I have not been much of a fan of using Merge Replication with mobile devices. It just wasn't designed for that purpose and was not particularly efficient.
With the changes in SQL Server 2005 merge replication I'm much more of a fan of using Merge Rep on SQL Server 2005 with SQL Mobile. This time Merge Replication is designed to work with mobile devices.
As we've all learned, using anything in a mobile situation presents challenges that don't exist in a more reliably connected environment. So I've been poking around Merge Rep a bunch to get an understanding of the ins-and-outs of using Merge Replication in mobile situations.
Something interesting that I've come across is that there's a real possibility that the SQL Mobile database gets successfully created but the table being replicated does not.
Here's some standard SQL Mobile Merge Rep code.
repl.InternetUrl = @"http://theserver/AdvWorksMobile/sqlcesa30.dll";
repl.Publisher = @"theserver";
repl.PublisherDatabase = @"AdventureWorks";
repl.Publication = @"AdvWorksMobile";
repl.SubscriberConnectionString = "Data Source=AdvWorksMobile.sdf";
// ... other replication parameters ...
repl.AddSubscription(AddOption.CreateDatabase);
repl.Synchronize();
The initialization process requires two steps, adding the subscription to the local SQL Mobile database then creating the table in the database by synchronizing with the server. The first part, AddSubscription, does not require access to the server and will therefore succeed (thereby creating the database) as long as the SuscriberConnectionString is correct.
The call to Synchronize is different. It has to be able to successfully reach the server and exchange data. If there is an error in making the connection to the server the table does not get created and an exception is thrown. The call to Synchronize can fail for any number of reasons, connectivity to the server has been lost, an invalid URL or a mistak in one of the other replication parameter values.
In this situation even though the program that performs the Merge Rep receives the exception and has the opportunity to handle it, the database file still exists leaving a false indication that the Merge Rep process has completed. In many situations, applications test for the existence of the database file to determine if the initial Merge Rep call is required. These programs then crash when they attempt to access the contained table.
So bottom line - Defensive programming.
- Any code that performs the AddSubscription and Synchronize calls should delete the database file if the Synchronize fails
- Any code that access a SQL Mobile database file created via Merge Rep must check for the existence of the synchronized table as well as the database file.
Obviously, this isn't rocket science but hopefully it'll save you a few headaches along the way. :-)
Posted
Aug 07 2006, 03:04 PM
by
jim-wilson