Merge filter inconsistant - MS Replication Problem.zip (1/1)

begin 644 MS Replication Problem.zip
M4$L#!!0````(`$""LC#YB*C2-`,``$L2```J````35,@.4F5P;&EC871I;VX@.
M4')O8FQE;2]C<F5A=&5?=&5S=%]L;V,N<W%LO5=-;]LP#+T'R'_0K4D1]&O#
M,`S809'H5*LL9Y+<I"<A!89=!NRP_7^,<F+9<CYD9TU9H$`2/_&1(A_IV^NO
M_V77M^/1[37AF[^;U\V?'U^(!6.=+!CI;]LS4IY.FS^#::`6"*>6SJF!0&4\
M^OE[//)_Y8%OW\(S9L!N7G]A^*M"/SEA(4\%'=D;9P#CETV@.-WQ>W#2\)N,1
M>EP)MR@.%CVF42GPO07!05F0"--'%RC_%"DE488DJI20<,EI*_``KP2?3676<
M7?8YSIL_8U93Z"((GLY$3N7D_L/L;EI_V6"X>#;`.CCV2/7DXY1$%OFQ+X[%
MKBK,YRYF%^,6MP#EM%$Q\B0NY.:*7.WR0M?[0=8Q/K1";/GU&%/./>D&FL`L
M-7=S6#ANVWZP%JS(@.;2MP?CG,R&=QX8$]?`#B@._RXY\?ZL=H!MTK.Y+[!F-+
MZXK,R=S20##!S>"C73=][YB:A=I=,V7VV2G\WSXLE'(48O>8NU"D+%_&>4V1
MSZS8)W_8:\!(U(2\&':!VLAGUQ6,1'-+`]+1DKL5ZDX-3&*0&^BXBA/<EKKX
M-K106*&,U50H2Y9/KE'&I<;,Z1?R!"^$3'8!3\>CZ65&!69'6(Q5DB%V^5'1
M\-J."G^+'*R,[O_\4=%O\GB+Y3C0:&,3XP*/TPZO.VN75$JNUAC]4`RF#S<.
MXVAK[@.=N][.'`]PRH:3S6D_YMX!+8'P.<K"/4<4GJMUCZ"*W^YC[DQC#5.PL
MX2?3OH:`(M)JNTM>(F^X-C!EV2`U@.K5U>^.N)R8:7:G1(%C?T=#$4SB]Q'!*
M64\'..(I^CE+'J-4T>JU[4[)?3/A0!/S[),+N\]M6\PI+L/R4&W\65KZ81
M01/*5P&P'/&-1P=@.2BG:&)6W,)_N8E`'XUO1FN;GPY48Q53YT(6,MKQ4=U'S
MM+?*]\%TM[P^F+B'D]U5Y<'+2SH/L6)R)2-0C\Z'-7L<XJ?*-9,FV\OU\9>F
M]U*E*OP*=.[FW-GF=@.V\M\N%1FZ+VGA$I<6>.ZX$V\OEO.TF"VZ<A@.PT*'Q9
MJ==(DA4:!#+PGEM+Y#\+PY^GK>0&J.)U@.&&3_"L_[]/8C^`U!+`P04````
M"`!`@.K(P48FJY#D#``!-$@.``*@.```$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO
M8W)E871E7W1E<W1?<F5P+G-Q;+U738_;(!"]1\I_X+;)*MJO5JNJ4@.\$<)8-
MQB[@.3?:$LE+52Z4>VO^O#DZ,P?G`3C<[D2(YX3%O!N;-^/;ZVW_9]>UX='N-
MZ.;OYFWSY\=79)@.V5K$2];?M'BE/I\WM013#AB&*#9YCS3R5\>CG[_'(?:J#
MO[Z';\B!V;S]@.@.2L"K6TW+`\%79D[YP#R(!H0[VA\^*FY349C\#CBMM%Q6E,
MHY+\>\4X9=+PC#.%5+%RJT@.AD"P,DI40B+(,5P(>V(K3R716; V?*/MLY<WO,
M&@.I=!(+="<^QF-Q_FMU-FQ];#.4OFI$.CCQA-?D\19%%?LRK);&K&O.EB]G%
MN,4MF+1*RQAY$N=S<X6N=GG!Z_T@.FQ@.?@.A`#OPZCJ[DCW4(3F %)1.V<+2TWH
M!^Z"X3E#H;48MS[CPCJL3U`//TS207[<^J%^M"*L>V1'<M]B3&5LD5F1&^P)
M)KAI6-IUT_>,L5[(W3%C8EZLA.]P,W^5HQ"[V]SY2TKR,LYKBGQF^#[YPUX]
M1H`FY,6P`U1:O-BN8"2*6V@.F+*ZH78'N-,`D!K@.Q%=_B!+=2%<]#+PHII#8*
M<VE0N;2M,I8*,J=>T9*](C39!3P=CZ9-LW@./B6Y;!62'&XA5H"%V^5;1\MJV
M"G>*E!D1G?_YK?YW$6R[&G$6(3[0*V4Q:..PNO5$JNUA #]4`RD#V8.;7'0
M]SVW^]G#`6X9E\(ZK<?TV>,2&)>#G)FGZ,8G;KO#X$5N]C'W)S&:R-A9PD^F
M(`F"84`:97;)2^0-Q@.8B#1FD1FQM[%Z[ZXF)6E>J-7#2MS6T\116E1!.Q8*0
M$G[.4>1SE#)6O;;(8]6+BOURV@.<BX-HG&F:7U[Z&EQ^2W5.B\5U<^1H:$32A
M?#4`KB.\\R@./3"E%B)%Y@.'F\BT$=C"M%H]N_#]_$**;:ARI$-.6EJ@.OKY=XH
MWP?3G?+Z8.(:3E97G0<G+^D\Q(I)I8A`/2J?K<G3$#]UKHG0V5ZNC[\T?90J
MU>'7H',GY\XTMRO@.O5G.%W(H:N,1%@.9J[K@.2;`^7TM!-YMW`ZHPI)N%EI1DC
M458HQH&!\QP,D=L@._'I]]/6\A30<3[#T,GZ$9_/_1Q#]!U!+`P04````"``2
MB+(P!=H#;H8!``!C`P``+````$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO9D=E
M=$-U<G)E;G15<V5R240N<W%LI5)-3\,P##VO4O^#;TW'/L2-RPZE2T?02$?2
M2B`A55V;;4&C14DJX-^3M@.,);1I"^)9G/]O/>=/A[%\QG+K.=`B;A3!AHY2H
M3*J%(G/X0_0]?IMT/MH>KB,W(-ZE-AJ0%GM1&+"KJ?H%](>NU\\6T.`Z@.\';
M3B@.!LH09]'`F2^0=B?!\R*NR8PSBZUL<)BL6KS!+'I$L1^`1S8M\GZNHJ0H C
MZ\K6S^#2=YU2U:^P.:#'QW&=;0WMOAPG<)_&"9YG9(YI0B*"& 4!,^U1`.<EH
MNESR%K.,1=RR0H:#!$.4TC`A%C\^/K([,)RDC'(H=KE"5Q8(>$N^Q@.M"O[*@.
MF[4V2E9;Q%..6<9I<(>1/T+A3<`(G>,'Y#UY(_B1]2\N;<42TY\D'\9PEN;;
M)3#MU)\3'T4GU+=@.KWX\;JQ(4/5>0"5$J2$O"J$UF!K,3NKON]LY*J^,=80H
M&B/`_D2YKB<G?L,R@.S189>W[:[O.UD9H`])T#CT8JBMD>#4YV0M9QVCP#O;I
M>WT"4$L#!!0````(`!:'LC!AZP$74@.8``%P9```I````35,@.4 F5P;&EC871I
M;VX@.4')O8FQE;2]S=6)?;&]C86Q?=&5S="YS<6SM&-MRTT;TF<SD'_;-<1J;
M))0.9$C)34/3<>S4=DH[P&A6TI$CD':%=F7PW_><75T=QUSB\H0>;.?<[^<H
MCW>/'_3L/M[>>OQ31O5L3@.:[R&3*5.XI/XM2'4FAV-<_F[)C,U+0&Y9`-@..6
MYG'<<NK'N-'KF7"FD9@.Q?0OW&6/]-0\[@.UDDCMC$X)B6S`.6Y8)QS2:6Q8/L
M"$TTCPD5:K&\`B`@.%A[@.UVVD6!0R/@..A&?Y&(&)5Z@.9H$1=2+!*9*X/>WLH5
ML#=39S)U!Z/S=]M;KT;;6\@.,GR.E%=M1$(.OV2X+,YDPM5#2>X\`Q;:W'CWZ
M=`L9L"A@.Q\R"W2C8Z5Q-,DCCR.?DH-NJITZWBWSWBE_#V="7YEY)@.XH[QO:Q
M<]WI&AKX#'[IJPDZQ;R5_Y.V@.&$M8:_`*=1C,-<W9X/+R1_.>.*,_W;&P],K
MY^7+ERTZ-_#:0HJ\7*!G&DSNW\32Y_$[]EYZ;$UP$Q5X_<"3?8PRDBIFW14\
M`?+SBISIE6IZ9]S_D*<=BJ?SCW-^,W4:`M!]H]XEE2?XX192AO>(V9A9DX7P
M'VR4$=)L#4<$W]88-@.E":NRV#&Q+8!O@.AUC@.'V+6[_>WM\A&JI4,$CF'P&M4
M'SL)O-+%LCLZ5NXFQL-/&?6S.1GL%,?]RZPC8W^3<C87)VQLJN^:Q]NRA\<
MB)B;+RS#([9ZWAZ5+E0_OGEMUK-AU;XK=P9.B'4KXT%K86_]WE&5J:Y>I'8J
M5JNZ06#L<=,LDEFD%TBVW]\W#Y'@.V&QPYUHFJ,PG[@.!J9ZJ!V]JD,JPK)>":
M>QP#91;`=>7[:K_['1O%.B4C<PS@.1/X3)_UJIGK85UJK%'F44:8S+A3WC7';
M6XQ=..>#T['#3E#HY04[NQR>CO_=.?BMVT*.0>>9.)<!L,OAE %`39^"<3UL8
MC!IA`O!CCMOA1$$VA\R,>S'GF7_+LYTG^T:P`MW"'[.=4N!)[ 5"W)0Y7FR^3
MA(N@.(>YP_Z`6V*"@.;/2^%&)64UR<%>6+(7M7P(L4-N$7N,JQG+`&,O9FM5"D
MFC2*:DJ%<UC!J&DPL8]^:;EO`,-.DZHRB/JIB9B`GU.17E'(#W"8=):C1"(]
M<X#096D4]'J*OKBJ0W=P^*P5N0;7NH.&6'#L)+G2S)<BC&9T"9A3C(48E3@. 2
M'^@.L-LX9B+D2U,>8A@.A.D#T62`',6S!IEXEKF/M(T:Z>C_$7TMV@.((O-N+FG
METH_S,FD(4E=#4IWK#/F2BO/,U_F0N_L=N]>:5@..,,/Y`$NWVK"#@.@.<]$S"\
MEE]@.4D@.NF9/CJ=J\U'`2NH6819N/`EMFPES^`H<E@.8Q117,>TZV++P-K+\B=
MPJQV3KO6R4(0)F1X,Q@.@.\,QY=3DL<AI`&%%F;!'8;8)"FLZTV WW9M>H"-1X4
MND8WT^N;Z5[K-&W;AC@.0W(N!N`YHXFJ>:5=I2*TD@.N'1&84+-X8YQ"Y^"!W+
M&>(.[^`2'L4TBY81`K0"4RMW4"F^M17PXI@.V\`K4GO)#R9H @./D>%9'Z?5D*9
M7G=5=2!>?A*XC-#V2-0DH]=#9SP882K*I6=*R&3LQ!F/1V/VXG>VS_"[F0&"
M==E,8F/]E4?Z=:1OQS*.*:JV4;\Z;13KNZDSJ6@.FP4\"$HGOD+X/2KE^,?;)
M+U%!B^UB61KP6E;!$&+@.:NK#!K!-FH'&@.')-C8MO4DU@.)#1.&AZ7VI2+(Z:U
MR!$:QGQ6LAG)=6[HHJ$W]GYY#"R0(*DGH$EI-60:&V:O'.`$KD<YE4NQYFLM
MC3>='Y+4/$4;8&4[KNJN'V1566HV:JL,,YAJ1M1!?;"!SO#"'O^4O$@.O'4& &
M"=^%)WQ.JWB9_:C1B]/QZ?!\=#.<,J,N*TB6!!:RCDBC/>',?,V@.7&YXAPGX
MA)-6^[<_='O;/*T[REW[_ZW__S0/&J?4>A6-(UX5QX^;V/HZ:%FP"MM0LQ(?
M9O`Q!^$ORA/_UQ9P:;[4B`QB]&L.ZRA06X8_`6>:;]W<;U&@.8P&G(?5L!7A9
M,%47JK/=2_U=B"O@.N-E60"VUCA)P9>A:94M,;>3ADZ?/GS[?JS:R&U+<\`TH
MF=DTA3Q69BKR&(>(X*FZE1JIXJ`HE;=O5V?R[:0@.)F9\771#G ;8E$M`X75B7
M@.9+Q');TRC",)0]LF;8P]QX8RR]2W_A_K_\`4$L#!!0````(`&B)LC"\<,:V
M<P4``+XE```G````35,@.4F5P;&EC871I;VX@.4')O8FQE;2]415-47U)%4"!P
M=6(N<W%L[5E9;]M&$)[G`OT/>DL*U(:<.@.7Z4#2)';M&?00YF@.<W(&12DM7J
M8$G)COKCFWPSLSR6NSSBU($:"`0/[<Y][>SJP[\[M$,]>DYS&M`536F"KS%&
MEG1-0[P3/&,9#P&QQ'L!B!Y%\HMQ!I0"YEOZAE;RU:.9C"WQG<CX,5W(F^\ A
MO<<=`BH%W:"&?@.2Z"XP7_)[(&$LY$QX_XSZG!_0:LK_",Z"7^ 'J!D>\%6K%=
M^)E(-9:Q&!*KSBFTS3!O@.#/%3!EK"1P>>>#HD^E\Z4CRSH%56S^%)I%C9[]<
M99OXK#<06@.6N'Y.UJIMILV,$JBEP$F#$'KRS5KE[>([PK')P8 Z@.'N`30,WR]
ML'S#/'CL#3VC4SH!G5]!XR7>_/Q=GN>P[!F^?I%K-]>`(XQC<5Z1OF_F4UIC
M+(1<,\Q&EM_G1H\;\;W"<W1,`7D+C%C\?^V-%#\T_^H&/0!WEG8M<C&?>KQA
MGK]#:!#`C@.M`!!)EFH=SL4)!822\TA*-T-@.HD9D)_6-HA2+%R/AUV2A')+;D
MG)N(14=X3XT$37BI8,5BRP5F5?)`O,&2KH0*:S65L:2!5B@.1% (O?4UR!0[W)
M"B/,Q^(KMF`&^XCV*O/LI;%(65!S/5:6J6S#H#8J]VC?X/R%V:&192"R3')8
M]LJU\!N+EMTB*I6<<K-9?1Q#[B;+V)0T9Y;X/<@.]K-DR;*1R8Z(K,K!5J:Z$
MDOJ?_5W0TC5A%Z/'8KL#X"5B1[;A&^&2H#8<TD/ZKB1U)%',DG).A7D^!U*%
M&5_U2%KTYU7M?9X/H<4]L.IWN;HT8U7SI1JI:4ZMOOK[JZXOZN^V"CR1JCRD
MOR6N6(>UV',-:IFV>_1CGA\N;%&%U/L93CT&CTRIJ+UU-/HM-,KV#H7.R,3`
M(J\A37)H;'*LKC\1NDUB.Q*Y6](<#_+,)GGE%'V#)M'IW)**_)@.:79(US[
MN/HM/)MI_$"/Z2>YZRK[GWA?X>WV9I^RON\XL>H;V2>W8ZMFT9AXQ=-\K,LE
MM@.3'3RH9>;<\8CS?JO$,6I]`Z]=XGM,?TA_.!&8BODN$`\=K6M%FTS2YH+=X
MLZ].\7TL^MA>VVSYH]SBO`ZMC-6USJI'-EO^%!3<>.^ZZ\AZC)"F(E^7_8:-
M\SGZ5"EE\$^1'8>(),8XQ/,TQTAI(=4]-+7HEN9D=X;:,=3!7Z$2Z=K?A9N]
MWFFGE77<7?9*<]+>O^@.'>8\YDYC0'`_1\67^*7C8W9QVM8'P&%IQ%8)69.G.
M.ZDXQW0QRI+Z9.1YCA+N8`):.!KU$1O]FNN`CG!E:Z7M6UV94['`3<EC5>[:
M%0XEF\K[B%`Z@.VS?[6(JS:6)P"GY^N?"3FZ?IUY<BB_*]FJ/L(&I&;SV,Y6Y
MX:G=2-:M-_%6V2>867OLQ#Z;@.(;*M9+YZLI?].A%_V&OXW[KU^V&]"2'^UO=
M@.TU,[`;X'>?]1RS1%I9HN;LRCB6.\4#R*)&*FHI&;-\TUZ2IPG[Y^O,6U2!`
M77@.%F<[OM?;X.6WKSK;NM$77MNY\C77G`I"_`?Y$<,_NN?;4< =O6G\VM/ZSO
M+2!XY[&2W.^1[@.@.>"M0T]W,5JCAGUQG.MK%@.WIK3=N81883/6XO3+;9W9NT]
MW,4YV[;Z;:O?U?]VL]X[[,:=N?N5L<1<.;&=D4=Z8D]IH"^OYKIQM'_I6KJ
M]:6JYK9KZ[?*_GE9L3GUT/<OYUTJ8MLY6K6.E>.Q9\5CE_I:AK^/ZEI_RE7F
M[)[/'TF'6,56KD=R[OL<<`=X!DY'F7'@.TW_];]>6SN56WY,6--K[HTN/MN]H
M%^.ZWSZ6T_=#C"G.I8>O']Z5ABO_Q/PG%,C_M\6_1E]O-/G/+;I$DHVYZ7%D
M2[L),?014$L#!!0````(`""2LC!_O5PM)`0``/H*```M````35,@.4F5P;&EC
M871I;VX@.4')O8FQE;2]415-47U)%4%]A=61I=%]D=&PN='ATI5;;;MPX#'V>
M!?8?BKS3("7JPGF31*F;12[%Q$7[Y@.\I\N]+9S*-9YIM@.M3P@.R79$@.\/SZ&O
MRE==M,\WR^>OUWJUN_IV?7KZN?(TZG?S86GW=V/1>1U^OYZWPX=Y*0_]82FW
M-AK7=S?+7+XO1?\]SJQ[W?;YGZ6==BZ?;^>7T4.[V[XP#K;?32^V,!_FXQ'S
MEZ7=S>UT_+Q\.>A2^^?SB6[[/$T\7+?C7O/]<OABGWWMQX4;V_KV7C>#?GC:
MY.^_?I2,5;1VT,056&N`TEV"&&AP#P%#P<?=C]3KZ*4VJ!+7UPK;:R-"[:FK
M.#=2<(\[9.]]VCE$!@.Q`^1.FO<M[+Y.+>+QV=EU=/=_VI@.-,@./X3XO[IWNU(
M)`/:32^3-B=`"'XS9]^_')4^D4W::32Y=#K*\#$F7T-OT(>+P,6BS]0&)$%R
MSF=R/AB^Z-1Q"+88*@.%C(Y!B88@.BY6*Y:*R&3R2(VYU!V!UC0WHU7OQ]O''/
M>1+V+_%:9FMG">`E=&#?&;*G`=E)$C%D&I+%6V2$-LA";5V`F3.4%LBP%<V2
M(U.1E0\70UX/M4C<63`7+-`:%.9+`/9-/)N+ET"/>_NWB(E[CU..&Z`2HD9M
M"3(V!%ZKKQ;+?18A%2E:/!G03HT\H\`8I1DQM4+A,"`T';T%IIK:X\X[8<>O
ME]/[RBU]I-SB'O.$N$%5UT+QOL!`+L"Y&'-M1=78QY6<'N***C,%8<O<L$IC
MR0.J&Q5&356-NV2J...P1$W/\`U07!?A.5&$?W$2(&ZZLBHA]@.S3$BG(85X6R
M2:0VE:2-U&5#Y=4"=V82P5G9,JVH5!.DZ"G&6$OKY:>(-B9!M/=ASW'*^"S=
M2WQ^+5_:E.=O1?<F:R%,YFPO^`H7'!4+Y,S!1!?,YU!-4AI"0NE$K1L^<=V<
M,J&I+*B)KCC39F5P%$I(I9-/<C1!)W_`VL=J,>W)37Z+JI>`-:RJJ<YJ,;`S
MNW8,U=PBL:98>!BJP,/(-%TAJ3DDQVR23`H%K9*ID/?:GUFC#Z/Z.%>(4]H:
MNOAB&G$"KI@.KL!48E!H5FK9LP3,:6D.E/49A,GNQ!...]TZ!Q;&G@.(<.ZF?*(
M6ZXVASK<LYM<.,GZ/?@.^REK<$T]\U@.#8@."5ON]D3L,D&A!N#VAA)J/LG7W39
MG$:JAVR=&>R;##5FBZWXH1J%[#('<1Q].$9MP;C_;P!^)6B[?D+J\0R4`8V_
M`K5N_290AU.4#5#/(R1-':15/?YYU#X4>JS&4"+34WH"&EA\%/!])3(5Z]'2
M&I2<15E=J<%$YSQ)P,O.O'M=*!C/3=O7D:KIW'*)EDLU(Y9H,A^B/J41K1/K
M&DD?K?2N@./9C9"Z(%D0<"*3-GFFX6OQSSSW)GX`V_?/70O+@.TEG*:4VY"Y<I
M/Z^M4S]W&T-\->5,9X[P'U!+`P04````"`"ZD;(PDY9":N$%``!J%```*P``
M`$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215!?=VE?87-G;BYT>'2]
MF,M2&\D2AM=,Q'D'A?;547FIJDSMZHI]S(@.)$'&&L^%!)OSND]5"-C;@.@.3&X
M0XNN5BN[Z^///S/9_N_C7;X^W]^=WWQLV[.M+;^>K5^LB_7L<'EW<]VOGKBR
M__UTI?3SN\.UK=;K5Y<7_:[.VP_Y^M/=X?;!XOJ0'ZS:3;]KAU.4OF_'*./J
M^G#7]A?WRPM;]3_KAP>/J!?7XQAG?OG[93N&61?]ZORX6B.L2[OS/[_]E4ME
MS``NDF?'TMEI@.>H\)8FC!PI9/Y_]U7J,RI"<U%8=YP(N^Y$=\]"1>FD\XN<S
MQDC`]N:E-D#:V//^>_EAOVF7?,OCNT9>H\.O/-I`WX7>,=I\9#\>IQMKYJD
MXXW;V]M;>^!Z>GY0/5Z=Q]9CD#42.Q\<K)%\W`$O/OC[2&=@.*+2)#U35C9R\
MXU2RRQBZ\S5@.PLRY2S44*(&5HCKJ$T7*Q8G6ZK*(-FZ82S!BF((0G&W_O/U_
MCH%7%'G?PH%.4#G=0.\([4]+/@.5Q>TAAN.-VWL2WZ,X$F`'<>.-P/P\>6T+
MGA\#2SL?%MO20V`8!D)-XFRG)H4XU!6N!FP`55$6U&[`3!ZCFR1<T5@.<M\PN
M]Q%=Z:DW11PIX.<SB$3\QL`F+8=A;H!EQ[A(/&W@.!<".R(T"^0W$7;`(<=%X
MTLQSG-`O";X1EJ#7R`-="J8N#@.F=^CCLS0:I4")/9)PZ5""V-QXCF[!\*2YS
M&"[4-GH-#"75R2E8FKUGCF%8Y&URS*<E4'J(`EO61*.[(&QV$U-U`HP.FT21
M2AA*,Q34<A(TR00T0V*0X4IKR27SEQACR;7GB8(YQK>6S$0!& R^[H#N,"_,O
MRS'36%A.TKD'1JF/C(U<+Z8'KF#),\HPXTU9,41,K4Q3ZJ/FWIL]J`?'PYL?
MQ>$=M&KG,+!DDY@.JQ,1O"PQ,.#/'#!C8)RPJK\BQ8P"9*38#6)X:@.2_9<^1#
MCF!Z'NB.:$GQR]_C&8CL'^3Y"G%0+"6GZ'*=-:M6RRST)L)"7<RP:PS!(&8=
MH0ZKA69BEJ?,8C\(8`K-350BPZR%2!&GLW^X.;]6RPW;4<U_'/+'_>93WI_G
MJ\O+'T'[_KAW=A\=KAM`F`R(OD!\:0*F)U"07QB_2<!HVU!,M O<\;*-*YMG-
MH*2J-8<4,PPQ%(%'!C'%>6C14$0S>9^:%7UN9O9`U/K[>[;N`)=$)SF\3$\_
ME8#>+R2GYZW`?*Z&@.*Q<)>[FRLT:I`'!J>3>H.4A*;_8L9`IH ;RY=M+,$"L]
MO+8U3*\V[Z>T\]B+@.'P1,?..04T[(9H7B17R;-6=K"<4G_VL8\(0E,U&1YT2
MFRAP%#=*LCX1C),OOT([8=:QUVG'6,+J-A;`*GE:%$\!?OSMTWH*NP"+_[9I
MZI!&Q6).G:>-%SN3@.NR*[SQ&$!W*!E&Q-VN0O)E/:`&:W+*NP0@.J5I[D!)
MWQUB\#N2Q=,OJX!I![`H?P/,=&:N3=8H^(Y&`H>3'"T?:ZQ6\UH;XM>V?%36
M0D[ZY(I97(EBF\DT6HL*=A@.P4M4W;QG,O$%GCTBX\["P?T4%/'O6BZR1_%H&
M5A0%1FQU-@.-D?2&+U28;W<!5TJXP&J?9(;XP`3&8,Z%-A*U^DB3SO=KE/E^T
M3;NIGWZTZR>/DQ>I`]EX<^XXFX&4WJ"./95&B@.!AQ&Q3&)DM2\LV7O3JJA6N
MG-"&V9)>T5._:QJ964!:\%6J."+`-4+8(<W9`^F?6I_'#3=Q&P02')&8%EC8
M"6-S-0RM8O.ZU?D7S_?OS4EFO4?_"KNY1P`.=8K.9C2KX`K_Q.GQ\)](,U9S
M#HU6W%E!G"9#45,"2=;^<9JS;,2&'(*-_,$0L;763K/:O<V#Y`#F06URBJK^
MK3G98#(W<!S^=:'T2DZX_OL`-T`[`K.J!^7]V59:OF^'&&)5"M$:F^+-9J59
M.V2_&MD2K&GF&.*+6VE&AK?6DY]N[,/:#M&<!=(KYY$UP)Q'S,/,>>)R`G#J
M`<2AS#_#%!LLITGC>8B/FO"_`5!+`P04````"`#FA;(P!^F*K+<#``!H"P``
M+0```$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215!?=V]R:U]I=&5M
M+G1X=*V6VU(C.0R&KWNK]AVHW*O*LF5;FCOY1+'+!"H)S'+5#T+Q[BL3YL#`
M+%F&KE1:MI5.?_U+OWOSY6(]O[EHFV5SN/X:V=SCN5W<[GM=O\X=[M8ZP_.^
M77?[[7%PT'^."3/8WY29]3B^WK6U]/.U'6PP@.W%QN<[)KY>9<=^V8\(,?D[8
M[VI_B@.XWA_5JK)>?#WK,WUOPN*3U<+MN[?LXM-NLGZ^/.>-P<9R\W!_6SU=/
M_[3;7]ZNWZDO]_URU9NV?MG]_7W.\OONZ=ZO=U=_S>O\^<>]YU%)2@.#N90!Y
M92B)/3@.-H[4D:,?#<L_!E5`5(:;4@.0HWD$$)D$A<X=Y8_<."GE)8-G=W/DR.
M+84S.^;#HINS8RAY0;>@."(-+X/#,N4^/GR6EQ3OGYW1PSZ8W9T_'9F;0S/`_
M9,PGMSOT9LMNF1\[-H]L?53MO8&C'H&&JZ!I.,!6+<;ABP9C(Q>R0ZK`*0F0
M=`_:.=D/.%!B06[RL+!WF/Z;+<MWMOP*&[[&5J^VMWUW^,8FI[&)[ZWT[(`Q
M-B!2#QP*@.<>H,6O'D.VF[WV5+,P5[.2!4#N4$"OTD)%B+*V7]+!(8N+?8S/=
MZ$VV$W5KW80@.S,"U52`M".J&&N60D7MI--)D$R>Q^F!LQ1;#8-"&`3)*'$E2
MJ85^9/.GU.0O=&,(^"%L'2L&,I7'4&-SI8!2'!!K&[U&PI+K.]C>K=M'LH6F
MF7VI$'TG*S8>4%K+D%/`E%+1VM78S%2\$U\AT;0<)@.'QI0%*L[9+/?7.#XL3
MB?+(YMYD$Y@.<K]7D2[9W>HG*B'4@.`M5N)D%D@.M2(UG[:6#A9:\G)7N*%Z0TO
M^5:3Z07;$S+ZYVSNW5Z2?//3#("CM1J9-8*H%8PTAZP1;8=HQE91710T+TED
MNIFS0*E-0%4H.VW9U?ZP1/'B3ZS)#]1-]^?;X_)SMDA#D:W+'#:3P30`=KF9
MH5`+J!A"LYN^+Z).G;F-9K5^&X9EK17`O)1B&GU(Y,F&@.K_-AO^7[9?[&T>2
M8'46^O3)K*:@.5&-@.ED;-:XFS)K&XCF7V&_L^MW@.%];8A9F)[,-RJ$4XO24BO
ML_$SMJ-IO&!;?L*(8*PG262./KJ:;13S-:"F9#TS$MCVUIMX/W+TTQ+[...,(
M##6S56GWPVRC=;#=HFCD7$TKLXV<K'4,`^5-B7C6V8D2O=,2.Q-&(0=N6%>1
M3$OTH\`HV;8Q-+]TQ=@.B#V>:31A[QS)=;)OV84"+&)(.MA:T\D.RUZW7)9*7
M;.A>9XL?5'[_`E!+`0(4"Q0````(`$""LC#YB*C2-`,``$L2```J````````
M``$`(`````````!-4R!297!L:6-A=&EO;B!0<F]B;&5M+V-R96%T95]T97-T
M7VQO8RYS<6Q02P$"%`L4````"`!`@.K(P48FJY#D#``!-$@.``*@.`````````!
M`"````!\`P``35,@.4F5P;&EC871I;VX@.4')O8FQE;2]C<F5A=&5?=&5S=%]R
M97`N<W%L4$L!`A0+%`````@.`$HBR,`7:`VZ&`0``8P,``"P`` ````````0`@.
M````_08``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO9D=E=$-U<G)E;G15<V5R
M240N<W%L4$L!`A0+%`````@.`%H>R,&'K`1=2!@.``7!D``"D`` ````````0`@.
M````S0@.``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO<W5B7VQO8V%L7W1E<W0N
M<W%L4$L!`A0+%`````@.`FR,+QPQK9S!0``OB4``"<`````` ````0`@.````
M9@.\``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215`@.<'5B+G-Q;%!+
M`0(4"Q0````(`""2LC!_O5PM)`0``/H*```M``````````$`(````!X5``!-
M4R!297!L:6-A=&EO;B!0<F]B;&5M+U1%4U1?4D507V%U9&ET7V1T;"YT>'10
M2P$"%`L4````"`"ZD;(PDY9":N$%``!J%```*P`````````!` "````"-&0``
M35,@.4F5P;&EC871I;VX@.4')O8FQE;2]415-47U)%4%]W:5]A<V=N+G1X=%!+
M`0(4"Q0````(`.:%LC`'Z8JLMP,``&@.+```M``````````$`( ````+<?``!-
M4R!297!L:6-A=&EO;B!0<F]B;&5M+U1%4U1?4D507W=O<FM?:71E;2YT>'10
52P4&``````@.`"`#%`@.``N2,`````
`
end
Hi Kees,
I am Michael's backup since he is OOF today. We have got your file and will
working on that. Thanks for your understanding.
Best regards
Baisong Wei
Microsoft Online Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.
|||Hello,
Have you been able to reproduce the problem I'm seeing? Do you need
any further information from me?
Thank you.
Kees
On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
(Baisong Wei[MSFT]) wrote:

>Hi Kees,
>I am Michael's backup since he is OOF today. We have got your file and will
>working on that. Thanks for your understanding.
>
>Best regards
>Baisong Wei
>Microsoft Online Support
>----
>Get Secure! - www.microsoft.com/security
>This posting is provided "as is" with no warranties and confers no rights.
>Please reply to newsgroups only. Thanks.
|||Hello Kees,
Actually, one of the Microsoft Engineers has replied to your post. This
reply can be found at
http://groups.google.com/groups?q=la...t&hl=en&lr= &
ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
Please follow the suggested action plan and post if you have any further
questions.
Thanks for using MSDN Newsgroups.
Vikrant Dalwale
Microsoft SQL Server Support Professional
This posting is provided "AS IS" with no warranties, and confers no rights.
Get secure !! For info, please visit http://www.microsoft.com/security.
Please reply to Newsgroups only.
| From: kjvt <kjvt@.newsgroups.nospam>
| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
| Date: Tue, 01 Jun 2004 10:06:18 -0500
| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
<u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
<djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
<tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
<BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
<ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
<ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
| X-Newsreader: Forte Free Agent 2.0/32.652
| MIME-Version: 1.0
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
| Newsgroups: microsoft.public.sqlserver.replication
| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
| Lines: 1
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!tk2msftngp13
.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
| X-Tomcat-NG: microsoft.public.sqlserver.replication
|
| Hello,
|
| Have you been able to reproduce the problem I'm seeing? Do you need
| any further information from me?
|
| Thank you.
|
| Kees
|
| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
| (Baisong Wei[MSFT]) wrote:
|
| >Hi Kees,
| >
| >I am Michael's backup since he is OOF today. We have got your file and
will
| >working on that. Thanks for your understanding.
| >
| >
| >Best regards
| >
| >Baisong Wei
| >Microsoft Online Support
| >----
| >Get Secure! - www.microsoft.com/security
| >This posting is provided "as is" with no warranties and confers no
rights.
| >Please reply to newsgroups only. Thanks.
|
|
|||Vikrant,
I've read and responded to that post. It proposes another test and
requests that I send my schema and scripts. I've done many tests,
most of them work fine, but my actual scenario does not work.
I sent in my schema and scripts over two weeks ago. I need you to
understand and test my scenario and tell me what to do to make it
work. From Felix's note, that process seemed to be underway. Is it?
If not, who at Microsoft is going to take ownership for resolution of
this problem?
Thank you.
Kees
On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
(Vikrant V Dalwale [MSFT]) wrote:

>Hello Kees,
>Actually, one of the Microsoft Engineers has replied to your post. This
>reply can be found at
>http://groups.google.com/groups?q=la...t&hl=en&lr= &
>ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
>Please follow the suggested action plan and post if you have any further
>questions.
>Thanks for using MSDN Newsgroups.
>Vikrant Dalwale
>Microsoft SQL Server Support Professional
>
>This posting is provided "AS IS" with no warranties, and confers no rights.
>Get secure !! For info, please visit http://www.microsoft.com/security.
>Please reply to Newsgroups only.
>--
>| From: kjvt <kjvt@.newsgroups.nospam>
>| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>| Date: Tue, 01 Jun 2004 10:06:18 -0500
>| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
>| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
><u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
><djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
><tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
><BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
><ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
><ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
>| X-Newsreader: Forte Free Agent 2.0/32.652
>| MIME-Version: 1.0
>| Content-Type: text/plain; charset=us-ascii
>| Content-Transfer-Encoding: 7bit
>| Newsgroups: microsoft.public.sqlserver.replication
>| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
>| Lines: 1
>| Path:
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGP08.phx.gbl!tk2msftngp13
>phx.gbl
>| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
>| X-Tomcat-NG: microsoft.public.sqlserver.replication
>|
>| Hello,
>|
>| Have you been able to reproduce the problem I'm seeing? Do you need
>| any further information from me?
>|
>| Thank you.
>|
>| Kees
>|
>| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
>| (Baisong Wei[MSFT]) wrote:
>|
>| >Hi Kees,
>| >
>| >I am Michael's backup since he is OOF today. We have got your file and
>will
>| >working on that. Thanks for your understanding.
>| >
>| >
>| >Best regards
>| >
>| >Baisong Wei
>| >Microsoft Online Support
>| >----
>| >Get Secure! - www.microsoft.com/security
>| >This posting is provided "as is" with no warranties and confers no
>rights.
>| >Please reply to newsgroups only. Thanks.
>|
>|
|||Vikrant,
Let me correct my prior posting to say that it is Baisong who appeared
to be testing my schema and scripts. I don't know where I came up
with the name Felix, but that's part of the frustration: we've had
five different support people responding to this thread.
Kees
On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
(Vikrant V Dalwale [MSFT]) wrote:

>Hello Kees,
>Actually, one of the Microsoft Engineers has replied to your post. This
>reply can be found at
>http://groups.google.com/groups?q=la...t&hl=en&lr= &
>ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
>Please follow the suggested action plan and post if you have any further
>questions.
>Thanks for using MSDN Newsgroups.
>Vikrant Dalwale
>Microsoft SQL Server Support Professional
>
>This posting is provided "AS IS" with no warranties, and confers no rights.
>Get secure !! For info, please visit http://www.microsoft.com/security.
>Please reply to Newsgroups only.
>--
>| From: kjvt <kjvt@.newsgroups.nospam>
>| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>| Date: Tue, 01 Jun 2004 10:06:18 -0500
>| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
>| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
><u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
><djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
><tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
><BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
><ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
><ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
>| X-Newsreader: Forte Free Agent 2.0/32.652
>| MIME-Version: 1.0
>| Content-Type: text/plain; charset=us-ascii
>| Content-Transfer-Encoding: 7bit
>| Newsgroups: microsoft.public.sqlserver.replication
>| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
>| Lines: 1
>| Path:
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGP08.phx.gbl!tk2msftngp13
>phx.gbl
>| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
>| X-Tomcat-NG: microsoft.public.sqlserver.replication
>|
>| Hello,
>|
>| Have you been able to reproduce the problem I'm seeing? Do you need
>| any further information from me?
>|
>| Thank you.
>|
>| Kees
>|
>| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
>| (Baisong Wei[MSFT]) wrote:
>|
>| >Hi Kees,
>| >
>| >I am Michael's backup since he is OOF today. We have got your file and
>will
>| >working on that. Thanks for your understanding.
>| >
>| >
>| >Best regards
>| >
>| >Baisong Wei
>| >Microsoft Online Support
>| >----
>| >Get Secure! - www.microsoft.com/security
>| >This posting is provided "as is" with no warranties and confers no
>rights.
>| >Please reply to newsgroups only. Thanks.
>|
>|
|||Hello Kees,
I apologize for the confusion which is casused by our internal tool
problem.
From here onwards, please track the thread at
http://groups.google.com/groups?hl=e...txifQEHA.3996%
40cpmsftngxa10.phx.gbl&rnum=1&prev=/groups%3Fq%3Dlanlb%2BMerge%2Bfilter%2Bin
consistant%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DEYOtxifQEHA.3996%2540cpms
ftngxa10.phx.gbl%26rnum%3D1
on which Microsoft Engneer with name LanLewis-Bevan [MS] will be working
with you shortly.
Thanks for using MSDN Managed Newsgroup.
Vikrant Dalwale
Microsoft SQL Server Support Professional
Microsoft highly recommends to all of our customers that they visit the
http://www.microsoft.com/protect site and perform the three straightforward
steps listed to improve your computers security.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
>From: kjvt <kjvt@.newsgroups.nospam>
>Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>Date: Wed, 02 Jun 2004 08:30:56 -0500
>Message-ID: <5glrb0p0jj73amu7boccvvdolmu98qemk6@.4ax.com>
>References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
<u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
<djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
<tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
<BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
<ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
<ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
<6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
<kmY8vOFSEHA.2260@.cpmsftngxa10.phx.gbl>
>X-Newsreader: Forte Free Agent 2.0/32.640
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Newsgroups: microsoft.public.sqlserver.replication
>NNTP-Posting-Host: adsl-67-67-196-3.dsl.austtx.swbell.net 67.67.196.3
>Lines: 1
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP11
.phx.gbl[vbcol=seagreen]
>Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51292
>X-Tomcat-NG: microsoft.public.sqlserver.replication
>Vikrant,
>Let me correct my prior posting to say that it is Baisong who appeared
>to be testing my schema and scripts. I don't know where I came up
>with the name Felix, but that's part of the frustration: we've had
>five different support people responding to this thread.
>Kees
>On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
>(Vikrant V Dalwale [MSFT]) wrote:
=&[vbcol=seagreen]
rights.[vbcol=seagreen]
(1/1)[vbcol=seagreen]
13
>

Merge filter inconsistant

We are doing merge replication between a central server and multiple
anonymous clients. We use a filter on one table and joins to related
tables to determine what records to merge. There are two parts to the
filter, one is user, which merges only records assigned to the user
that is replicating. The second is a merge code, which is set to 0 or
1 and basically serves as a completion code: when the user is done
with the record, it is set to complete and is no longer included in
the merge.
The problem has to do with changes to the merge code. As long as it
is set to 1, replication occurs smoothly. After it is set to 0 and
merged so that client and server are 0, changes made to the client
records continue to be merged with the server until a change is made
to the table on the server. So, if there are two tables A & B, when
table A is changed on the server, local changes to A will no longer be
merged but local changes to B will continue to merge until a change is
made to B on the server. Since A & B are related tables, this is a
serious synchronization issue! It is as though a server change has to
be made to each table to force re-evaluation of the filter criteria
for that table, strange.
Here are the details of our setup:
There are 3 tables for which merge replication is defined on SQL
Server 2000 on NT:
1. WI_ASGN
wi_asgn_guid
wi_guid (fk to work_item constraint)
asgn_to_user_id
dnld_merg_cd
2. WORK_ITEM
wi_guid
office_id
3. WI_DETAIL
dtl_guid
wi_guid (fk to work_item constraint)
start_date
A row filter is defined on the WI_ASGN table: WHERE
[WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM
[dbo].[WI_ASGN] WHERE (ASGN_TO_USER_ID =
dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
fGetCurrentUserID is a user defined function which returns a char(8)
user_id.
Join filters are used to filter WORK_ITEM:
SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
[dbo].[WORK_ITEM] ON [WI_ASGN].[WI_GUID] =
[WORK_ITEM].[WI_GUID]
and WI_DETAIL:
SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
[dbo].[WI_DETAIL] ON [WI_ASGN].[WI_GUID] =
[WI_DETAIL].[WI_GUID]
We begin with DNLD_MERG_CD = 1 and merge replication running smoothly.
After the user has completed working on the assignment, the data no
longer should no longer replicate even if the user makes chagnes. We
reset the DNLD_MERG_CD to 0 so that the replication filter condition
would not be met.
After doing this, the problem occurs. The following steps were
executed to test the replication:
Action:
DNLD_MERG_CD is set to 0.
Merge is executed.
Result:
Merge code is 0 on both databases (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local changes are replicated to the Central database. (not expected
since merge filter condition is not met)
Action:
WORK_ITEM is updated on the Central database.
Merge is executed
Result:
The Central change is not replicated to the Local database. (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local change to WORK_ITEM is not replicated (expected, but different
result then the first local change)
Local change to WI_DETAIL is replicated to Central database (not
expected since merge filter condition is not met)
Action:
WI_DETAIL is updated on the Central database.
Merge is executed
Result:
The Central change is not replicated to the Local database. (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local changes ar not replicated (expected)
Why do the changes to the Local database tables continue to replicate
until the corresponding Central database table is modified?
Sorry for the length of this post, but it seemed necessary. Thanks
for your help.
Kees VanTilburg
VanTilburg Enterprises
Hi Kees,
There is something strange happening here.
Firstly, if a row meets your subset filter requirements it will be
replicated to the subscriber from the publisher. Then, subscriber DML on
that row will be replicated back to the publisher.
If, however, your subset filter excludes the row then the row will not
replicate to the subscriber in the first place. Now, in your case, the
row does at first match the filter's requirements so it is replicated to
the subscriber. But when you change the row data so that the row does
not match the filter anymore (we call that "moving out of partition")
the row at the subscriber should be deleted since it no longer belongs
in the subscriber's partition. Because your row (and all its dependent
rows) does not get removed from the subscriber, it leads me to believe
that something could be wrong with the subset filterclause.
Looking at your subset filterclause, the only thing that struck me as a
bit strange was the unnecessary double select. Could you try use the
following instead:
change:
WHERE [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN] WHERE
(ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
to:
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1)
There shouldn't be a reason to do the first IN selection since the
second WHERE clause is all you're interested in.
Also, you might try (for testing sake) remove the first requirement and
simply state WHERE DNLD_MERG_CD = 1 as your subset filterclause. See if
this works and then add fGetCurrentUserID() back again.
Hope this helps,
Reinout Hillmann
SQL Server Product Unit
This posting is provided "AS IS" with no warranties, and confers no rights.
kjvt wrote:
> We are doing merge replication between a central server and multiple
> anonymous clients. We use a filter on one table and joins to related
> tables to determine what records to merge. There are two parts to the
> filter, one is user, which merges only records assigned to the user
> that is replicating. The second is a merge code, which is set to 0 or
> 1 and basically serves as a completion code: when the user is done
> with the record, it is set to complete and is no longer included in
> the merge.
> The problem has to do with changes to the merge code. As long as it
> is set to 1, replication occurs smoothly. After it is set to 0 and
> merged so that client and server are 0, changes made to the client
> records continue to be merged with the server until a change is made
> to the table on the server. So, if there are two tables A & B, when
> table A is changed on the server, local changes to A will no longer be
> merged but local changes to B will continue to merge until a change is
> made to B on the server. Since A & B are related tables, this is a
> serious synchronization issue! It is as though a server change has to
> be made to each table to force re-evaluation of the filter criteria
> for that table, strange.
> Here are the details of our setup:
> There are 3 tables for which merge replication is defined on SQL
> Server 2000 on NT:
> 1. WI_ASGN
> wi_asgn_guid
> wi_guid (fk to work_item constraint)
> asgn_to_user_id
> dnld_merg_cd
> 2. WORK_ITEM
> wi_guid
> office_id
> 3. WI_DETAIL
> dtl_guid
> wi_guid (fk to work_item constraint)
> start_date
> A row filter is defined on the WI_ASGN table: WHERE
> [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM
> [dbo].[WI_ASGN] WHERE (ASGN_TO_USER_ID =
> dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
> fGetCurrentUserID is a user defined function which returns a char(8)
> user_id.
> Join filters are used to filter WORK_ITEM:
> SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
> [dbo].[WORK_ITEM] ON [WI_ASGN].[WI_GUID] =
> [WORK_ITEM].[WI_GUID]
> and WI_DETAIL:
> SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
> [dbo].[WI_DETAIL] ON [WI_ASGN].[WI_GUID] =
> [WI_DETAIL].[WI_GUID]
> We begin with DNLD_MERG_CD = 1 and merge replication running smoothly.
> After the user has completed working on the assignment, the data no
> longer should no longer replicate even if the user makes chagnes. We
> reset the DNLD_MERG_CD to 0 so that the replication filter condition
> would not be met.
> After doing this, the problem occurs. The following steps were
> executed to test the replication:
> Action:
> DNLD_MERG_CD is set to 0.
> Merge is executed.
> Result:
> Merge code is 0 on both databases (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local changes are replicated to the Central database. (not expected
> since merge filter condition is not met)
> Action:
> WORK_ITEM is updated on the Central database.
> Merge is executed
> Result:
> The Central change is not replicated to the Local database. (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local change to WORK_ITEM is not replicated (expected, but different
> result then the first local change)
> Local change to WI_DETAIL is replicated to Central database (not
> expected since merge filter condition is not met)
> Action:
> WI_DETAIL is updated on the Central database.
> Merge is executed
> Result:
> The Central change is not replicated to the Local database. (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local changes ar not replicated (expected)
> Why do the changes to the Local database tables continue to replicate
> until the corresponding Central database table is modified?
> Sorry for the length of this post, but it seemed necessary. Thanks
> for your help.
> Kees VanTilburg
> VanTilburg Enterprises
>
|||I assume that your subscribers are runnig sql server ce.
Take a look at
http://support.microsoft.com/default...b;EN-US;315758
http://support.microsoft.com/default...b;EN-US;287651
http://support.microsoft.com/default...b;EN-US;827914
Marius
|||Thank you for your reply. No, the subscribers are running MSDE.
Kees
On Thu, 13 May 2004 11:25:32 +0300, "Marius Bucur"
<marius.bucur@.optima.ro.nospan> wrote:

>I assume that your subscribers are runnig sql server ce.
>Take a look at
>http://support.microsoft.com/default...b;EN-US;315758
>http://support.microsoft.com/default...b;EN-US;287651
>http://support.microsoft.com/default...b;EN-US;827914
>Marius
>
|||Reinout,
Thank you for your reply. Please see my comments below.
Kees
On Wed, 12 May 2004 18:02:06 -0700, "Reinout Hillmann [MS]"
<reinouth@.online.microsoft.com> wrote:

>Hi Kees,
>There is something strange happening here.
>Firstly, if a row meets your subset filter requirements it will be
>replicated to the subscriber from the publisher. Then, subscriber DML on
>that row will be replicated back to the publisher.
>If, however, your subset filter excludes the row then the row will not
>replicate to the subscriber in the first place. Now, in your case, the
>row does at first match the filter's requirements so it is replicated to
>the subscriber. But when you change the row data so that the row does
>not match the filter anymore (we call that "moving out of partition")
>the row at the subscriber should be deleted since it no longer belongs
>in the subscriber's partition. Because your row (and all its dependent
>rows) does not get removed from the subscriber, it leads me to believe
>that something could be wrong with the subset filterclause.
>Looking at your subset filterclause, the only thing that struck me as a
>bit strange was the unnecessary double select. Could you try use the
>following instead:
>change:
>WHERE [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN] WHERE
>(ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
>to:
>WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1)
>There shouldn't be a reason to do the first IN selection since the
>second WHERE clause is all you're interested in.
There's another layer of complexity that necessitates the subquery.
However, I think it would be better to filter on the Work_Item table
as follows:
WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1))
Work item has a one-many relationship with wi_asgn (there may be many
employees assigned to a single work item). If I am assigned to a work
item, I need to replicate all the assignment records for the work item
(including other employees' assignment records). But I don't want any
assignments for work items that I'm not assigned to. So for example:
wi_guidasgn_to_user_iddnld_merg_cd
1me1
1john1
1jane1
2john1
3jane1
If I merge, then I need to replicate the first three rows. If i
filter on Work_item as specified above, then join wi_asgn to work_item
on wi_guid, that should return the proper rows. This is different
from what I was doing prior (the filter was on wi_asgn, which was then
joined to work_item), so I'll test this and report back.

>Also, you might try (for testing sake) remove the first requirement and
>simply state WHERE DNLD_MERG_CD = 1 as your subset filterclause. See if
>this works and then add fGetCurrentUserID() back again.
I'll also try this simpler test and report back.

>
>Hope this helps,
>Reinout Hillmann
>SQL Server Product Unit
|||Hi Kees,
I am just checking on your progress regarding you said you will show us
your report back. I wonder how the testing is going. If you encounter any
difficulty, please do not hesitate to let me know. Please post here and let
me know the status of your issue. Without your further information, it's
very hard for me to continue with the troubleshooting.
Looking forward to hearing from you soon.
Sincerely yours,
Michael Cheng
Microsoft Online Support
************************************************** *********
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks.
|||Michael,
Based on further testing, it appears to be the subquery in the filter
clause that causes the problem. Please see below for updates on my
test results that led to this conclusion.
How can I restructure the filter to eliminate the problem while still
meeting my requirement?
Thank you.
Kees
On Thu, 13 May 2004 17:09:59 -0500, kjvt <kjvt@.newsgroups.nospam>
wrote:

>Reinout,
>Thank you for your reply. Please see my comments below.
>Kees
>
>On Wed, 12 May 2004 18:02:06 -0700, "Reinout Hillmann [MS]"
><reinouth@.online.microsoft.com> wrote:
>
>There's another layer of complexity that necessitates the subquery.
>However, I think it would be better to filter on the Work_Item table
>as follows:
>WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
>WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
>1))
>Work item has a one-many relationship with wi_asgn (there may be many
>employees assigned to a single work item). If I am assigned to a work
>item, I need to replicate all the assignment records for the work item
>(including other employees' assignment records). But I don't want any
>assignments for work items that I'm not assigned to. So for example:
>wi_guidasgn_to_user_iddnld_merg_cd
>1me1
>1john1
>1jane1
>2john1
>3jane1
>If I merge, then I need to replicate the first three rows. If i
>filter on Work_item as specified above, then join wi_asgn to work_item
>on wi_guid, that should return the proper rows. This is different
>from what I was doing prior (the filter was on wi_asgn, which was then
>joined to work_item), so I'll test this and report back.
>
I retested after moving the filter criteria to the work_item table
WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1))
and received the same results (see my note describing the original
problem).

>I'll also try this simpler test and report back.
A simple filter clause (without the subquery)
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1)
works correctly. When the dnld_merge_cd is set to 0 and a merge is
executed, the row is deleted from the local (subscriber) database.
(Thus my conclusion that the subquery is causing the problem.)
However, this approach does not return all the records that I need.
[vbcol=seagreen]
|||Hi Kees,
Thanks for your update.
From your descriptions, I understood that
1.
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =1)
the WHERE clause works well, why didn't you use this clause only?
2.
WHERE [Work_Item].[WI_GUID]
IN
(SELECT WI_GUID
FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =1))
By using WHERE clauses above, could you make the right result back in Query
Analyzer? Could you make all other clause and condition right back from
Query Analyzer? I am not sure what dbo.fGetCurrentUserID() send back, but
based on my testing, the above could work well.
Could you make it without dbo.fGetCurrentUserID()?
Would you please send me some sample data that could reproduce the problem?
Could you ensure dbo.fGetCurrentUserID() send the right result and
condition for WHERE clause?
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know.
Sincerely yours,
Michael Cheng
Microsoft Online Support
************************************************** *********
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks.
|||Hi Kees,
I checked your replication logic, couldn't figure out why the replication
behaves like that.
So I setup a merge replication to test, using one table:
1. Create the merge table:
create table T3 (c1 int, c2 int, c3 char(8), c4 int)
insert T3 values (1, 1, 'one', 0)
2. Checked the filter statement:
Select * from T3 where c1 in (select c1 from T3 where c3 = 'one' and c4 =1)
=> 0 row returned
Select * from T3 where c3 = 'one' and c4 =1 => 0 row returned.
3. Setup a merge replication for this table (T3) with row filter:
SELECT <published_columns> FROM [dbo].[T3] WHERE c1 in (select c1 from T3
where c3 = 'one' and c4 = 1)
4. Run Snapshot and merge agents. Checked the subscriber table, no row was
copied, This is as expected, since no row satisfies the filter condition..
5. updated publisher:
update T3 set c4=1
6. Run merge agent, one row went to the sub, as expected. Now both pub and
sub has one row with c4 = 1
7. Updated subscriber:
update T3 set c4=0
8. Run merge agent. The row at the sub was removed and the row at pub was
updated. This is by design. At any time, as soon as a row becomes
dissatisfied to the filter condition, it will be removed from the
subscriber table.
After Step 6, if I run step 7, before run merge agent, make another update
statement:
update T3 set c1=0, c2=3 where c1=1
Then run merge agent, I see the row in subscriber was removed and the row
in publisher was updated.
In your case, your first action (below) should remove the row from the
subscriber, then you won't have a chance to do the other updates:
Action:
DNLD_MERG_CD is set to 0.
Merge is executed.
Result:
Merge code is 0 on both databases (expected)
Please test again. If confirmed, please let me know all the versions of
your publisher, subscriber and distributor (I am using 818 for all), and if
possible, send your table schemas and replication script to me for further
check.
Regards,
Lan Lewis-Bevan
MS SQL support
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Lan,
Thank you for looking into this problem. There's an extra wrinkle in
my scenario that could affect the result. My filter condition is on
another table. The filter condition excludes rows based on values in
the second table, yet because of the filter join, those excluded rows
are appropriately included in the replication. You may need to add
that second table to see the same results.
I posted my table defns and replication scripts to this newsgroup and
received a reply from Baisong Wei that they would try to duplicate the
error (see 5/18, appears as a separate thread in Agent Newsreader). I
have not heard back from them. I'd love to get this solved sooner,
but don't want to see you duplicating effort.
We have version 8.00.760 on our server and locally. I believe this is
sp3. Where do I obtain v8.18? It would be worth a retest on that
version.
Kees
@.@.version on publisher:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack
4)
@.@.version on subscriber:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Personal Edition on Windows NT 5.1 (Build 2600: Service Pack
1)
On Tue, 25 May 2004 01:36:27 GMT, lanlb@.online.microsoft.com (Lan
Lewis-Bevan [MS]) wrote:

>Hi Kees,
>I checked your replication logic, couldn't figure out why the replication
>behaves like that.
>So I setup a merge replication to test, using one table:
>1. Create the merge table:
>create table T3 (c1 int, c2 int, c3 char(8), c4 int)
>insert T3 values (1, 1, 'one', 0)
>2. Checked the filter statement:
>Select * from T3 where c1 in (select c1 from T3 where c3 = 'one' and c4 =1)
> => 0 row returned
>Select * from T3 where c3 = 'one' and c4 =1 => 0 row returned.
>3. Setup a merge replication for this table (T3) with row filter:
>SELECT <published_columns> FROM [dbo].[T3] WHERE c1 in (select c1 from T3
>where c3 = 'one' and c4 = 1)
>4. Run Snapshot and merge agents. Checked the subscriber table, no row was
>copied, This is as expected, since no row satisfies the filter condition..
>5. updated publisher:
>update T3 set c4=1
>6. Run merge agent, one row went to the sub, as expected. Now both pub and
>sub has one row with c4 = 1
>7. Updated subscriber:
>update T3 set c4=0
>8. Run merge agent. The row at the sub was removed and the row at pub was
>updated. This is by design. At any time, as soon as a row becomes
>dissatisfied to the filter condition, it will be removed from the
>subscriber table.
>After Step 6, if I run step 7, before run merge agent, make another update
>statement:
>update T3 set c1=0, c2=3 where c1=1
>Then run merge agent, I see the row in subscriber was removed and the row
>in publisher was updated.
>
>In your case, your first action (below) should remove the row from the
>subscriber, then you won't have a chance to do the other updates:
>Action:
>DNLD_MERG_CD is set to 0.
>Merge is executed.
>Result:
>Merge code is 0 on both databases (expected)
>
>Please test again. If confirmed, please let me know all the versions of
>your publisher, subscriber and distributor (I am using 818 for all), and if
>possible, send your table schemas and replication script to me for further
>check.
>Regards,
>
>Lan Lewis-Bevan
>MS SQL support
>This posting is provided "AS IS" with no warranties, and confers no rights.

Merge Dynamic filter problem

Hi!

I'm a merge newbie and have a couple of questions. I'm about to setup a merge replication with Sql Server 2005 and Sql Server CE as a subscriber. Situation is like this, we have 10 service technicians using pda.

I want to each pda user have their own data. What I understand I need to use dynamic filter and SUSER_NAME()? Do I need to create a "translation" table to map my system's UserId against SUSER_NAME? How have you solved this problem?

/Magnus

Hello magnus,

One easy approach is to have a column in the table for filtering purpose.

Please take a look on sp_addmergearticle (Transact-SQL) , from http://msdn2.microsoft.com/en-us/library/ms174329.aspx.

[ @.subset_filterclause = ] 'subset_filterclause'
Is a WHERE clause specifying the horizontal filtering of a table article without the word WHERE included. subset_filterclause is of nvarchar(1000), with a default of an empty string.

Important:
For performance reasons, we recommended that you not apply functions to column names in parameterized row filter clauses, such as LEFT([MyColumn]) = SUSER_SNAME(). If you use HOST_NAME in a filter clause and override the HOST_NAME value, you might have to convert data types by using CONVERT. For more information about best practices for this case, see the section "Overriding the HOST_NAME() Value" in Parameterized Row Filters.

Parameterized Row Filters - http://msdn2.microsoft.com/en-us/library/ms152478.aspx.

and

[ @.partition_options = ] partition_options
Defines the way in which data in the article is partitioned, which enables performance optimizations when all rows belong in only one partition or in only one subscription. partition_options is tinyint, and can be one of the following values.

Value Description
0 (default)
The filtering for the article either is static or does not yield a unique subset of data for each partition, that is, an "overlapping" partition.
1
The partitions are overlapping, and data manipulation language (DML) updates made at the Subscriber cannot change the partition to which a row belongs.
2
The filtering for the article yields non-overlapping partitions, but multiple Subscribers can receive the same partition.
3
The filtering for the article yields non-overlapping partitions that are unique for each subscription.