replication triggers

Hi all:
Cannot insert duplicate key row in object 'MSmerge_tombstone' with unique
index 'uc1MSmerge_tombstone'.
The statement has been terminated.
that is the error i got when i try to delet a record from table which has
merge replication on.
i had a check that this error actually is from the trigger generated by
replication..
so any helps will be appreciated.
Thanks
Nick
"nick" schrieb:
> Hi all:
> Cannot insert duplicate key row in object 'MSmerge_tombstone' with unique
> index 'uc1MSmerge_tombstone'.
> The statement has been terminated.
> that is the error i got when i try to delet a record from table which has
> merge replication on.
> i had a check that this error actually is from the trigger generated by
> replication..
> so any helps will be appreciated.
> Thanks
> Nick
Run the merge agent and try again ...

Replication row Commit Size

Is there a way to get replication to commit records in batches instead of all at once? I am in a 24/7 shop and some of my updates end up being thousands of rows and it locks the subscriber table for a few minutes sometimes. If I could get it to commit say every 1000 rows it might give me some relief in this area..

Or am I thinking about this wrong? If this is possible, would it help at all...

I

transactional replication adheres to the ACID properties, so if you apply 10,000 commands in one trasaction at the publisher, the distribution agent will apply the same commands in one transaction at the subscriber.

You have a couple options:

1. commit your commands at the publisher in smaller batches. That means if your update statement will affect 100k rows, break it up by updating 1,000 at a time until all 100k are completed.

2. You can use the logreader agent parameter -MaxCmdsInTran, which will break the ACID properties, but allow you to do what you want to do. This has other performance impact, but if you're committing thousands and thousands (or millions) of rows in a single transaction, this can offer some relief. You can find more information about this parameter in Books Online.

I'd recommend #1 before #2.

|||

Thanks for that response... it was what I was expecting to hear but just wanted to check. My servers typically only get updated once a day with major updates and the updates can happen over time as they are not mission critical. The servers are only content related so as long as they get updated they are happy...

Thannks again for the answer.

Replication problem(integrity violation) - Cannot Sync up emulator -HELP!

Can somebody help please - i keep getting this erro when trying to sycn
up my emulator to my Merged Replication DB.
"The row update or insert cannot be reapplied due to an integrity
violation. [,,,,,]"
Anybody know what this problem could be? I have recently dropped an
recreated a lot of my tables and changed some data types but did not
think it would effect me this badly.
I have also disabled and re-enabled my merge replication db many times.
I am sure all my connection settings are correct and the problem
appears to be deeper than that.
Recently i have changed the constraint on all of my tables to "Not to
enforce relationships on insert / update". It seems like this is what
the emulator is trying to do though?
Suggestions GREATLY appreciated!!!!
Thanks,
Steve
When you disable these constraints it means they will be fired twice.
The first time do to the originating action, the second time due to the
replicated command. This is probably not what you want unless you do not
have cascading updates and deletes on your subscriber.
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
"steroche" <steroche@.gmail.com> wrote in message
news:1125268893.110010.148790@.g44g2000cwa.googlegr oups.com...
> Can somebody help please - i keep getting this erro when trying to sycn
> up my emulator to my Merged Replication DB.
>
> "The row update or insert cannot be reapplied due to an integrity
> violation. [,,,,,]"
> Anybody know what this problem could be? I have recently dropped an
> recreated a lot of my tables and changed some data types but did not
> think it would effect me this badly.
> I have also disabled and re-enabled my merge replication db many times.
> I am sure all my connection settings are correct and the problem
> appears to be deeper than that.
> Recently i have changed the constraint on all of my tables to "Not to
> enforce relationships on insert / update". It seems like this is what
> the emulator is trying to do though?
> Suggestions GREATLY appreciated!!!!
> Thanks,
> Steve
>

Replication Message

Does anyone know what causes this message?
The row was inserted at 'CVTDEESQL005.ZenithSQL_L_060104' but could not be
inserted at 'ICK24BQZ0J.Zenith'. Procedure or function sp_MSsetrowmetadata
has too many arguments specified.
Our conflict log seems to be full of them
Does this apply?
http://support.microsoft.com/kb/319258/en-us
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
"Spike" <Spike@.discussions.microsoft.com> wrote in message
news:582616D9-62FB-4E73-A83F-01B3C835BBB6@.microsoft.com...
> Does anyone know what causes this message?
> The row was inserted at 'CVTDEESQL005.ZenithSQL_L_060104' but could not be
> inserted at 'ICK24BQZ0J.Zenith'. Procedure or function sp_MSsetrowmetadata
> has too many arguments specified.
> Our conflict log seems to be full of them
>
|||Hi Hilary, I don't think so as we do have service pack 3 applied. However,
it seems to be tied up with a new subscription database that we issued to the
users.
My main concern is to not lose any of changes that have been stored as
conflicts.
kind regards
Spike
"Hilary Cotter" wrote:

> Does this apply?
> http://support.microsoft.com/kb/319258/en-us
> --
> 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
>
> "Spike" <Spike@.discussions.microsoft.com> wrote in message
> news:582616D9-62FB-4E73-A83F-01B3C835BBB6@.microsoft.com...
>
>
|||Spike,
Check your merge agents in the replication monitor, you may see errors
related to space in the database primary tables. We started coming up with
this error over a year ago and after fighting with MS for a long time they
came back that is was a bug in the merger replication. If you view the
replication conflicts for your published database you will probably find a
lot of them. You should be able to resolve them by either keeping the winning
change or resolving, which ever columb has data in it (the other side should
read somthing about the data was changed at both locations, the update
won/lost.. (sorry can't remember the exact verbage). This should add any lost
data back to your database.
I am not sure what SP (if any) that microsoft added this fix to, they sent
us 2 patches to resolve the issue.
Check your database sizes and make sure they are not approaching the limits.
You may need to allocate more space for the primary tables.
Hope this helps you out.
Gary
"Spike" wrote:
[vbcol=seagreen]
> Hi Hilary, I don't think so as we do have service pack 3 applied. However,
> it seems to be tied up with a new subscription database that we issued to the
> users.
> My main concern is to not lose any of changes that have been stored as
> conflicts.
> kind regards
> Spike
> "Hilary Cotter" wrote: