Okay,
So I am learning how to do this stuff, so bear with me, but here is the scenario:
We have a rather large application that accesses a central database. However, we have remote terminals (laptops) that are not always capable of accessing the primary network, so we setup Merge Replication with a Push Agent on the Distributor Server to local SqlExpress servers on the individual laptops.
When an Express laptop is on the network with the SqlServer, the data is synchronized and has no problems.
Our application is also designed to dynamically update the database schema with new revisions/versions of the software.
We have code that does the following:
1) Creates Merge Publication (enabled replication on the server, database, and creating the initial snap shot)
2) Applies Schema Updates to the Database.
3) Updates the Publication, adding new Merge Articles.
(sp_addmergearticle with @force_invalidate_snapshot set to 1)
4) Restarts Snapshot Agent. (sp_startpublication_snapshot)
5) Reinitializes the Subscriptions
(sp_reinitmergesubscription with @upload_first set to 1, @subscriber and @subscriber_db were not provided as the default was listed as "all")
My Test for this process:
1) Setup on of our application databases and updated it to an older version of our software.
2) Created Merge Publication. (DSVR\MSSQLServer)
3) Created Subscription on SqlExpress server (same physical computer) (DSVR\SQLExpress)
4) Logged into SQLExpress database from our software. Made a Change via our software. Agent synchronized this change with MSSQLServer published database.
5) Stopped Synchronization Agent.
6) Made another change to the SQLExpress database, and verified this Change was present on the SQLExpress side, but the MSSQLServer did not have the change.
7) Shut down our application, and stopped the SQLExpress windows service.
8) Restarted Synchronization Agent on MSSQLServer. As expected, it repeatedly error-ed out with inability to connect to SQLExpress.
9) Ran our current version of the software on the MSSqlServer version of our database, which proceeded to add several tables, columns, and other such schema changes.
10) Ran through the first number list above: Updated the Merge Articles adding the new ones, re-running the snapshot agent, and calling to the reinit subscription stored procedure with upload_first set to 1. (I i did not provide any subscriber info as the documentation
says the default is "All").
11) Started the SQLExpress windows Service.
What happened:
The snapshot agent was at +/- 55% when i restarted the SQLExpress service, so when the Synchronization Agent had been erroring out, unable to connect to SQLExpress server, within a few seconds or so, the Synchronization Agent indicated it could not syncrhonize as the snapshot was out of date.
The snapshot agent finished, and on the next iteration of the Synchronization Agent's 60 second cycle, it start to update the Express database.
Problem:
I specifically included the sp_reinitmergesubscription @upload_first parameter set to 1 (true), and yet, after the subscription finished initializing from the snapshot, both the MSSqlServer database and the SqlExpress database had the OLD MSSqlServer data, and the changes I made to the SQLExpress when the Synchronization Agent had been turned off was lost.
This seems to defy the documentation and description of the meaning of "@upload_first".
With the Synchronization agent on a "Push" (we cannot do a pull), we have to be able to disconnect the SqlExpress laptop, and should any SCHEMA change occur on the MSSqlServer instance (with appropriate updates to the Publication) that those changes are pushed down to the Subscriber (SqlExpress) without ANY LOSS OF DATA on the Subscriber side. That is what I expected the @upload_first was supposed to effect. This did not happen in my test environment.
I simulated this process by stopping the Sync agent, stopping the Express Win service, restarting the Sync agent, and restarting the Express Win service after the Distributor Server's Publication had been updated.
Perhaps the changing of these might have affected the issue, but I am hoping it is something else.
Any Ideas?
Thanks
Jaeden "Sifo Dyas" al'Raec Ruiner
"Never Trust a computer. Your brain is smarter than any micro-chip."
PS - Don't mark answers on other people's questions. There are such things as Vacations and Holidays which may reduce timely activity, and until the person asking the question can test your answer, it is not correct just because you think it is. Marking it
correct for them often stops other people from even reading the question and possibly providing the real "correct" answer.