Monday, March 12, 2012

Merge Replication Issue. Update not happening

Hi,
We have set up merge replication between a few boxes. I make changes on one
box, replicate, and check the tables on the other box. The inserts are being
replicated, and some updates.
It appears that the updates made out of a stored proc are not being
replicated. I can manually update the table, and it will be replicated. But
when updated from the stored proc, it is not coming accrossed.
Any ideas?
Steve
More info.
sp3, no conflicts reported, after further testing, it seems one column on
one table never gets updated. Other columns that didn't, did at other times.
It is of type bit. I can manually update it and replicate, but can't have
the stored procedure update it and replicate.
"SteveInBeloit" wrote:

> Hi,
> We have set up merge replication between a few boxes. I make changes on one
> box, replicate, and check the tables on the other box. The inserts are being
> replicated, and some updates.
> It appears that the updates made out of a stored proc are not being
> replicated. I can manually update the table, and it will be replicated. But
> when updated from the stored proc, it is not coming accrossed.
> Any ideas?
> Steve
>
|||Just went to sp4, that did not help. When I do a "validate" after the
replicate, the checksum for that table fails.
"SteveInBeloit" wrote:
[vbcol=seagreen]
> More info.
> sp3, no conflicts reported, after further testing, it seems one column on
> one table never gets updated. Other columns that didn't, did at other times.
> It is of type bit. I can manually update it and replicate, but can't have
> the stored procedure update it and replicate.
>
> "SteveInBeloit" wrote:
|||More info - it is a Pull initiated at the subscriber. If I run the same
application on the Publisher, and make the updates, then replicate, the
change gets to the subscriber, just not the other way around.
"SteveInBeloit" wrote:
[vbcol=seagreen]
> Just went to sp4, that did not help. When I do a "validate" after the
> replicate, the checksum for that table fails.
> "SteveInBeloit" wrote:
|||Solved:
It was actually a delete and an insert, not an update. A record had been
written to a ##TempTable. Processing was done on that record. Then the GUID
key of that row was used to delete the row out of the real table, then and
INSERT from the temp to the real table to put it back. On that insert, I
used the same GUID key instead of letting the table NEWID get a new one. It
confused replication, having known there was a DELETE and and INSERT, but the
GUIDs the same.
"SteveInBeloit" wrote:
[vbcol=seagreen]
> More info - it is a Pull initiated at the subscriber. If I run the same
> application on the Publisher, and make the updates, then replicate, the
> change gets to the subscriber, just not the other way around.
> "SteveInBeloit" wrote:

No comments:

Post a Comment