IE launches slowly after running Management Studio

Once I launch Management studio, even after closing it, IE takes minutes to launch.

Looking at task manager I can see the "iexplore.exe" process just sitting there.

I've tried using filemon from sysinternals thinkg it got stuck on a file, but not such luck.

I have to reset the entire machine to get it to work.

Any ideas why the tool would corrupt IE in that way?

Thanks,

Eric

Use Firefox
|||I'm curious if you see the same effect if you launch VS 2005 instead of SSMS?sql

Identity reseed error with merge

Are you using automatic range management? If so, the
process of synchronization will reseed if you achieve a
set % of available values. I'd advise against relying on
this behaving correctly in all circumstances and force
the system to never reseed by allocating a huge range to
each subscriber. An integer datatype can span -2billion
to 2billion or so, so there is not really any need to
ever have such a small range that reseeding occurs (IMHO).
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Thanks but these is not the problem. Perhaps I didn't express correctly.
I know the merge replication automatically reseed when it reaches the
imposed limit, but what happened to me is that this seed has returned to
an anterior value, so with the IDs I get concurrence troubles
replicating. The replication and range automatic asignation works
correctly, but I don't know what I did to make the seed backward to a
previous value. The seed didn't reached its limit.
I changed manually the values of the seed in
Distribution.MSrepl_identity_range, but I want to know in what
circurstances those values are being reinitialized to a previous value.
Thanks
Juan
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||are they reseeded on the publisher, subscriber or both?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Juan a" <juan@.mailinator.com> wrote in message
news:uNotHeU$EHA.4004@.tk2msftngp13.phx.gbl...
>
> Thanks but these is not the problem. Perhaps I didn't express correctly.
> I know the merge replication automatically reseed when it reaches the
> imposed limit, but what happened to me is that this seed has returned to
> an anterior value, so with the IDs I get concurrence troubles
> replicating. The replication and range automatic asignation works
> correctly, but I don't know what I did to make the seed backward to a
> previous value. The seed didn't reached its limit.
> I changed manually the values of the seed in
> Distribution.MSrepl_identity_range, but I want to know in what
> circurstances those values are being reinitialized to a previous value.
> Thanks
> Juan
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!
|||They are reinitialized on publisher, but because of automatic range
administration, when the SQLCe synchronize it gets the range asigned
from the publisher, an old range that was used before, and that already
have registers in publisher.
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!

Identity range when rows already exist

I've created a merge publication with automatic range management. Insert
fails because the ranges assigned have already been used. How do I specify
that I want the new identity ranges to start above those which have already
been used?
I created this publication by backing up my production database and
restoring it to my test database. Then I created the publication on my test
database by manually editing the auto-generated script for creating the
publication on the production database. I don't know if this is the reason
things don't work out as I want them to.
I think you would be best to drop this publication and its subscriptions and
recreate from start.
If you are a masochist you can do the following.
Look in your distributor for a table called MSrepl_identity_range. The
highest range is the range which is deployed to one of your subscribers. You
can bump this value up to give yourself a cushion.
For instance if the highest range is 10000, bump it up to 20000, which will
be the next value assigned.
Now go to your problem subscriber and fix the table there. Use dbcc
checkident('tablename') to determine what the current range is, and then
reseed to the value you found on your publisher's distribution database
MSrepl_identity_range table.
Now issue a sp_help 'problemTableName' to get the name of the check
constraint used to restrict the range of possible values acceptable for this
table. script out the check constraint and recreate it with a set of values
which matches the range you assigned with the checkident reseed statement.
If you are really feeling like punishing yourself you might want to read
http://www.simple-talk.com/2005/07/05/replication/
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
"Daniel" <daXniel_kriXstensXen_@.hotmail.com (remove the Xs)> wrote in
message news:92B2698A-DE7C-485C-9381-78295E49A335@.microsoft.com...
> I've created a merge publication with automatic range management. Insert
> fails because the ranges assigned have already been used. How do I specify
> that I want the new identity ranges to start above those which have
already
> been used?
> I created this publication by backing up my production database and
> restoring it to my test database. Then I created the publication on my
test
> database by manually editing the auto-generated script for creating the
> publication on the production database. I don't know if this is the reason
> things don't work out as I want them to.
|||"Hilary Cotter" wrote:

> I think you would be best to drop this publication and its subscriptions and
> recreate from start.
I already did that. Perhaps the problem was that I created the publication
using the script generated by EM. For each merge article it did:
exec sp_addmergearticle ... @.article = [tableName] ...
go
To solve the problem, for all merge articles for which I use automatic range
management I added:
declare @.NewID int
Select @.newID = max(ID)+1 FROM [tableName]
DBCC CHECKIDENT([tableName],RESEED,@.newID)
exec sp_addmergearticle @.article = [tableName] ...
go
That is, I reseed the identity for each table before adding it to the
publication. It seems to work.

>If you are really feeling like punishing yourself you might want to read
> http://www.simple-talk.com/2005/07/05/replication/
Thanks I did that. You got all these great articles scattered all over the
net. But your book about merge replication is due any week now, right? It
would be nice to have the information gathered in one place

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.

Identity Range Management

Hello all,

I am just beginning to get into replication and have a couple questions for the experts.

When I set up replication (transactional with queued updates), the default identity range was set to 10,000 for the publisher and 1,000 for the subscriber.I understand that if I try to insert 1,100 records at the subscriber, I will get an error saying that the identity range has been exhausted and I need to run sp_adjustpublisheridentityrange on the publisher and the Distribution Agent for the subscriber.

My questions are:

Why wouldn’t someone increase the identity range to a very large number, just in case something happens and the publisher/subscriber link is broken for an extended period of time?What are the ramifications to a larger identity range?

Since identity range management is done by the distributor, what happens if the distributor goes down?Do the publisher and subscribers receive errors when they fill their current ranges?

Thanks,

Jarret

1. If you set it too large, it's possible to exhaust all possible values. i.e. if you have smallint column with publisher having range of 10,000 and two subscribers with range of say 11,000, and one subscriber hits the threshold, that subscriber cannot get new range since you hit datatype limit even though the 2nd subscriber may not have used any of of their range of identities.

2. If distributor goes down, subscriber inserts will run out of identity values and will most likely fail.

You can read more about this in BOL topic "Replicating Identity Columns", http://msdn2.microsoft.com/en-us/library/ms152543.aspx.

Identity range management

I apologize for the repeated post, but my previous posts were not answered
and I'm getting desperate.
I have a SQL2005 Standard publisher with 10 SQL2005 Express subscribers
using web synchronization (anonymous subscriptions). The identity ranges on
the subscribers are not properly updating in at least some cases. The
identity range is 10000 with an 80% threshold but the subscribers run out of
identity values even though they synchronize every hour and never have more
than 150 inserts per sync. Re-syncing after the identity range is full (and
the client sees error messages) fixes the problem.
Is there any reason why an anonymous subscription on SQL2005 Express would
not get a new identity range before filling the old range? Thanks.
No, there is no reason. I think you should open a support incident with PSS
on this one.
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
"John Van Vliet" <JohnVanVliet@.discussions.microsoft.com> wrote in message
news:815687F4-989A-4CAD-A43C-45A942B55037@.microsoft.com...
>I apologize for the repeated post, but my previous posts were not answered
> and I'm getting desperate.
> I have a SQL2005 Standard publisher with 10 SQL2005 Express subscribers
> using web synchronization (anonymous subscriptions). The identity ranges
> on
> the subscribers are not properly updating in at least some cases. The
> identity range is 10000 with an 80% threshold but the subscribers run out
> of
> identity values even though they synchronize every hour and never have
> more
> than 150 inserts per sync. Re-syncing after the identity range is full
> (and
> the client sees error messages) fixes the problem.
> Is there any reason why an anonymous subscription on SQL2005 Express would
> not get a new identity range before filling the old range? Thanks.
>
|||My problem is similar, but in this case the publisher is complaining about
the insertions, so the publication database is the one running out of
identities.
I had seen this happening when the subscriber hasn't replicated for a while
and makes more insertions than the available range. However I am getting the
errors in the publication database, when we insert data from another system:
The insert failed. It conflicted with an identity range check constraint in
database 'Appraisal', replicated table 'dbo.ApprRenExistingVAC', column
'ApprRenExistingVACId'. If the identity column is automatically managed by
replication, update the range as follows: for the Publisher, execute
sp_adjustpublisheridentityrange; for the Subscriber, run the Distribution
Agent or the Merge Agent.
In this case our settings are:
@.pub_identity_range = 10000, @.identity_range = 1000, @.threshold = 80
we have 15 subscribers.
thanks in advance for any input.
"Hilary Cotter" wrote:

> No, there is no reason. I think you should open a support incident with PSS
> on this one.
> --
> 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
>
> "John Van Vliet" <JohnVanVliet@.discussions.microsoft.com> wrote in message
> news:815687F4-989A-4CAD-A43C-45A942B55037@.microsoft.com...
>
>

identity range management

hi all, got a major problem, having done some mods to my replicated
database, the subscriber, no has primary key violations. im using sql server
identity range management so this should be fine,
i have performed an table upgrade in this way before.
scrpit out the repliation,
remove the replaction from the publisher by deleting the publication and
then using sp_removeddbrepliation.
makeing my changes
then running the script to rebuild the repliaction.
however this time, in serveral tables at the subscriber the id ranges seem
to have gone back to range that have been used.
is there anyway i can get the ranges updated bearing in mind that im using
the auto identity range management.
Thanks Andrew
Andrew,
you could use dbcc checkident to reseed manually, edit the check constraints
accordingly, and change the values in MSrepl_identity_range on the
subscriber. This table is used to check if the subscriber has used up its
range or reached the threshold. The new range you set would be obtained from
MSrepl_identity_range on the distributor, which is the master table and is
used to generate new values. The values in this table (MSrepl_identity_range
on the distributor) would need to be changed to avoid a future potential
conflict.
HTH
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||After dropping the publication you will need to connect to the subscribers
and drop the replication check constraints on the tables. This is a
"problem" I have reported to Microsoft.
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
"andrew bourne" <andrewbourne@.vardells.com> wrote in message
news:eMFNzaihFHA.1948@.TK2MSFTNGP12.phx.gbl...
> hi all, got a major problem, having done some mods to my replicated
> database, the subscriber, no has primary key violations. im using sql
server
> identity range management so this should be fine,
> i have performed an table upgrade in this way before.
> scrpit out the repliation,
> remove the replaction from the publisher by deleting the publication and
> then using sp_removeddbrepliation.
> makeing my changes
> then running the script to rebuild the repliaction.
> however this time, in serveral tables at the subscriber the id ranges seem
> to have gone back to range that have been used.
> is there anyway i can get the ranges updated bearing in mind that im using
> the auto identity range management.
> Thanks Andrew
>
|||hi all
i have stopped client connecteding to the subcriber
ok so if at the subscriber i change the next_seed value to the current_max
value in the msrepl_identity_range.
at the distributer i change the next_seed value to a range that is out of
the way.
If i then run the merge agent, will that pick up that the subcribers ranges
need changeing and change them to the value in the next_seed specified in
the distributor.
Thanks In Advance Andrew
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:eij4KLjhFHA.576@.tk2msftngp13.phx.gbl...
> Andrew,
> you could use dbcc checkident to reseed manually, edit the check
> constraints accordingly, and change the values in MSrepl_identity_range on
> the subscriber. This table is used to check if the subscriber has used up
> its range or reached the threshold. The new range you set would be
> obtained from MSrepl_identity_range on the distributor, which is the
> master table and is used to generate new values. The values in this table
> (MSrepl_identity_range on the distributor) would need to be changed to
> avoid a future potential conflict.
> HTH
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Andrew,
I'm suggesting you bypass the automatic management and assign a range
yourself. Setting the values in msrepl_identity_range on the subscriber for
the range you want, msrepl_identity_range on the distributor to make sure it
is greater than the subscriber range, issuing a dbcc checkident, and
changing the check constraints will allow things to proceed as per normal,
and running the merge agent will register that anything has been changed
manually.
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Identity Range Management

Good morning All,
In the context of a merge replica:
Does this range serve as surrogate key (Primary Key) but after the sync, the
server overlooks it when inserting new rows in the published table and
generate a sequential one?
Here's what I am trying to achieve:
My disconnected users, have to issue unique File# to their customers.
Once a file number is given to a customer, the customer will use this file
number to reference his/her case for ever.
I want this number to be the unique identifier of his/her record in my table.
If I use this range model, then that would solve the problem provided that
the server will use this number as the primary key for the table where
customer cases are stored.
I read a few articles about the range model but it never read that this
number is kept or used as a primary key in a table.
What am I missing here?
Also
How can we reduce the large skipped numbers not used between sync?
Thanks
YOW
Yes. So the identity column which may or may not be the primary key or may
be one of the columns involved in the primary key could appear on two nodes
simultaneously if Automatic Identity Range Management is not working
correctly. This will lead to a conflict when the merge agent runs and can
cause one of the inserts to be rolled back and replaced by the winning
insert.
If it is working correctly or if there are other columns in the primary key,
or if the identity value is the only key in a primary key or unique index
and you are perfectly partitioned it should work.
Automatic identity range management promotes efficient use of the identity
ranges. If you notice that the ranges are not being used efficiently on the
publisher lower the publisher range. If it is not being used efficiently on
all subscribers, lower that range. If it is not being used efficiently on
one or the subscribers, but is on the other you are out of luck.
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
"Lottoman2000 NEWBE" <Lottoman2000NEWBE@.discussions.microsoft.com> wrote in
message news:C2F1728A-0241-412E-AF9D-CAB3BE2CB04C@.microsoft.com...
> Good morning All,
> In the context of a merge replica:
> Does this range serve as surrogate key (Primary Key) but after the sync,
the
> server overlooks it when inserting new rows in the published table and
> generate a sequential one?
> Here's what I am trying to achieve:
> My disconnected users, have to issue unique File# to their customers.
> Once a file number is given to a customer, the customer will use this file
> number to reference his/her case for ever.
> I want this number to be the unique identifier of his/her record in my
table.
> If I use this range model, then that would solve the problem provided that
> the server will use this number as the primary key for the table where
> customer cases are stored.
> I read a few articles about the range model but it never read that this
> number is kept or used as a primary key in a table.
> What am I missing here?
> Also
> How can we reduce the large skipped numbers not used between sync?
> Thanks
> YOW
|||What do you think if i go for ROWGUID instead?
"Hilary Cotter" wrote:

> Yes. So the identity column which may or may not be the primary key or may
> be one of the columns involved in the primary key could appear on two nodes
> simultaneously if Automatic Identity Range Management is not working
> correctly. This will lead to a conflict when the merge agent runs and can
> cause one of the inserts to be rolled back and replaced by the winning
> insert.
> If it is working correctly or if there are other columns in the primary key,
> or if the identity value is the only key in a primary key or unique index
> and you are perfectly partitioned it should work.
> Automatic identity range management promotes efficient use of the identity
> ranges. If you notice that the ranges are not being used efficiently on the
> publisher lower the publisher range. If it is not being used efficiently on
> all subscribers, lower that range. If it is not being used efficiently on
> one or the subscribers, but is on the other you are out of luck.
> --
> 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
> "Lottoman2000 NEWBE" <Lottoman2000NEWBE@.discussions.microsoft.com> wrote in
> message news:C2F1728A-0241-412E-AF9D-CAB3BE2CB04C@.microsoft.com...
> the
> table.
>
>
|||They tend not to make good PK's. Have a look at this for more info on why
not.
http://www.aspfaq.com/show.asp?id=2504
Its in the bottom section.
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
"Lottoman2000 NEWBE" <Lottoman2000NEWBE@.discussions.microsoft.com> wrote in
message news:8587BCD9-84AB-4719-BFFA-8A7BD607A847@.microsoft.com...[vbcol=seagreen]
> What do you think if i go for ROWGUID instead?
> "Hilary Cotter" wrote:
may[vbcol=seagreen]
nodes[vbcol=seagreen]
can[vbcol=seagreen]
key,[vbcol=seagreen]
index[vbcol=seagreen]
identity[vbcol=seagreen]
the[vbcol=seagreen]
on[vbcol=seagreen]
on[vbcol=seagreen]
in[vbcol=seagreen]
sync,[vbcol=seagreen]
file[vbcol=seagreen]
that[vbcol=seagreen]
this[vbcol=seagreen]
|||From your first answer:
if Automatic Identity Range Management is not working correctly. This will
lead to a conflict when the merge agent runs and can cause one of the
inserts to be rolled back and replaced by the winning insert"
What could make Automated IRM not work properly?
Thanks
"Hilary Cotter" wrote:

> They tend not to make good PK's. Have a look at this for more info on why
> not.
> http://www.aspfaq.com/show.asp?id=2504
> Its in the bottom section.
> --
> 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
> "Lottoman2000 NEWBE" <Lottoman2000NEWBE@.discussions.microsoft.com> wrote in
> message news:8587BCD9-84AB-4719-BFFA-8A7BD607A847@.microsoft.com...
> may
> nodes
> can
> key,
> index
> identity
> the
> on
> on
> in
> sync,
> file
> that
> this
>
>
|||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
"Lottoman2000 NEWBE" <Lottoman2000NEWBE@.discussions.microsoft.com> wrote in
message news:37219273-4565-47B0-AB13-1D01132A0658@.microsoft.com...
> From your first answer:
> if Automatic Identity Range Management is not working correctly. This
will[vbcol=seagreen]
> lead to a conflict when the merge agent runs and can cause one of the
> inserts to be rolled back and replaced by the winning insert"
> What could make Automated IRM not work properly?
>
> Thanks
> "Hilary Cotter" wrote:
why[vbcol=seagreen]
in[vbcol=seagreen]
or[vbcol=seagreen]
two[vbcol=seagreen]
and[vbcol=seagreen]
winning[vbcol=seagreen]
primary[vbcol=seagreen]
on[vbcol=seagreen]
efficiently[vbcol=seagreen]
efficiently[vbcol=seagreen]
wrote[vbcol=seagreen]
and[vbcol=seagreen]
customers.[vbcol=seagreen]
this[vbcol=seagreen]
in my[vbcol=seagreen]
provided[vbcol=seagreen]
where[vbcol=seagreen]
|||I'd like to say bugs, but I am not really convinced that there are bugs with
this. Properly sized it does seem to work well - or at least it has worked
well for us on several installations.
If you don't size your data type or your ranges correctly or run the agent
in continuous mode, it might not update the ranges in time. This seems to be
the biggest problem with it.
It also seems that if you are monkeying around with the metadata that the
merge agent will not detect that an article is under automatic range
management when it runs and then check the local and remote ranges. It
normally does this check when it first runs. I have seen cases where the
detection proc never runs, but when I try to repro it on a clean database I
am unable to do so. So I think its something i have messed up along the way.
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
"Lottoman2000 NEWBE" <Lottoman2000NEWBE@.discussions.microsoft.com> wrote in
message news:37219273-4565-47B0-AB13-1D01132A0658@.microsoft.com...
> From your first answer:
> if Automatic Identity Range Management is not working correctly. This
will[vbcol=seagreen]
> lead to a conflict when the merge agent runs and can cause one of the
> inserts to be rolled back and replaced by the winning insert"
> What could make Automated IRM not work properly?
>
> Thanks
> "Hilary Cotter" wrote:
why[vbcol=seagreen]
in[vbcol=seagreen]
or[vbcol=seagreen]
two[vbcol=seagreen]
and[vbcol=seagreen]
winning[vbcol=seagreen]
primary[vbcol=seagreen]
on[vbcol=seagreen]
efficiently[vbcol=seagreen]
efficiently[vbcol=seagreen]
wrote[vbcol=seagreen]
and[vbcol=seagreen]
customers.[vbcol=seagreen]
this[vbcol=seagreen]
in my[vbcol=seagreen]
provided[vbcol=seagreen]
where[vbcol=seagreen]

