Merge replication failure

Hello,
I have an SQL2000 server, which acts as the distributor and as the
publisher. The clients are Pocket PC's, using SQL Server CE. I have the
latest SP for both. The replication is a merge replication, with a lot of
join filters, more than 100 articles (only tables, no views or procedures
included). The average size of the database on the clients is about ~7MB.
Sometimes, following a massive delete on several tables (delete from table,
than insert into table select from sthing), I have got the following error
message during replication:
1. "a call to the sql server reconciler has failed"
2. "failed to enumerate changes"
3. "select permission denied on column <pk> of object MS_<long-long guid>"
The error occurs in the stored procedure sp_MSsetupbelongs.
Actually, the message is right, the user has no rights to the referred
table. But. This is a generated table, created by the replication itself (I
think this is the table used for deletion). After I've added the rights, the
error disapperared. Reinitialize also helps.
Do I have to do this all for the tables in the publication? I could not do
this, because of the generated table names.
Or this is a bug?
Thanks for replies,
Tamas Beri
Funny, but I can't find anything better solution than this one:
select
'grant select on '+sysobjects.name+' to sales;'
from
sysobjects
where
name like 'MS_bi%_v_%'
order by
sysobjects.name;
After you ran this generated script, the whole problem described down there
disappears.
Do You have any information about the Service Pack 4? I have a lot of
problems with sql server ce and merge replication.
Regards,
Tamas Beri
"Beri Tamas" <gfoyle@.freemail.hu> az albbiakat rta a kvetkezo zenetben
news:uYP%23YL89EHA.2984@.TK2MSFTNGP09.phx.gbl...
> Hello,
> I have an SQL2000 server, which acts as the distributor and as the
> publisher. The clients are Pocket PC's, using SQL Server CE. I have the
> latest SP for both. The replication is a merge replication, with a lot of
> join filters, more than 100 articles (only tables, no views or procedures
> included). The average size of the database on the clients is about ~7MB.
> Sometimes, following a massive delete on several tables (delete from
table,
> than insert into table select from sthing), I have got the following error
> message during replication:
> 1. "a call to the sql server reconciler has failed"
> 2. "failed to enumerate changes"
> 3. "select permission denied on column <pk> of object MS_<long-long guid>"
> The error occurs in the stored procedure sp_MSsetupbelongs.
> Actually, the message is right, the user has no rights to the referred
> table. But. This is a generated table, created by the replication itself
(I
> think this is the table used for deletion). After I've added the rights,
the
> error disapperared. Reinitialize also helps.
> Do I have to do this all for the tables in the publication? I could not do
> this, because of the generated table names.
> Or this is a bug?
> Thanks for replies,
> Tamas Beri
|||Hi Beri,
Replication shouldn't require you to issue the explicit select on this
particular object. Can you please provide some more info so that we can try
to create the repro in our test environment?
1. What kind of permission have you provided to publisher and distributor
login?
2. What's the type of object 'MS_bi%_v_%' - view, SP, etc?
3. Can you please provide the content of following tables - sysmergearticles
& sysmergepublications?
4. In case you are okay - can you post your scripts which you used to setup
your replication?
thanks - Deepak
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Beri Tamas" <gfoyle@.freemail.hu> wrote in message
news:Ocybvt%239EHA.2984@.TK2MSFTNGP09.phx.gbl...
> Funny, but I can't find anything better solution than this one:
> select
> 'grant select on '+sysobjects.name+' to sales;'
> from
> sysobjects
> where
> name like 'MS_bi%_v_%'
> order by
> sysobjects.name;
> After you ran this generated script, the whole problem described down
there[vbcol=seagreen]
> disappears.
> Do You have any information about the Service Pack 4? I have a lot of
> problems with sql server ce and merge replication.
> Regards,
> Tamas Beri
> "Beri Tamas" <gfoyle@.freemail.hu> az albbiakat rta a kvetkezo zenetben
> news:uYP%23YL89EHA.2984@.TK2MSFTNGP09.phx.gbl...
of[vbcol=seagreen]
procedures[vbcol=seagreen]
~7MB.[vbcol=seagreen]
> table,
error[vbcol=seagreen]
guid>"[vbcol=seagreen]
> (I
> the
do
>
|||Same error here, but I run the script and still get it.
Any more on this one?

merge replication and disaster recovery (SQL 2005)

Once a merge relationship is established, what happens when either the
publisher restores a previous backup, or the subscriber restores a previous
backup? How is this handled? Will the latest data will be restored from
the database that didn't crash?
--Troy
If a publisher is restored to an earlier state, data which is in the
subscriber is detected as new (even if it came from the publisher originally
before the crash) and fills in the publisher. If the subscriber is restored
to a previous state, data flows from the publisher back to the subscriber to
sync it up.
This process will continue as long as you are within your retention
settings.
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
"Troy Wolbrink" <wolbrink@.ccci.org> wrote in message
news:%23UjcBWJ9FHA.1020@.TK2MSFTNGP15.phx.gbl...
> Once a merge relationship is established, what happens when either the
> publisher restores a previous backup, or the subscriber restores a
> previous backup? How is this handled? Will the latest data will be
> restored from the database that didn't crash?
> --Troy
>
|||As long as your within your retention settings, would new deletes be
included? Or would the restored record be seen as a new record and then
reinserted?
--Troy

> If a publisher is restored to an earlier state, data which is in the
> subscriber is detected as new (even if it came from the publisher
> originally before the crash) and fills in the publisher. If the subscriber
> is restored to a previous state, data flows from the publisher back to the
> subscriber to sync it up.
> This process will continue as long as you are within your retention
> settings.
[vbcol=seagreen]