Future Maintenance of SQL 2005 Merge Replication

I have remote offices that are entering data into their local database, then
using merge replication to "upload" their changes to a publisher on my web
server, and then possibly download any changes made on my web server. My
Web server is running SQL 2005 Standard, and the local offices are running
SQL 2005 Express. I've got it working via https/replisapi.dll, and once
it's started, it works very nicely.
Typically when a new office once to get started, they'll backup their
(never-before-replicated) database to a .bak file, send me that file, and
I'll restore their (new) database onto my server, and create a publication.
Then I'll send them instructions on how to start a subscription. This
causes the data they just send me to come back down, as a snapshot is
applied to init the subscription. I realize that I could start a no-sync
initialization, but if any changes were made from when they made the backup
to when they start/init the subscripion, I believe the two-databases would
be out of sync. Am I right?
I understand that once a subscription is started, that if a backup is
restored (on either the subscription side or publisher side) that as long as
you're within the retention period, merge replication will correctly bring
over the changes that have occurred since the backup. With this in mind...
Would it be possible on the soon-to-be subscriber database to get the
replication triggers installed and working (tracking all changes) before the
backup is made, so that if any changes occur on the subscriber side (from
the time the backup was made to when it's applied to the publisher database
to when the subscription is started), these changes will be applied to the
publisher when the new subscription is initialized?
--Troy
Unfortunately you cannot enable change tracking before setting up the
subscription. So you would have to track the subscriber side changes
yourself while the subscription is being setup and update those rows that
changed in that interval so that it triggers a replication upload.
“This posting is provided "AS IS" with no warranties, and confers no rights.”
"Troy Wolbrink" wrote:

> I have remote offices that are entering data into their local database, then
> using merge replication to "upload" their changes to a publisher on my web
> server, and then possibly download any changes made on my web server. My
> Web server is running SQL 2005 Standard, and the local offices are running
> SQL 2005 Express. I've got it working via https/replisapi.dll, and once
> it's started, it works very nicely.
> Typically when a new office once to get started, they'll backup their
> (never-before-replicated) database to a .bak file, send me that file, and
> I'll restore their (new) database onto my server, and create a publication.
> Then I'll send them instructions on how to start a subscription. This
> causes the data they just send me to come back down, as a snapshot is
> applied to init the subscription. I realize that I could start a no-sync
> initialization, but if any changes were made from when they made the backup
> to when they start/init the subscripion, I believe the two-databases would
> be out of sync. Am I right?
> I understand that once a subscription is started, that if a backup is
> restored (on either the subscription side or publisher side) that as long as
> you're within the retention period, merge replication will correctly bring
> over the changes that have occurred since the backup. With this in mind...
> Would it be possible on the soon-to-be subscriber database to get the
> replication triggers installed and working (tracking all changes) before the
> backup is made, so that if any changes occur on the subscriber side (from
> the time the backup was made to when it's applied to the publisher database
> to when the subscription is started), these changes will be applied to the
> publisher when the new subscription is initialized?
> --Troy
>
>
|||Thanks for confirming that. I'm considering setting the database to
read-only during the interim to keep the user from making any changes that
will get discarded. Or atleast just give the user a warning that any
changes during the interim will be ignored.
--Troy
"Vijay TS" <VijayTS@.discussions.microsoft.com> wrote in message
news:FF785F35-E3BA-4966-953F-69B58A30F057@.microsoft.com...[vbcol=seagreen]
> Unfortunately you cannot enable change tracking before setting up the
> subscription. So you would have to track the subscriber side changes
> yourself while the subscription is being setup and update those rows that
> changed in that interval so that it triggers a replication upload.
> --
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>
> "Troy Wolbrink" wrote: