Merge Replication Doesn't Update IDENT_CURRENT() ?

I have found that a table that is being merge-replicated to each branch
office has a different INDENT_CURRENT value in each branch. Is this
correct?
Basically, I have a table called "Batch" in two database servers (one
for each branch office). Let's call the database servers dbsOne, and
dbsTwo. "Batch" table has an identity field that is not the primary
key and is not the replication ID either. Somehow we find that
IDENT_CURRENT() in dbsOne is different from that's in dbsTwo, like
this:
IDENT_CURRENT("Batch") in dbsOne: 1073
IDENT_CURRENT("Batch") in dbsTwo: 943
When I check the identity values of "Batch" entries that the users have
added in dbsOne, the identity values is closely following
IDENT_CURRENT("Batch") in dbsOne.
Likewise, when I check the identity values of "Batch" entries that the
users have added in dbsTwo, the identity values is closely following
IDENT_CURRENT("Batch") in dbsTwo.
Seem like the merge replication doesn't update IDENT_CURRENT()
accordingly.
Is my understanding correct?
Thanks.
Jay Chan
yes, this is perfectly normal. Basically it means that on one subscriber the
merge agent has run more frequently than on the other.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<jaykchan@.hotmail.com> wrote in message
news:1120749290.480181.201600@.g49g2000cwa.googlegr oups.com...
> I have found that a table that is being merge-replicated to each branch
> office has a different INDENT_CURRENT value in each branch. Is this
> correct?
> Basically, I have a table called "Batch" in two database servers (one
> for each branch office). Let's call the database servers dbsOne, and
> dbsTwo. "Batch" table has an identity field that is not the primary
> key and is not the replication ID either. Somehow we find that
> IDENT_CURRENT() in dbsOne is different from that's in dbsTwo, like
> this:
> IDENT_CURRENT("Batch") in dbsOne: 1073
> IDENT_CURRENT("Batch") in dbsTwo: 943
> When I check the identity values of "Batch" entries that the users have
> added in dbsOne, the identity values is closely following
> IDENT_CURRENT("Batch") in dbsOne.
> Likewise, when I check the identity values of "Batch" entries that the
> users have added in dbsTwo, the identity values is closely following
> IDENT_CURRENT("Batch") in dbsTwo.
> Seem like the merge replication doesn't update IDENT_CURRENT()
> accordingly.
> Is my understanding correct?
> Thanks.
> Jay Chan
>
|||Thanks for telling me that this is normal. I will have to keep this in
mind and not using the identity field for synchronizing data between
branch offices and only use it to ID an entry generated within the
branch office. OK.
I don't quite understand what do you mean by "one subscriber the merge
agent has run more frequently than on the other". My database servers
situation is actually like this:
o I have three database servers:
1. dbsOne (the publisher)
2. dbsTwo (The subscriber # 1)
3. dbsThree (The subscriber # 2)
o The INDENT_CURRENT("Batch") value in each database server are:
1. dbsOne: 10734
2. dbsTwo: 9841
3. dbsThree: 9289
o The estimated volume of data added to "Batch" table from
each branch office into their database server are:
1. dbsOne: High
2. dbsTwo: Medium
3. dbsThree: Low
I assume what you mean is that the value in IDENT_CURRENT in each
database server is corresponding to the number of entries that we add
to the table in the database server. This seems to match the numbers
that I get from our database servers. Thanks.
Jay Chan
Hilary Cotter wrote:[vbcol=seagreen]
> yes, this is perfectly normal. Basically it means that on one subscriber the
> merge agent has run more frequently than on the other.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> <jaykchan@.hotmail.com> wrote in message
> news:1120749290.480181.201600@.g49g2000cwa.googlegr oups.com...