Showing posts with label subscribers. Show all posts
Showing posts with label subscribers. Show all posts

Monday, March 19, 2012

Identity range management with web synchronization

I am using SQL Server 2005 replication with anonymous subscriptions and web
synchronization. The server is SQL 2005 Standard and the subscribers are SQL
2005 Express. Every subscriber syncs with the publisher once an hour. There
are no re-publishers.
The subscription databases each run a client program that works on the local
subset of data (partitioning is done by SUSER_SNAME).
My problem is that periodically the client program will fail with an
Identity Range Check Constraint. The error can be fixed by replicating with
the server.
The way I understand SQL2005 replication with SQL2005 subscribers, each
subscriber should be getting a primary and a secondary range of identity
values. When the primary range runs out they should switch to the secondary
range and refresh the primary range (and vice-versa when the secondary range
runs out).
Alternatively, non-SQL2005 subscribers should request a new identity range
when their identity range threshold is exceeded. I have a subscriber identity
range of 10000 and a threshold of 80%. None of the subscribers have inserted
2000 rows between replications (they typically insert no more than 100 rows).
Please help.
<bump>
Let me try again...
I am using web synchronization for merge replication between SQL 2005 Std
and SQL 2005 Express. Occasionally the subscriber databases use their entire
identity range without requesting a new identity range from the publisher.
They request a new range only after the old range has been completely used.
Does anyone have any ideas how to fix this?
Thanks.
"John Van Vliet" wrote:

> I am using SQL Server 2005 replication with anonymous subscriptions and web
> synchronization. The server is SQL 2005 Standard and the subscribers are SQL
> 2005 Express. Every subscriber syncs with the publisher once an hour. There
> are no re-publishers.
> The subscription databases each run a client program that works on the local
> subset of data (partitioning is done by SUSER_SNAME).
> My problem is that periodically the client program will fail with an
> Identity Range Check Constraint. The error can be fixed by replicating with
> the server.
> The way I understand SQL2005 replication with SQL2005 subscribers, each
> subscriber should be getting a primary and a secondary range of identity
> values. When the primary range runs out they should switch to the secondary
> range and refresh the primary range (and vice-versa when the secondary range
> runs out).
> Alternatively, non-SQL2005 subscribers should request a new identity range
> when their identity range threshold is exceeded. I have a subscriber identity
> range of 10000 and a threshold of 80%. None of the subscribers have inserted
> 2000 rows between replications (they typically insert no more than 100 rows).
> Please help.

Monday, March 12, 2012

Identity Primary Field in Merge Replication

Hello I currently have a merge replication set up with 4 subscribers. A primary field for one of my tables is set to a integer indetity.

What Ive noticed is that depending on which database I enter data into, the indentity field (primary key) is set within a certain range I.e

On Server 1 - Values start from 1 then 2,3,4 etc etc

Server 2 - 24001, 24002, 24003 etc etc

Server 3 - 46001, 46002, 46003 etc etc

Server 4 - 68001, 68002, 68003

My question is what happens when these ranges eventually conflict? Do they automatically gain a different range such as 142 001, 142 002 etc etc?

Ive tried looking in SQL Help, and a quick search here, Im just after some confirmation before I implement this to my app.

cheers

I wouldn;t advice you use only this for your primary key.

Check out this post:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1423523&SiteID=1

Identity Primary Field in Merge Replication

Hello I currently have a merge replication set up with 4 subscribers. A primary field for one of my tables is set to a integer indetity.

What Ive noticed is that depending on which database I enter data into, the indentity field (primary key) is set within a certain range I.e

On Server 1 - Values start from 1 then 2,3,4 etc etc

Server 2 - 24001, 24002, 24003 etc etc

Server 3 - 46001, 46002, 46003 etc etc

Server 4 - 68001, 68002, 68003

My question is what happens when these ranges eventually conflict? Do they automatically gain a different range such as 142 001, 142 002 etc etc?

Ive tried looking in SQL Help, and a quick search here, Im just after some confirmation before I implement this to my app.

cheers

I wouldn;t advice you use only this for your primary key.

Check out this post:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1423523&SiteID=1

Friday, March 9, 2012

Identity Fields

Do ALL identity fields need to be changed to (Not for Replication) before I
create Publisher and Subscribers even if some tables will never be changed
outside of the Publisher? Thanks.
David
David,
this depends on what type of replication you are setting up (and actually
which version of SQL Server as Hilary pointed out to me). Please can you
post back with a little more info.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Sorry. We are planning to use Merge Replication with initially only
replicating to laptops with MSDE and not to a 2nd SQL Server. We are
using SQL Server 2000 with SP4.
Thanks.
David
*** Sent via Developersdex http://www.codecomments.com ***
|||David,
yes - in merge replication, this setting is needed.
Rgds,
Paul Ibison
|||They only need to be set for not for replication if
1) you have more than two nodes in your replication topology (i.e. more than
one subscriber)
2) Inserts occur on both sides between merges
This does capture the majority of merge implementations, but not all of
them.
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
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23tTlvK77FHA.1484@.tk2msftngp13.phx.gbl...
> David,
> yes - in merge replication, this setting is needed.
> Rgds,
> Paul Ibison
>

Identity columns problem in replication among n no of subscribers

I have created Transaction Replication.
Nearly 100's of tables there in my database.
I have created Recordid (identity) column with primary key in each table and
all are incremented by 1.
Front End application in VB6 is 100% dependable on this column. Changes in
this column may spoil my work of VB6.
Synchronisation is done @. subscribers side using below activex component in
VB6
Set objSQLDist = CreateObject("SQLDistribution.SQLDistribution.2")
Subscribers side does not show identity columns with primary key. It shows
only name of the column as INT.
Front application is failed to run @. subscribers side.
Pls suggest how to Replicate identity column among n no. of subscribers.
Best Regards
Sanjay
You will have to create different identity seeds and an increments of 2 on
both sides - on the subscriber a seed of 2 with an increment of 2, and on
the publisher an seed of 1 with an increment of 1.
Make sure the identity column has the not for replication property on it.
Then set your articles up to not modify the existing tables on the
subscriber and in your pre-snapshot script have your table creation scripts
(along with their respective indexes).
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"SANJAY PAWAR" <sanju@.nisiki.net> wrote in message
news:OUx4ONMBHHA.4472@.TK2MSFTNGP03.phx.gbl...
>I have created Transaction Replication.
> Nearly 100's of tables there in my database.
> I have created Recordid (identity) column with primary key in each table
> and all are incremented by 1.
> Front End application in VB6 is 100% dependable on this column. Changes in
> this column may spoil my work of VB6.
> Synchronisation is done @. subscribers side using below activex component
> in VB6
> Set objSQLDist = CreateObject("SQLDistribution.SQLDistribution.2")
> Subscribers side does not show identity columns with primary key. It shows
> only name of the column as INT.
> Front application is failed to run @. subscribers side.
> Pls suggest how to Replicate identity column among n no. of subscribers.
> Best Regards
> Sanjay
>
>
>
>
>
|||Dear Friend Hilary
Thanks for the help.
But one more solution can be there if I give different IDENTITY ranges to
each subscribers.
Pls help me If you know how to give diff IDENTITY ranges to each
subscriber.
Thanks in Advance
Best Regards
Sanjay
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:ut$xlYMBHHA.4292@.TK2MSFTNGP02.phx.gbl...
> You will have to create different identity seeds and an increments of 2 on
> both sides - on the subscriber a seed of 2 with an increment of 2, and on
> the publisher an seed of 1 with an increment of 1.
> Make sure the identity column has the not for replication property on it.
> Then set your articles up to not modify the existing tables on the
> subscriber and in your pre-snapshot script have your table creation
> scripts (along with their respective indexes).
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "SANJAY PAWAR" <sanju@.nisiki.net> wrote in message
> news:OUx4ONMBHHA.4472@.TK2MSFTNGP03.phx.gbl...
>
|||You certainly can, so you can go to your subscriber and do a
dbcc('mytablename', checkident, reseed, 10000000) and it will probably work.
However you will always have to monitor the range you assigned and adjust it
as necessary.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"SANJAY PAWAR" <sanju@.nisiki.net> wrote in message
news:%23e4pfjMBHHA.1220@.TK2MSFTNGP04.phx.gbl...
> Dear Friend Hilary
> Thanks for the help.
> But one more solution can be there if I give different IDENTITY ranges to
> each subscribers.
> Pls help me If you know how to give diff IDENTITY ranges to each
> subscriber.
> Thanks in Advance
> Best Regards
> Sanjay
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:ut$xlYMBHHA.4292@.TK2MSFTNGP02.phx.gbl...
>
|||Why do you need the identity property on the subscribers if you have
transactional replication, where the subscribers are treated as RO?
Perhaps this is being used as a failover server? If this is the case, the
easiest way to set it up is to enable automatic identity range management,
large range sizes and queued updating subscribers.
This way the subscriber can start entering data once the publisher is down
without any meddling with identity ranges on the subscriber.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Dear friend Hilary
Thanks for your full co-operation. My all doubts are clear now except below
2.
1. If I am having file called EMP with identity column Recid.
I want to give automatic range control on publisher for n no. subscribers
what will be the command ?
2. If I give range 1001 to 2000 to subscriber1, will he (subscriber1) be
able to store or pull others data range from 1 to 1000 or 2001 to 3000.
Best Regards
Sanjay
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:u5x4t7MBHHA.4428@.TK2MSFTNGP04.phx.gbl...
> You certainly can, so you can go to your subscriber and do a
> dbcc('mytablename', checkident, reseed, 10000000) and it will probably
> work. However you will always have to monitor the range you assigned and
> adjust it as necessary.
> --
> Hilary Cotter
> Director of Text Mining and Database Strategy
> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
> This posting is my own and doesn't necessarily represent RelevantNoise's
> positions, strategies or opinions.
> 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
>
> "SANJAY PAWAR" <sanju@.nisiki.net> wrote in message
> news:%23e4pfjMBHHA.1220@.TK2MSFTNGP04.phx.gbl...
>
|||For automatic identity range management on the publisher for queued and
merge replication you have to drop your publication and subscriptions and
enable this feature - in the articles tab of the create publication wizard.
A subscriber with a range of 1000-2000 will be able to receive replicated
commands for other ranges if the not for replication constraint is enabled.
Otherwise he will not.
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
"SANJAY PAWAR" <sanju@.nisiki.net> wrote in message
news:%239Zlc%23yBHHA.3380@.TK2MSFTNGP04.phx.gbl...
> Dear friend Hilary
> Thanks for your full co-operation. My all doubts are clear now except
> below 2.
> 1. If I am having file called EMP with identity column Recid.
> I want to give automatic range control on publisher for n no. subscribers
> what will be the command ?
> 2. If I give range 1001 to 2000 to subscriber1, will he (subscriber1) be
> able to store or pull others data range from 1 to 1000 or 2001 to 3000.
> Best Regards
> Sanjay
>
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:u5x4t7MBHHA.4428@.TK2MSFTNGP04.phx.gbl...
>