Identity problem. (Need generate on subscriber new identity values)

If you change the publication to queued updating, use
automatic identity range management and don't run the
queue reader, you should achieve what you require.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
But where in that case subcribers updates will be stored? On distributor?
Is it known bug with incorrect handling identity values in replications? Or
it is my own issue?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:050b01c50853$c6e94010$a601280a@.phx.gbl...
> If you change the publication to queued updating, use
> automatic identity range management and don't run the
> queue reader, you should achieve what you require.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||The subscriber updates will be held on the queue table at
the subscriber, or you could remove the subscriber
triggers. It is assumed that subscribers are read only in
normal circumstances, so any issues regarding data
changes at a subscriber and problems with identities on
the subscriber are not really catered for. Identities are
only coded for if the subscriber uses immediate updating
or queued updating.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

identity management...

now as i have gotten the bugs out replication seems to work great (2 days and
no more conflicts), but I have a general comment. Microsoft documentation
stinks.
Wheres the Microsoft article on setting up replication, INCLUDING
SCREENSHOTS? Why did the defaults leave me high and dry with respects to
identity fields being primary keys and not reseeding properly. Does it not
make sense to have identity management turned on by default in merge
replication where identity fields are involved? Had this been the case I
would not have even experienced a hiccough in the transition to a replicated
environment. As it was not the case, I called PSS, paid for a support call,
and the agent I spoke with (Terry) never clued me into this fact, he only
helped fix all the primary key troubles (using DBCC CHECKIDENT which is
manually setting the range and manually maintaining it, which I was also not
made aware of). Any support call is a two way street, but I feel MS has made
a great product, poor documentation and in my case caused poor customer
relations.
pUmkInhEd
There are a few articles on the web on setting up replication, but they are
mostly independant. In general, the microsoft documentation doesn't have
screenshots. There are some articles here:
http://www.mssqlcity.com/Articles/Replic/Replic.htm and there is now Hilar'y
book which has loads of graphgics:
http://www.amazon.com/exec/obidos/tg...lance&s=books.
As for the automatic range management being turned on by default, this might
be a good idea in some cases, but I would rather have a prompt. It might be
that you want to use manual range management instead, but either way, to
have a prompt would be enough to make you realize that some type of
intervention was necessary.
You don't have to use dbcc checkident on each subscriber - have a look at
http://www.replicationanswers.com/ManualIdentities.htm for other ways of
manual identity range management. Using dbcc checkident will be ok for
ranges, but more complex algorithms used to ensure no overlap can't be done
this way, because the seed and increment will both need altering.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks for your response Paul, I guess the underlying solution is to educate
myself. Manual range management does not fit my solution since it seems to
require some type of user intervention to keep things going. I appreciate
your input and also your suggested reading material.
Thanks, Brandon
"Paul Ibison" wrote:

