Error Pull replication

I have two Win2000 that are in a domain. SQL1(SQL server) acts as the
distributor and publisher. SQL2(MSDE2000) acts as the subscriber. Push merge
replication is running well.
I want to PULL the db from SQL1 to the db on SQL2, failed :The process could
not connect to Distributor. Cannot generate SSPI context.
I changed Merge Agent location from Subsciber to Distributor, message :
Server 'SQLTEST1" is not prepared to run the offloaded agent
Error Unable to activate the agent on the specified remote server because of
security restrictions. Use dcomcnfg on the remote server to allow the local
SQL Server Agent account to activate the agent
1. Where the best location for the Merge Agent
2. What I have to do next
the SSPI error should be addressed first - consult these kb articles for
more info on it.
http://support.microsoft.com/search/...alse&x=11&y=14
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
"Thang Long" <ThangLong@.discussions.microsoft.com> wrote in message
news:CA8EB6A7-F554-4A18-B817-6CE8F3B9A2C6@.microsoft.com...
> I have two Win2000 that are in a domain. SQL1(SQL server) acts as the
> distributor and publisher. SQL2(MSDE2000) acts as the subscriber. Push
merge
> replication is running well.
> I want to PULL the db from SQL1 to the db on SQL2, failed :The process
could
> not connect to Distributor. Cannot generate SSPI context.
> I changed Merge Agent location from Subsciber to Distributor, message :
> Server 'SQLTEST1" is not prepared to run the offloaded agent
> Error Unable to activate the agent on the specified remote server because
of
> security restrictions. Use dcomcnfg on the remote server to allow the
local
> SQL Server Agent account to activate the agent
> 1. Where the best location for the Merge Agent
> 2. What I have to do next
>
|||Thank you for the reply. Now it is running well.
One more question. I want to use dinamic filter, different database name for
each subscriber:
... WHERE CityCode = DB_NAME()
but no record in the subscriber table. Plese advice.
"Hilary Cotter" wrote:

> the SSPI error should be addressed first - consult these kb articles for
> more info on it.
> http://support.microsoft.com/search/...alse&x=11&y=14
> --
> 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
> "Thang Long" <ThangLong@.discussions.microsoft.com> wrote in message
> news:CA8EB6A7-F554-4A18-B817-6CE8F3B9A2C6@.microsoft.com...
> merge
> could
> of
> local
>
>
|||I think that db_name will always resolve to msdb - as that is the database
that the job is run in. In this case I think you will need to change your
filtering criteria.
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
"Thang Long" <ThangLong@.discussions.microsoft.com> wrote in message
news:75905A3F-F21F-4131-9FDA-79D6628B79BB@.microsoft.com...
> Thank you for the reply. Now it is running well.
> One more question. I want to use dinamic filter, different database name
for[vbcol=seagreen]
> each subscriber:
> ... WHERE CityCode = DB_NAME()
> but no record in the subscriber table. Plese advice.
>
> "Hilary Cotter" wrote:
http://support.microsoft.com/search/...alse&x=11&y=14[vbcol=seagreen]
Push[vbcol=seagreen]
:[vbcol=seagreen]
because[vbcol=seagreen]
|||what should be the filter?
Please advise.
Thank you.
"Hilary Cotter" wrote:

> I think that db_name will always resolve to msdb - as that is the database
> that the job is run in. In this case I think you will need to change your
> filtering criteria.
> --
> 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
> "Thang Long" <ThangLong@.discussions.microsoft.com> wrote in message
> news:75905A3F-F21F-4131-9FDA-79D6628B79BB@.microsoft.com...
> for
> http://support.microsoft.com/search/...alse&x=11&y=14
> Push
> :
> because
>
>
|||I would like to use instance name as the filtering criteria, it is posible ?
Please advice.
Thank you.
"Hilary Cotter" wrote:

> I think that db_name will always resolve to msdb - as that is the database
> that the job is run in. In this case I think you will need to change your
> filtering criteria.
> --
> 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
> "Thang Long" <ThangLong@.discussions.microsoft.com> wrote in message
> news:75905A3F-F21F-4131-9FDA-79D6628B79BB@.microsoft.com...
> for
> http://support.microsoft.com/search/...alse&x=11&y=14
> Push
> :
> because
>
>

Error Message 8144 on Transaction Push Replication

Don,
have you changed the schema on the publisher and
subscriber - please can you check the table definitions.
Perhaps this was a nosync initialization and you created
the procedures by hand and they are now out of sync as
you've altered the columns on the publisher? Depending on
the problem it may be possible to run
sp_scriptpublicationcustomprocs to generate new
procedures and then recreate them on the subscriber if
this is the case. I'd only do this if the schemas are
identical.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Paul,
Thank you so much. The developers were upgrading the publication and got the
error message that Dirc Khan-Evans just posted.
Trying to run ALTER TABLE ... get the error message:
Server: Msg 4929, Level 16, State 1, Line 1
Cannot alter the table 'blah' because it is being published for replication.
I had no choice but to delete the publication. I recreated it and pushed a
new subscription and it ran successfully. However, the schema changes did not
carry over to the subscriber. The subsriber table does not have the new
fields. That is why I am getting this error. Should I delete the table on
the subscriber and push a new subscription? Thanks.
Don
the "Paul Ibison" wrote:

> Don,
> have you changed the schema on the publisher and
> subscriber - please can you check the table definitions.
> Perhaps this was a nosync initialization and you created
> the procedures by hand and they are now out of sync as
> you've altered the columns on the publisher? Depending on
> the problem it may be possible to run
> sp_scriptpublicationcustomprocs to generate new
> procedures and then recreate them on the subscriber if
> this is the case. I'd only do this if the schemas are
> identical.
> HTH,
> Paul Ibison
> (The ONLY sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Don,
I'd reinitialize, but first double-check something in the
publication properties. On the article properties
elipsis, snapshot tab, for name conflicts check that it
says 'DROP the existing table'. When you subscribe, be
sure to leave the default which is to initialize. Then it
should all go fine.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

>
|||Paul,
Just to let you know how the story ended. I tried to reinitialize, but that
also did not work. I ended up droping the tables on the subscriber that had
schemas different from the publisher. I scripted the tables from the
publisher and recreated them on the subscriber. I then had to recreate the
publications and push the subscriptions. It now seems to be running fine.
Just one thought... the publisher is on SQL 2000 sp2 and the subsciber is on
2000 sp3. I don't know if this was a bug. Thanks for all your help.
Don Saluga
Vector Security Inc.
"Paul Ibison" wrote:

> Don,
> I'd reinitialize, but first double-check something in the
> publication properties. On the article properties
> elipsis, snapshot tab, for name conflicts check that it
> says 'DROP the existing table'. When you subscribe, be
> sure to leave the default which is to initialize. Then it
> should all go fine.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Thanks for the update Don - it's always helpful.
Regards,
Paul
"Don" <Don@.discussions.microsoft.com> wrote in message
news:A1286950-DC8C-4DB3-97CC-1C6E06E90565@.microsoft.com...
> Paul,
> Just to let you know how the story ended. I tried to reinitialize, but
that
> also did not work. I ended up droping the tables on the subscriber that
had
> schemas different from the publisher. I scripted the tables from the
> publisher and recreated them on the subscriber. I then had to recreate
the
> publications and push the subscriptions. It now seems to be running fine.
> Just one thought... the publisher is on SQL 2000 sp2 and the subsciber is
on[vbcol=seagreen]
> 2000 sp3. I don't know if this was a bug. Thanks for all your help.
> Don Saluga
> Vector Security Inc.
> "Paul Ibison" wrote: