"Mark for re-initialization" hangs

Hi, I have a problem with a SQL 2000 transactional replication.
It is a replication with subscriptions on several world wide located
servers.
A WAN connection has been disabled for some time and as result one
subscription has been marked inactive.
Message: "The subscription(s) have been marked inactive and must be
reinitialized. NoSync subscriptions will need to be dropped and
recreated."
In the past this problem could been solved by re-initializing the
subscription but in this case
the Enterprise Manager hangs, when I tried to mark the subscription
for re-initialization.
Both SQL servers (publisher and subscriber) have been re-started but
the problem remained.
There are no sessions on the subscriber database which could block the
initialization.
The subscription can not be deleted.
What more can I do?
can you issue this command in qa on the publisher in the publication
database?
sp_reinitsubscription
'publicationname','all','SubscriberName','subscrip tionDatabase'
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
"hmb1963" <hmb1963@.gmx-topmail.de> wrote in message
news:1185358724.772454.145180@.k79g2000hse.googlegr oups.com...
> Hi, I have a problem with a SQL 2000 transactional replication.
> It is a replication with subscriptions on several world wide located
> servers.
> A WAN connection has been disabled for some time and as result one
> subscription has been marked inactive.
> Message: "The subscription(s) have been marked inactive and must be
> reinitialized. NoSync subscriptions will need to be dropped and
> recreated."
> In the past this problem could been solved by re-initializing the
> subscription but in this case
> the Enterprise Manager hangs, when I tried to mark the subscription
> for re-initialization.
> Both SQL servers (publisher and subscriber) have been re-started but
> the problem remained.
> There are no sessions on the subscriber database which could block the
> initialization.
> The subscription can not be deleted.
> What more can I do?
>
|||I tried out the stored procedure but the result was a hanging qa
without any status or error message.
|||use sp_who2 to identify locks/deadlocks caused by the replication processes
and selectively kill them,
Then try again.
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
"hmb1963" <hmb1963@.gmx-topmail.de> wrote in message
news:1185443077.713064.265760@.r34g2000hsd.googlegr oups.com...
>I tried out the stored procedure but the result was a hanging qa
> without any status or error message.
>
|||Success!
I have killed again all sessions both on the publisher and subscriber
databases and
then the stored procedure sp_reinitsubscription worked.
Many thanks for your support.
Martin

"Know Issue" not in KB. COLID continues to rise.

I use transactional replication on several very "wide" table. One has
254 columns. After finding that was my limit for replication to work I
removed an unused columns and added a new needed column. Since the
COLID in the SYSCOLUMNS did not reset replication failed. I'm down to
renaming columns now.
This was in SQL Server 2000 and is still present in 2005. A call to
Microsoft turned up "Known Issue" statement.
Has anyone found another way around this without creating a new table
with the needed columns and moving the current data in? Keep in mind I
inherited this database and did not create a table this wide.
Thanks.
Mike.Mike,
apart from your suggestion, the only other workaround I am aware of is to
partition the table and to replicate the 2 tables separately, which is
probably more work than your method.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com

"Know Issue" not in KB. COLID continues to rise.

I use transactional replication on several very "wide" table. One has
254 columns. After finding that was my limit for replication to work I
removed an unused columns and added a new needed column. Since the
COLID in the SYSCOLUMNS did not reset replication failed. I'm down to
renaming columns now.
This was in SQL Server 2000 and is still present in 2005. A call to
Microsoft turned up "Known Issue" statement.
Has anyone found another way around this without creating a new table
with the needed columns and moving the current data in? Keep in mind I
inherited this database and did not create a table this wide.
Thanks.
Mike.Mike,
apart from your suggestion, the only other workaround I am aware of is to
partition the table and to replicate the 2 tables separately, which is
probably more work than your method.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com