> There are a few articles on the web on setting up replication, but they are
> mostly independant. In general, the microsoft documentation doesn't have
> screenshots. There are some articles here:
> http://www.mssqlcity.com/Articles/Replic/Replic.htm and there is now Hilar'y
> book which has loads of graphgics:
> http://www.amazon.com/exec/obidos/tg...lance&s=books.
> As for the automatic range management being turned on by default, this might
> be a good idea in some cases, but I would rather have a prompt. It might be
> that you want to use manual range management instead, but either way, to
> have a prompt would be enough to make you realize that some type of
> intervention was necessary.
> You don't have to use dbcc checkident on each subscriber - have a look at
> http://www.replicationanswers.com/ManualIdentities.htm for other ways of
> manual identity range management. Using dbcc checkident will be ok for
> ranges, but more complex algorithms used to ensure no overlap can't be done
> this way, because the seed and increment will both need altering.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Manual range management is manual only in the initial
setup, but there again, automatic range management
is 'manua;l' by the same rationale - you have to
configure the form ;)
Admittedly it is simpler to do automatic, and I only
would use manual for nosync initializations.
Good luck,
Paul

>--Original Message--
>Thanks for your response Paul, I guess the underlying
solution is to educate
>myself. Manual range management does not fit my
solution since it seems to
>require some type of user intervention to keep things
going. I appreciate[vbcol=seagreen]
>your input and also your suggested reading material.
>Thanks, Brandon
>"Paul Ibison" wrote:
replication, but they are[vbcol=seagreen]
documentation doesn't have[vbcol=seagreen]
and there is now Hilar'y[vbcol=seagreen]
/0974973602/qid=1107634413/sr=1-1/ref=sr_1_1/103-5571393-
2419806?v=glance&s=books.[vbcol=seagreen]
by default, this might[vbcol=seagreen]
a prompt. It might be[vbcol=seagreen]
but either way, to[vbcol=seagreen]
some type of[vbcol=seagreen]
subscriber - have a look at[vbcol=seagreen]
for other ways of[vbcol=seagreen]
checkident will be ok for[vbcol=seagreen]
overlap can't be done[vbcol=seagreen]
need altering.[vbcol=seagreen]
www.replicationanswers.com
>.
>

Identity Management

Hi,
I have a merge replication going on. Say, I have a subscriber with an
identity range from 1000 to 1200 and I have only used 100 identities of that
range. For some what reason I have to reinitialise the subscription. What
publisher does is it allocates a new set of range to the table i.e. 1300 -
1400 to the article on subscription. As you can see I have simply wasted 100
identities i.e. from 1100 to 1200. Please note identity allocation is
happening automatically.
Is there a way that I can avoid the wastage?
How can I deduce using system stored procedure that what identities are in
use for each article on each subscriber?
Thanks
Vivek
This is normally not a concern.
Basically replication does not track which identity ranges are in place by
subscribers. All it does is track the last deployed identity range and the
range in use on the publication database.
While I don't recommend it, you can go to the subscriber and do a dbcc
checkident('TableName',reseed,101) and then run a sp_help TableName identify
the replication constraint which limits the identity values which can be
used in the subscriber, and modify it for the range you wish to use.
Again I don't recommend doing this.
You might want to check this link for more on this feature.
http://www.simple-talk.com/2005/07/05/replication/
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
"Vivek Sharma" <vivek_nz76@.hotmail.com> wrote in message
news:e97gXp$3FHA.476@.TK2MSFTNGP15.phx.gbl...
> Hi,
> I have a merge replication going on. Say, I have a subscriber with an
> identity range from 1000 to 1200 and I have only used 100 identities of
that
> range. For some what reason I have to reinitialise the subscription. What
> publisher does is it allocates a new set of range to the table i.e. 1300 -
> 1400 to the article on subscription. As you can see I have simply wasted
100
> identities i.e. from 1100 to 1200. Please note identity allocation is
> happening automatically.
> Is there a way that I can avoid the wastage?
> How can I deduce using system stored procedure that what identities are in
> use for each article on each subscriber?
> Thanks
> Vivek
>