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: