I have a strange problem I can't seem to figure out. Hopefully someone can
point me in the right direction.

I have a database I'm replicating with a number of tables that have identity
columns as part of their primary key. I'm using merge replication and use
automatic range management for the identity columns. The publication has one
pull subscription. I replicate once every 15 minutes.

Infrequently (maybe once a month), I get pk violations on one of the
identity column tables and find after a little investigation that the table
seems to have reseeded itself back to the beginning of it's current identity
range. For example, I have a table with an identity range of 4000. The
check constraint is "id > 240000 and id < 244000". I do a select for the max
id between those ranges and see that the max value is currently 240178,
however when I run DBCC CHECKIDENT, I find that the current identity value is
240011.

I wind up having to manually reseed the value back to what it should be
using DBCC CHECKIDENT(tableName, RESEED, correctSeed).

The only way I can see that this has happened is if
something 'manual' has happened. EG if identity_insert
was set to on before making the insert, then DBCC
CHECKIDENT was used to reseed. If there is no possibility
that the range has been manually altered in tihs way, I'd
see this as a bug. This could be raised as such, but
what's really needed is the ability to reproduce it. If
you see any pattern at all, please post back.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)