Max Replication Text Size

When SQL Server is installed, the Max Replication Size value is set by default to 65536. If a record is inserted into a published table that exceeds that value, an error will occur at the application.

The following error will be returned to the calling application:

__________________________________________________________________________________

    Server: Msg 7139, Level 16, State 1, Line 1

Length of text, ntext, or image data (200) to be replicated exceeds configured maximum 10.

The statement has been terminated

__________________________________________________________________________________

In order to prevent this from occurring, Max Text Replication Size needs to be overridden to the maximum allowed, which is 2147483647

Solution :- 

exec sp_configure 'max text repl size', 2147483647

reconfigure with override

Bidirectional, Transactional Replication VS Peer-to-Peer Transactional Replicatio

With Bi-Directional replication if you want to make a schema change you must drop your publications, and then drop your subscriptions, make the schema change and then recreate the publications and subscriptions on both sides. Then you start up the agents and you are in business again. The best way to deploy subscriptions in bi-di transactional topologies is by restoring the subscriber via a backup.

Now if your users are banging away on your first publisher while you do this it will be hard to achive consistency between both nodes in your bi-directional replication toplogy, as these updates may or may not be in the backup. You can run validations after the fact but it hard to cobble together a consistent topology while you are live. It can be done, but its hard. Plus table locks are held when the publication is created. So you can run into a lot of locking.

With peer-to-peer in SQL 2005 you again have to quiesce the system, make your change, ensure it is everywhere and then let your users back on. Its the same problem.

WIth merge replication and bi-di transactional the model is a hub and spoke methodology. You have a central publisher and multiple subscribers all talking to this central publisher which is the clearing house for changes. Peer to peer is a mesh topology which means a<->b, b<->c, c<->a. b can drop off and a can replicate with c until b comes back on.

You can't do this using bi-directional transactional replication and merge.

More on
http://technet.microsoft.com/en-us/library/ms151196.aspx

======================================================

How to Configure Peer-to-Peer Transactional Replication (SQL Server Management Studio)

http://technet.microsoft.com/en-us/library/ms152536.aspx