sql server replication: Hi,

I have a fairly major problem with my SQL Server 2000 merge replication
setup. Certain of my subscribers are causing conflicts such as:

"The row was inserted at 'MyServer.MyPublication' but could not be
inserted at 'Subscriber.Subscription'. Procedure or function
sp_ins_A7E27E390276442D98DB48C7F9BC4442 has too many arguments
specified."

The cause of this error is currently my second priority. The major
problem is that the row in question is actually being *deleted* from
the publisher when the subscriber attempts to synchronise. This is
fairly disasterous in a production system. I'm also encountering a
similar conflict with updates, wherein changes to the article are being
reverted upon synchronisation.

What I think I need is a resolver which says "the publisher always
wins". My understanding is that the default resolver behaves like
that, but records are being deleted despite the default resolver being
selected for the article in question.

Can anyone suggest a way to force the publisher to 'win' in all
circumstances?

Thanks in advance,
Alex

Hi Paul

Thank you yet again! This has been driving me demented. If you're ever
in London, let me know and I'll buy you a drink or ten. :)

Cheers
Alex

Have a look at this article on compensating changes:
http://support.microsoft.com/kb/828637.
This property can now be controlled in SQL Server 2000.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .

My position in a nutshell: three subscribers are throwing an error on
insert/update to certain tables. We're not certain why, but think it's
due to an error during the initial configuration of these subscribers.
As a result of the errors the changes were being lost (due to the
@compensate_for_errors thing, which I didn't know about, being set to
true).

The main issue is that I don't want to lose those changes. I don't
care if the three subscribers become out of sync with everyone else, as
I'm going to have to recreate them from scratch anyway. So I'm going
to act as though the 'conflicts' (read: 'errors') never arose in the
first place. Then, once we've rebuilt the offending subscribers,
everything will be working nice and smoothly and no data will have been
lost.

At least, that's the theory...

But if you have a conflict, the conflict resolver acts. And the default one
is the publisher action wins. So I don't understand why you are getting this
error.

And, if "@compensate_for_errors=False" it waits until you resolve the
conflict with the Conflict Viewer, so the conflict resolver doesn't act. So,
this is more work for you...


Josep




<WombatDeath@gmail.com> escribió en el mensaje
news:1165946376.123250.168340@79g2000cws.googlegroups.com...
[quoted text, click to view]

Yes, this option solves your problem. Although you shouldn't have it (by the
way you've it configured).
But if it works...

Josep.


<WombatDeath@gmail.com> escribió en el mensaje
news:1166028253.819201.281180@80g2000cwy.googlegroups.com...
[quoted text, click to view]