SqlCE Replication error handling Pattern

[Steve B.]

Hello,

I'm building an application for mobile users based on SQL Ce merge
replication (CF 1.0, SQL Ce 2)

What is the bast way to handle errors ?
If the communication is interrupted (since it it gprs and users will often
sync from their car), how SQL Ce react ? Is it possible to continue where it
stopped ? Is it possible to add data to the DB between the time where the
comm stopped and the time when the comm restart ?

Thanks,
Steve

 

[Darren Shaffer]

there is row level tracking of data during merge replication with SQL CE.
if your
connection drops in the middle of a replication event, you simply need to
retry the
replication and it should pick up where it left off (assuming you havea
connection,
which you should always test for before initiating replication). I have
seen some
issues with clean restartability over GPRS and occasionally you'll get an
error about
locking or a conflict on the server that is caused by this sudden drop in
connectivity.
Best thing to do there is try to avoid the failure - use smaller
publications and filter
the data your are replicating over GPRS to make it as small and quick as
possible.

Things improve on this front greatly with SQLMobile and SQL Server 2005.
Column level tracking is the biggest impact, with multiple subscriptions per
database also allowing you to have more, smaller publications and safer
replication over spotty network connections.
--
Darren Shaffer
..NET Compact Framework MVP
Principal Architect
Connected Innovation
www.connectedinnovation.com

 

[Steve B.]

Thanks for this explanation, but I wonder what I'll have to do when the
issue you described appends...

I have seen some
issues with clean restartability over GPRS and occasionally you'll get an
error about
locking or a conflict on the server that is caused by this sudden drop in
connectivity.

SQL Mobile can't be use for the first version of the application since the
target is Pocket PC 2003 SE, CF 1 and SQL 2000 (we can't rely on beta
version).

Thanks,
Steve