Broken merge. Need help.

Hi,
Seems I found how to brake merge replication.
Actually I reproduced this situation on my test env. after we found it on
production.
OK we have SQL2K EE SP3a on W2k AE SP4.
Suppose You create a table with few fields of different type
(field1,field2,field3.etc.. rowguid)
Then you publish it for merge replication an push the subscription to
subscriber (with initialization).
Everything works fine.
Then suppose you need to ALTER one of columns (let's say field2) in that
table (char(12 ->char(20))
In merge (or whatever) you have to do sp_repldropcolumn then
sp_repladdcolumn and restore data of that column on publisher.
All changes are done and synchronized with the subscriber. Everything still
works.
Then you create a new merge publication including the same table and push it
to another subscriber (with initialization).
After we found that changes are not correctly transferred between two
subscribers. All data is still correct at the publisher but at the
subscribers some fields are different.
Does anyone know about this? Or any suggestions how to resolve this problem?
Thank You
Darius T.
Hi Darius,
Try looking at the .sch file created by the publication. It is usually
located at: ...\MSSQL\REPLDATA\name_of_publication. I have dealt with cases
that the snapshot file for the creation of the table was not correctly
created. You can manually modify this file to create the correct table with
the correct columns. When the initialization takes place, it will take this
file and apply it tio the subscribers. Hope this helps!
-Jose Molina
"Darius T." <dta@.takas.lt> wrote in message
news:%23s$CB3Z$EHA.1452@.TK2MSFTNGP11.phx.gbl...
> Hi,
> Seems I found how to brake merge replication.
> Actually I reproduced this situation on my test env. after we found it on
> production.
> OK we have SQL2K EE SP3a on W2k AE SP4.
> Suppose You create a table with few fields of different type
> (field1,field2,field3.etc.. rowguid)
> Then you publish it for merge replication an push the subscription to
> subscriber (with initialization).
> Everything works fine.
> Then suppose you need to ALTER one of columns (let's say field2) in that
> table (char(12 ->char(20))
> In merge (or whatever) you have to do sp_repldropcolumn then
> sp_repladdcolumn and restore data of that column on publisher.
> All changes are done and synchronized with the subscriber. Everything
> still works.
> Then you create a new merge publication including the same table and push
> it to another subscriber (with initialization).
> After we found that changes are not correctly transferred between two
> subscribers. All data is still correct at the publisher but at the
> subscribers some fields are different.
> Does anyone know about this? Or any suggestions how to resolve this
> problem?
> Thank You
> Darius T.
>
>
|||> After we found that changes are not correctly transferred between two
> subscribers. All data is still correct at the publisher but at the
> subscribers some fields are different.
Could you be more specific about this situation ?
What do you mean with "some fields are different." ?
Are you making inserts/updates only on publisher ?
Is replication working properly (replicating data to both subscribers) if
you skip step 2 (alter of the column) ?
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"Darius T." <dta@.takas.lt> wrote in message
news:%23s$CB3Z$EHA.1452@.TK2MSFTNGP11.phx.gbl...
> Hi,
> Seems I found how to brake merge replication.
> Actually I reproduced this situation on my test env. after we found it on
> production.
> OK we have SQL2K EE SP3a on W2k AE SP4.
> Suppose You create a table with few fields of different type
> (field1,field2,field3.etc.. rowguid)
> Then you publish it for merge replication an push the subscription to
> subscriber (with initialization).
> Everything works fine.
> Then suppose you need to ALTER one of columns (let's say field2) in that
> table (char(12 ->char(20))
> In merge (or whatever) you have to do sp_repldropcolumn then
> sp_repladdcolumn and restore data of that column on publisher.
> All changes are done and synchronized with the subscriber. Everything
still
> works.
> Then you create a new merge publication including the same table and push
it
> to another subscriber (with initialization).
> After we found that changes are not correctly transferred between two
> subscribers. All data is still correct at the publisher but at the
> subscribers some fields are different.
> Does anyone know about this? Or any suggestions how to resolve this
problem?
> Thank You
> Darius T.
>
>
|||"Some field are differnet" means that if you make update on a record at
publisher and run merge agents to both subscribers You find that all data is
correct only at subscriber 2, but at subscriber 1 data in some fiels in not
updated correctly. (INSERT,DELETE statements work properly).
The same things happening when you make an update on subscriber 2. Data is
merged correctly with publisher but not with subscriber 1.
I could post a step by step script here to see how it happens (if you are
interested)
Darius
P.S. gal galime susirayti ir lietuvikai jei k.
"Kestutis Adomavicius" <kicker.lt@.nospaamm_tut.by> wrote in message
news:%232dPB%23s$EHA.2444@.TK2MSFTNGP10.phx.gbl...
> Could you be more specific about this situation ?
> What do you mean with "some fields are different." ?
> Are you making inserts/updates only on publisher ?
> Is replication working properly (replicating data to both subscribers) if
> you skip step 2 (alter of the column) ?
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
>
> "Darius T." <dta@.takas.lt> wrote in message
> news:%23s$CB3Z$EHA.1452@.TK2MSFTNGP11.phx.gbl...
> still
> it
> problem?
>
|||Thanks, Jose,
I've checked those .sch scripts. Didn't find any problem.
Darius
"Jose Molina" <rcmaniac23@.yahoo.com> wrote in message
news:OCHeF8k$EHA.3840@.tk2msftngp13.phx.gbl...
> Hi Darius,
> Try looking at the .sch file created by the publication. It is usually
> located at: ...\MSSQL\REPLDATA\name_of_publication. I have dealt with
> cases that the snapshot file for the creation of the table was not
> correctly created. You can manually modify this file to create the
> correct table with the correct columns. When the initialization takes
> place, it will take this file and apply it tio the subscribers. Hope this
> helps!
> -Jose Molina
>
> "Darius T." <dta@.takas.lt> wrote in message
> news:%23s$CB3Z$EHA.1452@.TK2MSFTNGP11.phx.gbl...
>