>>Yes, it turns out the solution provider isn't willing to support replication over low bandwidth, so it's going to have to be some sort of remote access setup.
>
>Replication would probably require a very respectable bandwidth support. I can understand their POV. It appears a remote access would probably be better, which is what have usually seen at several occasions from discussions on this site, in situations like yours.

Actually, bandwidth is something that may need to be revisited from time to time. A solution provider may say they don't support multi-site replication, but that policy may have been set years ago when bandwidth was very low. With more bandwidth available, that could change.

>>Embedding documents in the database doesn't happen every day. They might go for a while not doing any, and then have to put in one or two dozen.
>
>As this is not applicable on a regular basis, in order to determine the payload, you would probably extend the calculation period over a very long period, which you certainly have. I would usually double up on everything, as far as potential scenarios, just to assure your expections would apply. When we have non regular processes like these, such as random payloads, it makes things a little bit more difficult to predict.
>
>>Do you have any idea of the efficiency of replication in this sort of scenario? If a 1MB document is embedded, how large of a transaction log entry does that create - I wonder if there's significant bloat.
>
>The transaction log tends to grow very fast based on various operations the database has the support, such as removing a bunch of records from a specific operation as well as when adding a new field. It might not be a factor if you have daily maintenance which shrinks some of that. However, if it keeps getting bigger, based on the limit applied into SQL Server, you might have a very big log, especially by embeding such documents into a table.

Regardless of the type of replication used, the data transferred between replicated databases has to be at least as large as the document(s) embedded. Although, it might be smart for SQL Server and/or the transport mechanism to compress during transport (as Walter appears to be doing manually). I was just wondering if anyone had any idea of bloat e.g. if embedding a 1MB document generates 2MB of traffic to the other sites.

>I never embed such documents into a table. While this is good for security concerns, it defies any potential of external manipulation, which might have served here in such replication. File synchronization would usually be easier to support than database. So, at least, you would have add that part more easily resolved.

In this case documents must be embedded, for legal compliance.