Sql-server – Multiple Publications for Merge Replication

Not really anything obvious.

The easiest would be if you have a backup you could restore to view it.

Otherwise you'll properly try - either yourself, daunting, or via commercial tools to find a tool that lets you explore the transaction log for the given changes. For example something like: http://www.apexsql.com/sql_tools_log.aspx

I've not tried out such tools myself so I cannot vouch for them. I usually get by either by having backups to search, or in some cases, I've set up change tables to log changes to critical data.

For a meer 52 client sites replication will do just fine. Consider your local copy as the 'master' site and have the application work only on the local copy, always. Use replication to aggregate the data to the central repository for aggregated reporting. Index maintenance operations normally do not generate replicaiton traffic. Manage schema changes through application deployment migrations, ie. have upgrade scripts for each released version.

As the number of sites increases, managing replication becomes harder and harder. Also licensing would push toward deploying Express on periphery. And SQL Server upgrade is an absolute pain when replication is involved, as the order of upgrading the components (publisher, distributor, subscriber) is critical is but difficult to coordinate with many sites. Deployments that I know of with +1500 sites use customized data movement based on Service Broker. See Using Service Broker instead of Replication for an example. I've even seen designes that use Service Broker to push out to periphery new bits (application changes) which in turn deploy, when activated, migrations and schema changes, making the entire deployment operated from the center.