when you specify NFR, the associated objects will behave normally for all clients apart from the actual replication Distribution Agent itself. The DA first calls sp_MSinit_subscription_agent sproc to establish itself as that "special one" (actually writes its SPID into MSsubscription_agents system table). The database engine recognises that SPID and skips the normal IDENTITY processing if NFR attribute has been set.

There may be multiple DA's (from various different pubs) pushing into the same table [one hopes non-overlapping IDENTITY ranges!]. So you might like to verify this against sp_who2 etc

select * from MSreplication_subscriptions

select * from MSsubscription_agents

Inevitably the pub db has extra tables such as syspublications,syssubscriptions as a result of

exec sp_replicationdboption @optname=N'publish', @value=N'true'

and these tables will inevitably be embedded in the .BAK db-dump file

the target SQL200x instance may not have replication turned on so may lack lotsa sprocs that understand such tables (and clauses like KEEP_REPLICATION), so you may get odd errors on restore and have to online and make multiuser.

It is sometimes appropriate to enable repl on such targets even if you have no intention that they be Pub/Dist) but just so the sprocs get populated, and you get an easier restore ride.

experiments show that you can flush these unwanted system tables by flipping value

exec sp_replicationdboption @optname=N'publish', @value=N'true'

exec sp_replicationdboption @optname=N'publish', @value=N'false'

so I request that you try

1. BACKUP DATABASE -- at pub (c/w "NFR" and system tables)

2. RESTORE DATABASE -- at sub

3. exec sp_replicationdboption @optname=N'publish', @value=N'true'

4. exec sp_replicationdboption @optname=N'publish', @value=N'false'

5. now add the sub to the existing pub

6. check behaviour of INSERTs at pub and ditto at sub

and post results back to this forum

HTH