Monitoring SQL Server 2008 Replication (Continued)

[Disclaimer:  I AM NOT a SQL Server expert, so there may be incorrect statements written below, particularly regarding the status of a an active SQL Server Agent-based replication.]

This article is a follow-up to a previous article:  Monitoring SQL Server 2008 Replication.

Until today, my SQL Server replication knowledge revolved around a scripted SQL Server Replication Publication and an associated SQL Server Job to run the publication at defined intervals.  Now, I see some usefulness for Replication Management Objects (RMO).

What did I do?
On the Server:
I installed the AdventureWorks database (as mentioned previously) and ran the "InstallSalesOrdersSample.bat" file, which installed the SalesOrders Sample.  I allowed that sample to create an IIS Virtual Directory, as I wanted the replication to be web-based.

On the Client:
I used Visual Studio 2010 to compile the SalesOrders solution.  I also added some logic to the Synchronize.CreateSubscription() method.  I needed replication to use Web Synchronization and the sample's code didn't include that.  So, right after the mergePullSub.DatabaseName property is set, I added the following:

if (!String.IsNullOrEmpty(webSynchronizationUrl))
{
 mergePullSub.UseWebSynchronization = true;
 mergePullSub.InternetUrl = webSynchronizationUrl;
 mergePullSub.InternetSecurityMode = AuthenticationMethod.BasicAuthentication;
 mergePullSub.InternetLogin = webSynchronizationUser;
 mergePullSub.InternetPassword = webSynchronizationPassword;
}

I made the appropriate changes to the app.config and the associated Properties.Settings.Designer.cs file.

After resolving some permission problems, the replication worked like a charm.  The neat thing is that C# code, using RMO, kicked off each merge replication task.  Plus, using RMO's Microsoft.SqlServer.Replication.AgentCore.StausEventHandler, I now have access to the completion percentage of the current replication activity.

As far as I can tell, you don't have access to this information if  you are using a SQL Server Agent job to execute the replication subscription.  But, for my current project, that could be an issue.  We kinda want our cake and eat it too.  We want to have a continuously updated database (whether our application is actually running or not) and we want to know the status of any replication activity when it is happening.  A decision must be made.  :-)

A quick note about the permission problems:
1)  For Web-based replication using Basic Authentication (via SSL, of course), the user credentials being passed from the client MUST also have access to the publication's snapshot folder.
2)  There were a few other changes, but I don't know if they had any impact.  I will post later if 1) I am setting up a new web-based publication and 2) I determine that there are additional permission issues to be implemented.

Chris