bi directional transactional replication and subscriber name

Hi,
I am trying to setup bi-directional transactional replication between 2 SQL Servers,
I add the subscription on both the servers using the code below.

EXEC sp_addsubscription @.publication = N'test',
@.article = N'all', @.subscriber = 'AnyServer',
@.destination_db = N'test', @.sync_type = N'none',
@.status = N'active', @.update_mode = N'read only',
@.loopback_detection = 'true'
GO

I have defined 'AnyServer' on both the servers using cliconfg
(Server1's AnyServer pointed towards Server2 and Server2's AnyServer pointed towards Server1, I need to do that because there is a restriction to run the same code on both the servers),

After inserting a record on server1 in the 'test' database, the changes successfully transfers to the server2, then server2 sends it back to server1 and server1 generates the error of

"Violation of PRIMARY KEY constraint 'PK_Table1'. Cannot insert duplicate key in object 'Table1'."

It seems as if loop detection is failing if I keep the same subscriber name on both sides.

It runs fine when I change the subscriber name in the subscription (@.subscriber = 'Server2' for server1 and @.subscriber = 'Server1' for server2).

Can anybody explains this behavior to me?not really , but common sense says that if you try & create a duplicate primary key on the first server, it MUST fail to preserve PK integrity...|||Let me rephrase my question.....

Why bi-directional replication is failing with the same subscriber name (managed by cliconfg) on both sides.... when it is running fine with the real server names?

Bi Directional Transactional Replication

Okay I posted this yesterday I believe:
“Let's say TableA on a 2000 ServerA.DatabaseA has an identity key and I want
to transactionally replicate that TableA to a ServerB.DatabaseA (that is also
2000). But here's the catch: in the case of a significant outage on ServerA
I want to be able to repoint the web to ServerB.DatabaseA and have everything
function successfully.
A previous responder suggested (I think) that I could simultaneously set up
transactional replication from ServerA.DatabaseA to ServerB.DatabaseA and
from ServerB.DatabaseA to ServerA.DatabaseA and have one database have the
identity on serverA with a seed of B using odds and the identity on serverB
using a seed of evens for example.
Here are my questions:
1) Will Sql Server 2000 let you set up this kind of quasi-two-way
transactional replication?
2) If the answer to #1 is 'yes', then how can you have identities set up on
both tables? Won't replication throw up if you're copying from an identity
column on ServerA to its sister table on ServerB that also has an identity
column?
3) Would this setup be much easier to implement than standard merge
replication?
Any tips on how I might do this would be much appreciated.”
And Hilary very kindly posted this:
“1) Yes, but you have to create the objects in advance on both sides and use
the not for replication switch on the identity colummns. You must also set
the identity increments and seeds. Then you must run dbcc
checkident(tablename, reseed, correctvalue) to fix everything.
2) replication doesn't throw up per se. Basically when you create your
publication and get to the specify articles dialog box, click on the browse
button to the right of the table, and in the snapshot section, select keep
existing table unchanged. Run the checkident to ensure that you are getting
odds on the correct sides, and evens on the other.
3) Standard merge is simpler to set up. It have typically 1 to 2 minutes of
latency whereas with bi-directional transactional on a system under load you
are looking at about 10-20s. Merge replication is harder to troubleshoot and
recover from.”
So I tried to do what Hilary said:
I set up Not for Replication, Seed=1 and Increment=2 on the identity field
on ServerA.TableA after setting up transactional replication from
ServerA.TableA to ServerB.TableA. I then manually ran the snapshot and it
sent over the table to ServerB.TableA. It created a non-identity column on
ServerB.TableA, however, so I had to go in and manually change ServerB.TableA
to Not for Replication, Seed=2 and Increment=2.
Now here’s the problem:
When I insert a record into ServerA.TableA, it does not migrate over to
ServerB.TableA.
What am I doing wrong?
This type of setup is possible. Replication performs identity inserts as you
set up the columns with 'Identity (not for replication)'.
Is it easier than merge? Probably I'd say a little more difficult although
neither are really difficult. The issue is that you have to do the setup
manually whereas merge can be done with the wizard. It'll perform much
better than merge, but merge will cope with schema changes better. Anyway,
here's a couple of articles to help you out:
http://support.microsoft.com/default...b;en-us;820675
http://msdn.microsoft.com/library/de...lsamp_3ve6.asp
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)