>Fred,
>
>
>>As you are now finding out, replication in SQL server leaves a bit to be desired when it comes to reliability. ...
>
>Well, that's not very comforting. I guess then my question should be, do you have any suggestions on resources with the ways to setup -- or 3rd-party tools for -- replication monitoring? SQL Server's built-in defaults leave a bit to be desired. I see Red Gate has a data compare tool for monitoring replication. I'm sure there are a bunch of scripts I should be running on a regular basis to check things, but since I couldn't even get the Validation script to run ... I'd much rather pay for a 3rd party tool than spend days learning every nuance of replication.
>
>The killer for me is that until a user noticed a problem, there were no errors. It's kind of nice to know there's a problem BEFORE the client learns of the problem from their secretary.
>
>An added annoyance, the snapshop I setup to reinitialize last night stopped after 9 hours because the T-1 went down briefly. (no UPS on the router, apparently) It was almost done. When I restared the merge agent, it started sending the snapshot from the beginning!!!

Dan,

We're still investigating our options on what to do for this. It's not the hot item it was a couple of months ago for us, but we still need to deal with how to handle it reliably. Right now, we just do our backups at each location, and we access the data over the WAN as needed. Our problem is what to do if the link between our sites goes down. Right now, we'd have at least one facility that couldn't continue to work without the available link, and that's the whole reason we want replication, so no facilty would be dead in the water.

Yep, re-starting the snap-shots was another strike against SQL replication for us, too.