merge replication issue

Hi all,
Setup: SQL2K (Enterprise) [SQLSVR1] in Network 1 - 2 publications (merge
for tables that data changes in often, and snapshot for stuff that is
batched after a few months) - there are a number of MSDE subscribers to
these publications in this network.
The same setup is in Network 2 [SQLSVR2].
SQLSVR2 subscribes to the SQLSVR1 publications, and re-publishes them for
Network 2 MSDE subscribers.
I have an app that works on the local msde installations - any changes to
a specific database is then replicated.
Everything works great in Network 1.
On Network 2, I tried to insert into a specific table and I get a
"Invalid object name 'ctsv_EEF98A7665F64374A3C47E6A3D87155E'." error ?
Other tables do not appear to be effected ?
I read a post that appear to suggest security context in setting up the
publications ? - the publications security context is a sql user, and the
distribution folder is shared so that all users in the network can read
and write to it
(http://groups.google.com/groups?hl=e...3DN%26tab%3Dwg)
Any information on helping me resolve this would be useful.
tia,
Best Regards,
Ranjeet.
how did you deploy the problem subscriber?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ranjeet" <not-telling> wrote in message
news:opsemtjwu6v8so89@.athwalrt40.castlewood.co.uk. ..
> Hi all,
> Setup: SQL2K (Enterprise) [SQLSVR1] in Network 1 - 2 publications (merge
> for tables that data changes in often, and snapshot for stuff that is
> batched after a few months) - there are a number of MSDE subscribers to
> these publications in this network.
> The same setup is in Network 2 [SQLSVR2].
> SQLSVR2 subscribes to the SQLSVR1 publications, and re-publishes them for
> Network 2 MSDE subscribers.
> I have an app that works on the local msde installations - any changes to
> a specific database is then replicated.
> Everything works great in Network 1.
> On Network 2, I tried to insert into a specific table and I get a
> "Invalid object name 'ctsv_EEF98A7665F64374A3C47E6A3D87155E'." error ?
> Other tables do not appear to be effected ?
> I read a post that appear to suggest security context in setting up the
> publications ? - the publications security context is a sql user, and the
> distribution folder is shared so that all users in the network can read
> and write to it
>
(http://groups.google.com/groups?hl=e...32G%23zQRJBHA.
388%40tkmsftngp02&rnum=1&prev=/groups%3Fq%3Dinvalid%2520object%2520name%2520
%27tsvw_%26hl%3Den%26lr%3D%26ie%3DUTF-8%26sa%3DN%26tab%3Dwg)
> Any information on helping me resolve this would be useful.
> tia,
> Best Regards,
> Ranjeet.
|||used enterprise manager logged on as a user in network 1 (registered the
subscriber in EM, and clicked through to add pull subscription to SQLSVR2
in network 2).
the subscriber and publisher were part of network 2.
|||when you start getting messages like this telling you you have missing
views, or the merge agent expects a different view than the one present on
your subscriber, you have inconsistent replication metadata.
While it is entirely possible to hack your way through the triggers and
adjust them for the views the merge agent expects to use, you are better off
to redeploy your subscriber.
I'm still not exactly sure how you deployed your subscribers. The way to do
it is to create a publication on SQLSRV1, and deploy a subscription to
SQLSRV2. After the subscription is deployed to SQLSRV2, you then create
your publication on SQLSRV2 and deploy the subscriptions to the MSDE
subscribers.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"ranjeet" <not-telling> wrote in message
news:opsem0kgrgv8so89@.athwalrt40.castlewood.co.uk. ..
> used enterprise manager logged on as a user in network 1 (registered the
> subscriber in EM, and clicked through to add pull subscription to SQLSVR2
> in network 2).
> the subscriber and publisher were part of network 2.
|||Hi Hillary,
thanks for the info.
My deployment was as you described.
I am now rebuilding the subscriptions and publications for network 2 and
SQLSVR2 in the hope that this fixes this most frustrating problem. I am
in the fortunate position that my users are not yet ready to go live in
network 2 (phew!).
I will update this post with my results incase it is ever useful to anyone.
thanks again,
Ranjeet.
|||recreating the server subscription and publications resolved this problem.
thanks again for your help hilary.
Ranjeet.