Hi,
I have a box running SQL 7 with replication. I restored one of the
replicated database to another SQL 7 with no replication. A developer needed
to test an upgrade of an application (MS Great Plains) using that database.
The application states that the tables are part of a replication. As far as I
know, when you restore a replicated DB to another server (with no
replication), the replication infomation is lost. I have also ran
sp_removedbreplication successfully but we still have the same problem.
Any ideas?
--
--
I saw it work in a cartoon once so I am pretty sure I can do it.The tables in question are still marked for replication.
I think you may need to manually update some of the system tables to remove
the marking for replication on the object.
I don't have my poster here at the office, so i couldn't tell you which
tables specically to look at.
I would guess sysobjects.xtype....
Rick Sawtell
MCT, MCSD, MCDBA
"Sasan Saidi" <SasanSaidi@.discussions.microsoft.com> wrote in message
news:260846C9-A09A-415A-8028-715D66021376@.microsoft.com...
> Hi,
> I have a box running SQL 7 with replication. I restored one of the
> replicated database to another SQL 7 with no replication. A developer
needed
> to test an upgrade of an application (MS Great Plains) using that
database.
> The application states that the tables are part of a replication. As far
as I
> know, when you restore a replicated DB to another server (with no
> replication), the replication infomation is lost. I have also ran
> sp_removedbreplication successfully but we still have the same problem.
> Any ideas?
> --
> --
> I saw it work in a cartoon once so I am pretty sure I can do it.|||I don't have a SQL 7.0 box at work anymore, but if it
also exists on SQL 7.0, please try using
sp_MSunmarkreplinfo which takes a tablename as a parameter
HTH,
Paul Ibison (SQL Server MVP)
>> (recommended sql server 2000 replication book:
>> http://www.nwsu.com/0974973602p.html)|||Before updatnig system tables, I would recommend making sure you've dropped
the distributor and publisher. In EM from Tools...Replication...configure
publishing subscribers and distributors. Make sure there are no selections
(uncheck all boxes).
Colleen
"Paul Ibison" wrote:
> I don't have a SQL 7.0 box at work anymore, but if it
> also exists on SQL 7.0, please try using
> sp_MSunmarkreplinfo which takes a tablename as a parameter
> HTH,
> Paul Ibison (SQL Server MVP)
> >> (recommended sql server 2000 replication book:
> >> http://www.nwsu.com/0974973602p.html)
>
>
Showing posts with label replication. Show all posts
Showing posts with label replication. Show all posts
Thursday, March 29, 2012
Cannot remove replication
Hi,
I have a box running SQL 7 with replication. I restored one of the
replicated database to another SQL 7 with no replication. A developer needed
to test an upgrade of an application (MS Great Plains) using that database.
The application states that the tables are part of a replication. As far as
I
know, when you restore a replicated DB to another server (with no
replication), the replication infomation is lost. I have also ran
sp_removedbreplication successfully but we still have the same problem.
Any ideas?
--
I saw it work in a cartoon once so I am pretty sure I can do it.The tables in question are still marked for replication.
I think you may need to manually update some of the system tables to remove
the marking for replication on the object.
I don't have my poster here at the office, so i couldn't tell you which
tables specically to look at.
I would guess sysobjects.xtype....
Rick Sawtell
MCT, MCSD, MCDBA
"Sasan Saidi" <SasanSaidi@.discussions.microsoft.com> wrote in message
news:260846C9-A09A-415A-8028-715D66021376@.microsoft.com...
> Hi,
> I have a box running SQL 7 with replication. I restored one of the
> replicated database to another SQL 7 with no replication. A developer
needed
> to test an upgrade of an application (MS Great Plains) using that
database.
> The application states that the tables are part of a replication. As far
as I
> know, when you restore a replicated DB to another server (with no
> replication), the replication infomation is lost. I have also ran
> sp_removedbreplication successfully but we still have the same problem.
> Any ideas?
> --
> --
> I saw it work in a cartoon once so I am pretty sure I can do it.
I have a box running SQL 7 with replication. I restored one of the
replicated database to another SQL 7 with no replication. A developer needed
to test an upgrade of an application (MS Great Plains) using that database.
The application states that the tables are part of a replication. As far as
I
know, when you restore a replicated DB to another server (with no
replication), the replication infomation is lost. I have also ran
sp_removedbreplication successfully but we still have the same problem.
Any ideas?
--
I saw it work in a cartoon once so I am pretty sure I can do it.The tables in question are still marked for replication.
I think you may need to manually update some of the system tables to remove
the marking for replication on the object.
I don't have my poster here at the office, so i couldn't tell you which
tables specically to look at.
I would guess sysobjects.xtype....
Rick Sawtell
MCT, MCSD, MCDBA
"Sasan Saidi" <SasanSaidi@.discussions.microsoft.com> wrote in message
news:260846C9-A09A-415A-8028-715D66021376@.microsoft.com...
> Hi,
> I have a box running SQL 7 with replication. I restored one of the
> replicated database to another SQL 7 with no replication. A developer
needed
> to test an upgrade of an application (MS Great Plains) using that
database.
> The application states that the tables are part of a replication. As far
as I
> know, when you restore a replicated DB to another server (with no
> replication), the replication infomation is lost. I have also ran
> sp_removedbreplication successfully but we still have the same problem.
> Any ideas?
> --
> --
> I saw it work in a cartoon once so I am pretty sure I can do it.
Cannot remove replication
I don't have a SQL 7.0 box at work anymore, but if it
also exists on SQL 7.0, please try using
sp_MSunmarkreplinfo which takes a tablename as a parameter
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]Before updatnig system tables, I would recommend making sure you've dropped
the distributor and publisher. In EM from Tools...Replication...configure
publishing subscribers and distributors. Make sure there are no selections
(uncheck all boxes).
Colleen
"Paul Ibison" wrote:
> I don't have a SQL 7.0 box at work anymore, but if it
> also exists on SQL 7.0, please try using
> sp_MSunmarkreplinfo which takes a tablename as a parameter
> HTH,
> Paul Ibison (SQL Server MVP)
>
>
>
also exists on SQL 7.0, please try using
sp_MSunmarkreplinfo which takes a tablename as a parameter
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]Before updatnig system tables, I would recommend making sure you've dropped
the distributor and publisher. In EM from Tools...Replication...configure
publishing subscribers and distributors. Make sure there are no selections
(uncheck all boxes).
Colleen
"Paul Ibison" wrote:
> I don't have a SQL 7.0 box at work anymore, but if it
> also exists on SQL 7.0, please try using
> sp_MSunmarkreplinfo which takes a tablename as a parameter
> HTH,
> Paul Ibison (SQL Server MVP)
>
>
>
Cannot remove replication
I don't have a SQL 7.0 box at work anymore, but if it
also exists on SQL 7.0, please try using
sp_MSunmarkreplinfo which takes a tablename as a parameter
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]
Before updatnig system tables, I would recommend making sure you've dropped
the distributor and publisher. In EM from Tools...Replication...configure
publishing subscribers and distributors. Make sure there are no selections
(uncheck all boxes).
Colleen
"Paul Ibison" wrote:
> I don't have a SQL 7.0 box at work anymore, but if it
> also exists on SQL 7.0, please try using
> sp_MSunmarkreplinfo which takes a tablename as a parameter
> HTH,
> Paul Ibison (SQL Server MVP)
>
>
sql
also exists on SQL 7.0, please try using
sp_MSunmarkreplinfo which takes a tablename as a parameter
HTH,
Paul Ibison (SQL Server MVP)
[vbcol=seagreen]
Before updatnig system tables, I would recommend making sure you've dropped
the distributor and publisher. In EM from Tools...Replication...configure
publishing subscribers and distributors. Make sure there are no selections
(uncheck all boxes).
Colleen
"Paul Ibison" wrote:
> I don't have a SQL 7.0 box at work anymore, but if it
> also exists on SQL 7.0, please try using
> sp_MSunmarkreplinfo which takes a tablename as a parameter
> HTH,
> Paul Ibison (SQL Server MVP)
>
>
sql
Tuesday, March 27, 2012
Cannot remove replication
Hi,
I have a box running SQL 7 with replication. I restored one of the
replicated database to another SQL 7 with no replication. A developer needed
to test an upgrade of an application (MS Great Plains) using that database.
The application states that the tables are part of a replication. As far as I
know, when you restore a replicated DB to another server (with no
replication), the replication infomation is lost. I have also ran
sp_removedbreplication successfully but we still have the same problem.
Any ideas?
--
I saw it work in a cartoon once so I am pretty sure I can do it.
The tables in question are still marked for replication.
I think you may need to manually update some of the system tables to remove
the marking for replication on the object.
I don't have my poster here at the office, so i couldn't tell you which
tables specically to look at.
I would guess sysobjects.xtype....
Rick Sawtell
MCT, MCSD, MCDBA
"Sasan Saidi" <SasanSaidi@.discussions.microsoft.com> wrote in message
news:260846C9-A09A-415A-8028-715D66021376@.microsoft.com...
> Hi,
> I have a box running SQL 7 with replication. I restored one of the
> replicated database to another SQL 7 with no replication. A developer
needed
> to test an upgrade of an application (MS Great Plains) using that
database.
> The application states that the tables are part of a replication. As far
as I
> know, when you restore a replicated DB to another server (with no
> replication), the replication infomation is lost. I have also ran
> sp_removedbreplication successfully but we still have the same problem.
> Any ideas?
> --
> --
> I saw it work in a cartoon once so I am pretty sure I can do it.
I have a box running SQL 7 with replication. I restored one of the
replicated database to another SQL 7 with no replication. A developer needed
to test an upgrade of an application (MS Great Plains) using that database.
The application states that the tables are part of a replication. As far as I
know, when you restore a replicated DB to another server (with no
replication), the replication infomation is lost. I have also ran
sp_removedbreplication successfully but we still have the same problem.
Any ideas?
--
I saw it work in a cartoon once so I am pretty sure I can do it.
The tables in question are still marked for replication.
I think you may need to manually update some of the system tables to remove
the marking for replication on the object.
I don't have my poster here at the office, so i couldn't tell you which
tables specically to look at.
I would guess sysobjects.xtype....
Rick Sawtell
MCT, MCSD, MCDBA
"Sasan Saidi" <SasanSaidi@.discussions.microsoft.com> wrote in message
news:260846C9-A09A-415A-8028-715D66021376@.microsoft.com...
> Hi,
> I have a box running SQL 7 with replication. I restored one of the
> replicated database to another SQL 7 with no replication. A developer
needed
> to test an upgrade of an application (MS Great Plains) using that
database.
> The application states that the tables are part of a replication. As far
as I
> know, when you restore a replicated DB to another server (with no
> replication), the replication infomation is lost. I have also ran
> sp_removedbreplication successfully but we still have the same problem.
> Any ideas?
> --
> --
> I saw it work in a cartoon once so I am pretty sure I can do it.
cannot remove repl... cannot delete database
I cannot delete a database becuase it ways its part of replication. I
removed replication via the EM GUI but it failed. All GUI elements are gone
but when I run sp_removedbreplication in query analyzer I get this:
Server: Msg 3701, Level 11, State 5, Line 1
Cannot drop the table 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
because it does not exist in the system catalog.
the weird thing is that the table mentioned in the error should not (and
does not to my knowledge) exist in this database? it exists in a different
database on the same system?
any help is greatly appreciated.
As far as I experienced it, SQL Server 2000 (at least SP3 and SP3a) does not
handle correctly merge replication of tables owned not by dbo. Various merge
replication related actions are failing because of that. One you just
mentioned - you can not properly drop merge replication, because it leaves
conflict tables. As you noticed from error message it tries to drop table
'HesstechUser.conflict_MergeReplLIVE_VendorCustome r'. I guess on your
published database you should find table
'dbo.conflict_MergeReplLIVE_VendorCustomer'.
If you can find it then I can provide you with a solution to this problem -
but it means fixing of couple of system stored procedures. Fixes are
straight forward - correct handling of object owners.
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"djc" <noone@.nowhere.com> wrote in message
news:OdhjTNDZEHA.2944@.TK2MSFTNGP11.phx.gbl...
> I cannot delete a database becuase it ways its part of replication. I
> removed replication via the EM GUI but it failed. All GUI elements are
gone
> but when I run sp_removedbreplication in query analyzer I get this:
> Server: Msg 3701, Level 11, State 5, Line 1
> Cannot drop the table
'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
> because it does not exist in the system catalog.
> the weird thing is that the table mentioned in the error should not (and
> does not to my knowledge) exist in this database? it exists in a different
> database on the same system?
> any help is greatly appreciated.
>
|||thanks for the info...
1) I ran a script posted by Hilary Cotter (thank you Hilary!) that I think
cleaned things up for me... BUT it will only happen again due to the issue
you just informed me about. So I am VERY interested in finding out how to
correct this. Please do let me know.
2) Can I change the owner of tables? if so how? The only reason they are not
owned by dbo is due to how our db person moved them to sql server from MS
Access. I would like them to be owned by dbo.
any help is GREATLY appreciated.
thanks!
"Kestutis Adomavicius" <kicker@.nospam-mail.lt> wrote in message
news:%234qLmOLZEHA.3596@.tk2msftngp13.phx.gbl...
> As far as I experienced it, SQL Server 2000 (at least SP3 and SP3a) does
not
> handle correctly merge replication of tables owned not by dbo. Various
merge
> replication related actions are failing because of that. One you just
> mentioned - you can not properly drop merge replication, because it leaves
> conflict tables. As you noticed from error message it tries to drop table
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r'. I guess on your
> published database you should find table
> 'dbo.conflict_MergeReplLIVE_VendorCustomer'.
> If you can find it then I can provide you with a solution to this
problem -[vbcol=seagreen]
> but it means fixing of couple of system stored procedures. Fixes are
> straight forward - correct handling of object owners.
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
> "djc" <noone@.nowhere.com> wrote in message
> news:OdhjTNDZEHA.2944@.TK2MSFTNGP11.phx.gbl...
> gone
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
different
>
|||oh one more very important question:
what else do I need to worry about due to this 'owner not being dbo'
problem? I currently have the same setup on a production server that is
about to go live. The issue I just cleaned up (I think) was on a test
server. You said 'various merge replication related actions are failing
because of that'. Is the integrity of my data in danger? can things get out
of sync? Do I need to think about stopping this from going live?
please let me know more. Thanks.
"Kestutis Adomavicius" <kicker@.nospam-mail.lt> wrote in message
news:%234qLmOLZEHA.3596@.tk2msftngp13.phx.gbl...
> As far as I experienced it, SQL Server 2000 (at least SP3 and SP3a) does
not
> handle correctly merge replication of tables owned not by dbo. Various
merge
> replication related actions are failing because of that. One you just
> mentioned - you can not properly drop merge replication, because it leaves
> conflict tables. As you noticed from error message it tries to drop table
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r'. I guess on your
> published database you should find table
> 'dbo.conflict_MergeReplLIVE_VendorCustomer'.
> If you can find it then I can provide you with a solution to this
problem -[vbcol=seagreen]
> but it means fixing of couple of system stored procedures. Fixes are
> straight forward - correct handling of object owners.
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
> "djc" <noone@.nowhere.com> wrote in message
> news:OdhjTNDZEHA.2944@.TK2MSFTNGP11.phx.gbl...
> gone
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
different
>
|||I attached fixes to stored procedures which are designed for SQL Server 2000
SP3a
They should be executed on master database. Be careful with them, execute
parts of every script step by step.
At the end of every script there is update to sysobjects table, which
restores initial state of stored procedure (which is changed after "alter
procedure" statement is executed). So before altering procedure, check if
this update will restore correctly stored procedure status (status in update
statement should match status which you will see in resultset, received from
select statement which is commented near to update).
Those are procedures which i met on my way of deploying merge replication.
First of all I fixed four procedures, but when I added publication
filtering, I had to fix some more
Now I am applying those fixes to all
new servers I am installing (where merge replication is used) and every
manipulations to merge replication are working smoothly.
Regards,
Kestas
"djc" <noone@.nowhere.com> wrote in message
news:%23d2H5xOZEHA.3368@.TK2MSFTNGP12.phx.gbl...
> thanks for the info...
> 1) I ran a script posted by Hilary Cotter (thank you Hilary!) that I think
> cleaned things up for me... BUT it will only happen again due to the issue
> you just informed me about. So I am VERY interested in finding out how to
> correct this. Please do let me know.
> 2) Can I change the owner of tables? if so how? The only reason they are
not[vbcol=seagreen]
> owned by dbo is due to how our db person moved them to sql server from MS
> Access. I would like them to be owned by dbo.
> any help is GREATLY appreciated.
> thanks!
> "Kestutis Adomavicius" <kicker@.nospam-mail.lt> wrote in message
> news:%234qLmOLZEHA.3596@.tk2msftngp13.phx.gbl...
> not
> merge
leaves[vbcol=seagreen]
table[vbcol=seagreen]
> problem -
(and
> different
>
begin 666 Merge replication fixes.zip
M4$L#!!0````(`,V0\2[413QMR"D``"R]```B````1FEX960@.+2!S<%]A9&1M
M97)G96%R=&EC;&4@.4U S+G-Q;-U];7/;1I+P9Z8J_V&JGJHEZ4 R2<FVDC5=
M4F0ZT466?)*\R=5FBP61H(0S"7 !T+*V[L<_W3WO+P`A6;G<'2NQ2&"F9Z:G
MNZ>GNZ>G7$]G>;9(;S9%P@.[YURQ>)6S,NO%RF=^QS7H>5TG9C>3KS_%R0^^'
MW6^_^>G\VV\N)L?G9^].?OIX,6&_GES]S,[_-KFX.'D[X:^__29>5DG!UD4^
M2^;83KF>QO/Y*BENDKBHTMDR^?8;!I_#]>9ZF<[B*LTS9GS*^Q+[%+&&S_-G
MS*Q-8WCV7, 5K;AU6L*5M6V89;XI9LDTO_[/9%8]&":OS41M&W)UOTX"M01D
MQ'P57R^3;A2$+'M+4!3,>5+.BG3M8C;['!>SV[CHC5Z\Z(_9V <?3TZ@.!I@.E%
M@.9[ER\TJFU9%//N49C<>Z.&@.CWU>Q,O2[3. YK79,OF<+)F"H;%<Q=6F],;I
M`M]DY7T&U&7"!^#R<<3B695^-O"Q+I+IK$B(6*:SU;P&[KS(URZ>`6XWRS,<
MBWS?G2?+I*(G5;')@. :3KH$@.V0Y'WB-Q7\YNDU7,! R-('H\S9VI!=C7:187
M][V#/OP,@.O>!RYXR#JXTFME<ETDU7:3(RK-EO"D3!U\#CK%N: R\&A/U7+:<
M%DF9+S]#@.?(=+9E%6^8JKV(B_4@.%0;\NTTS19Y#>&S>NR[;1 43P;<9:KS
M-J<26,V"%4P)40+5Z'3"!:$=&$2\G*YQ-%B^TU']I=YVWQV=7DZZ40<^T$E9
M@.:D*R$. C2PW*"7>5/DTG2<9%+F?%G%VDYA@..QY8F'"65JS*&?$NX3>#%6&'
M016HS=*2K?.R3*]-A(,4=EOI7*<W:59U[&&ZA40I!QG5+>#^-E_.L5,6D XB
M*EW<*_*9EKAV5;C"4%& -*"QX& &XWE.^."5F"H;L>%8/*MNXTJ_P.$M"IA\
M8.FR2N9"9D=LE<-+6@.5+MHKOV77"8#F#`LL8J=R4N7K"]3)A3KN]BM"@.:-4%
M:@.507&BI\7E4($0JC>_N-JEN$\T`!*9D!AQ.Q!O.WYHV.H>+N*RFJ\T2*N;+
M*5_O<;'VV@.-$N,WQTK2V,YBFS7(N'Q' -?2$2WCL"@..I*5^C8$]60 &B+[LL
M7<!TP1PD&5 >4#*6$H73LMP`?I$`DWAV*Q<-3H;S73$.D&&S3]-U4JR@./(HO
M307(RM=IM8K7V'.8OL&7P4 0-%4K(WPTI$=I5@.)#,7J.CT?T5'1%/=VGIUSP
M\Z<2G3G.: JX6Z9890J3O0;<5-@.#U9MW6(KI4BSYDB*YW#!5G(,CK::\3>8`
M$A?9; I/6) 2$.Y)-D<="$B3J+FZ!2H6-%$"WG""@.%X54)R5&-?=K$0JR3.4
M(H8>%9?L+EDN%5$?7
"1T(.I ,@.+]_@.%&;RZ...G_.^S9^QM`O*^(##EKGB*
M(YK3<] V5_$7Q?N"^7DQ54)VL\ 2@.FOJBDSGUV8AW4R\A%5M?C]58\;&W):4
M,"KSZ2(N:OJ#0L80RAV_!*BVFEUKNIQM5E/)%.:JL0*>#>(@.G3/OL\G2?VX2
MWNU%:BT_<NWZ8,PC@.)!3J"#/KUGH$T"AQLYFO<Z+*C1R5Q%VH=F%G16SL7"1
M5+-\[JG$P2Z$4!68)= *IWYIOR JT0&0-5.5I;-/)-BWM4];'R1((?BG*!G\
M8HYF/14]"11<!8;M*#DN"DBQ]L8&$N@.>A>;.SO 'BO'']EHQ^8_/KBARS!
M]4DL*B_I)__AHB/Y4DW+))G7\W>10->]3O@.%U1(_6YI]UE)PT&^L,04%8EL-
MVE3A%&[K# J %AQI,1"I(9QK; $H6<M 4<<D`*2G3EBPI2#JYR&XZT^?DOM.
MO<R<PTI3I->@.#UH\V%C8%1;UA4D7J"'$O8&']OEU@.&7J1<%Z:2OR-7,TOYZ&
MP(:A\LU-"[F1EE-S20K0*:AN9?JO[1(`U@.EO9MT"8I-05^*?&U =@.-#F]D@.U
MT[_R<"U5BRFMB"[3FR1$$G(%4A?;#[SWM50087Q=U87J%$L2= T[9H)JC"]H,
M.)^GCF8<1E$,[^*;[>56P$JHJ6TKEX$P`Q(`&;%9=T)J!'!T* T#08+H"-6!K
MN?A+NW*XH%1?JJT%UT4J5I5 23T;7W#A"XF6+RBR0R]@.0%4*>U9@.)-1B.RXM
M7&]6ZREL0 \&G8[W\@.9T_A!09'>2R(%W4.=F`W(87S6)7BR4;4"%W59P7O$^
MX 16*>$#_@.,]:A5_@.OT*[@.AGFZ+ +0L4B:_CDK28;K!M^<T#0P$E)"[Y)*
M5_(EF2E-9CR_SG>!P=]?'N.^@.6H9E7@.-V X='DXN+LXO7K\9X"9)UH:?O$0'
M'FR*C/6&_8#Z?<(G)/T7U\"9H8&CL--X@.>W#0'QV`O_(3U>J_4M4\RQ1B)L:
MYZU-#7X!DY/\MYI8_'>>.N\7,3MV>'@.YN?C;Y.+LZ/VDIA3L'*"@.6#%Z?;N4
MM49SVX,[$J7EA%Z[>I;765>U"0)Q%J@.Q&S(^W>P8YK;ZP=JSD >6WR^MH,Z0:
M4$CWY#!'!T0<O)S 1Z<6,\96A^'8N^_369&7^BE_]^>ID4^.(2= R8H@._*
M]G\AJCCDY(ETYD%D`N21*(I#7\"@.JUJ8CO1O`$DED5"WP70%=SW ,][SD=HB.
MB&^ R$NVZ:.U"-5#?'MT-;DZ>3]AO4E<+'$7^6N:E?TV?7YP"Z=D'&L)WUW.
M&I!"(O<*F!"@.\CWU-NC^&E@./_D.1Y@.6PO@.!N@.M1BVC(#PY*@.&1@._UPE0EOYI
ML9!9<<PV)8@.!8C60S7UN?(3%F...I*2Q7*0H\P;KIO&=;$/MV.W6=8\PN5]--
M^2GB%'I6P!K4&^X/1J\B-AQ&; ?^;VQ=53>6*?==DLWU0_5#XL=1<<?LWS^>
M7TU0E/>L<?79=ZR[VX5_`P5DUT"V$3X"GHS7;UBWR^)L'GX-6$-K*9_6CD 4
M:@.;<[%?=DCDXG2.=Y L6`D'K+BD!O:[><28E;?O5>/'!>,@.G'D?C(@.!&*:B@.
M-QR/^M1C*A=HLB_&JW0(^*WZWNFH.>V-AJ,7+V%*7\HI]6%%RE?3YY6-&>UT
M:-HZ:O*P4<_78;.%7F2\<NATN\X%QWI*S64"*ABQ(V)>JS3X=_+; Y%@.;BW#9
M$DH6JE;"-LR7?%[^Y)U$#LZ_I6+1`TV7C7K6AWC.\DU%5%"NDQE-EW2H";=<
ME=/K9;*H[#XK06!Y\<9L@.;)IO01E>QW/N2/OH&>7"O>E`#)!.4OX^<'RJ.^J
M8E>WB>UK!YDRBS.D\>N$"PBDK-4&R!-]_GFQDD,H-LND5(#(6JZ4:6WE9::
MT51A-=E"3-IR9W]/$VG7A-5UY$I(WA!U>OH?R5+Z&WF;XS&S'T3&IGBLOBDA
M34N6T:G2P !G6>GRL<SK@..:/'SY,+GI*&^V/^0.MGW(^-]75L:6\6@.B&(3T0
MM:/!8&3RO]&_]HA%4;/,[Y*BIR3%& -(NO529W\PE*W62I46%([:KM[T+(A*
MI1,,?1_DF8OA"^N"7@.0B>,X^I\F=XM!L>=^5%2(%2._YA!LE< 4(V$+2 L7.=
M;S(.5?,8*"&@.)@."M`>$$"AK\IC<RU$L%H5O;S=VP$"&]?RRG@.7Z!GH-.2=1H
MIJ" I=EP^E,"8A:V9L<?AM/CR^G19=]4902,LR9<P1 X$M9%ODZ*ZKYGJ"/V
MBM4'5CTI+ZGZCSCX;A]EZY WZ-"E29/#T2M3S7"@.VJ+%)DW]7*U("7JOK=$]
M_:C&[0;UHGY0X?7&$5X&*YQ#O[540(*"_V$_7Q==M76=I#4RK C1(+D]:K9;F
M<OGCY*>3,UMR7!R=7/+**&Y>[1F,;Q6;7'V\.+,%S.3LK;N6-,H#AT>>\1>X
M?L$F77/SH2$CECD@.+N+O4K7DZ67.7/O<-2\BRI%522J0(X$_!Q974&+.2QBD
M`H\1O\J,Q"G-8&O-D$8W'RC4]U_48+E)C%MVJK 21>O8H45:6L]LITI930=(
M^S+ADR3]0[N,=)9YLH@.WRXH;. `A//Q*S;2J3A_3N>1&>]DEQ_)C?A<?NR3_
M#.A?# $+O>66&>Q9Z.V(OZ6H@.=#[/?I7!I'9C LL>'K^*ZD&;O1:*SG/SLZO
MV FP5YOP-3U!'CL;S R+^,MAD,P"K$R<' @.3J#!B(TMHQM&C< .LP8-,D=<$
M'5CCW7UBQ(Q%1)_JJC85"!I29KO)Z>7D21HDW#<U.'SJ!ODD-S4Y>N(F%34U
M-;J'1%$K`K@.'OD8`D*2%=R<5+7^J,FA5&&H$>_%%CHZJ-+NIDQ*&A]_2)$W)
M8$D)CVL'7V+^A7KCOAY\&7%Y(6*DM,[AE]P7)5WMQ"]Y($HN`+_M8-;I<ZR7
M@.YZZS&-0D_O&_LT2S9H6VFN56MK(:.6NBP%\YFEB\,P=%3ZKU4<;!)6G= ^RW
MUSL,8?6HT:.6R0?.@.=B=NYQ<*=(;8^19+#A/*CL."SZP80_1;?H`=/JDG?!F
MJDTG]@.=/VH=:JOD3^N)1=9L^')A]<&Q&.HAIS,Y__+?)\=7TY&TOO*T@.RZ>N
M\'#KR^A5FYT+U:M7+^U]9DK1ASVDO BQ'>%P^\%=%%2A^,B2]<3PGRG+RRQ?
M81QI&38^&T9S`P'ALHQT]B2;%?KBAR+YAB:4 1[.U"X32-J@.UU<(&@.8,'RW
M-'HH]3NJL?#Q/4]J6T.$YU1B$G!/T:$!`,\-T3?Y[>3RZI+U+B>G0&'L60!U
M[R[.WRL;6/*E@.E$D<QETBJSGU_GUY\G%A$D3G+G1M#]'9V^5X4R;H.5;P3NF
M88FVV=^/6D[%PS><1R*F=IV#JAIAF#5#`LPS#+X7LR1B>DVW.[>5TH) 1&:N
MP"H\]S;^G "9)88FLTX*W(OB$98R9]=%G,UNR=Q,9 T;TUN I@.YPJ&HV7+(K
MD6TZAM["AM/1G_4.WV5+DH(1,QC3$%<:2U@.U$.U^<LF-R;#\AEZC4.QZDVE.
MCZ"Y<&5[8@./S9_?/-K&+KK5JW37.8^RX]1G6$$^MI47:9SADR9]VZX<V<T3.
M6UE)\X5;PCZ@.%CAK8)46IC%!`>Y;\^#7V/KIM<H/;(WE-_>]O9D`SD%N&.L-
M@.5O>/3PU]A[5C5NXDZS?@.7%Y_B?_H=>"0Q#V@.\8VU&3X3]UZGO/3>1(Q%B 9
MY5JP/0W>$%QGA_/$+5]_J&'<\-*5HTQ+7,D6?4^_V<*L#J.V8]+C=^^&7D-F
ML-2"2]!$>NQF>5;%:58*_4Z<F9%K&Q,VXC0I(V/7N5FMV69-:RY0]AJJ7:?+
MM+K?H=.-YN:*?]_989=IACX%%-?D(43;/=L;8=!CB?M79USH-E9U-R4N"UA-
M[7*%1QK6IW*S6*2S%!2C77:65\+RZ8!+2P5,*@.=K[C ACZ;V6C)A-24=B)\N
M6XAU4$;V[#J1AE9+TV4^O\N+>2 2]@.OB<NKT*Q0*OY1,'RPIM>(0.$D-L 5T
M@.J_JP,H:0Z]&>%C*8WN35,)=*U[Y7EN$!II9KP;47VI[U3=LJ301]B)G*J-[
M!]^#!C1H].@.%@.^V&CNNDN:,!9(<Z6=/'[P=?WT>/DWD\D%"TI (TSQ,>P@.$T
MO@.16$\=8F"&$I0T>;4FW<<D]?BAWN242GO!U).QZ:Z6@.?/N-[*>*_1/AXN-R
ML^HMD^RFNNT;^QH>SB1W,.,V>SP)\<U+H%P#\=H%:YI$AH.7I J;L>=GL10"D
M1$A?IGF@.^!:]-?:/L+8W&O*S;+;?6"+,.H#%C;(J_@.1JJ4I0I;'>4-4SI\,X
MF#6F@.VV]9_7384=A>1.BI\0\[O6&C?9?T@.;@."1'ES+$Y9;;]Z^5![61'V+$6
MFZ,PT[&?A+46T)+S3:<#/\PVTGI!\1?J;,>8J:\-(7!MN.%/-7;X*H8,'S?5
M-*5HQ.A1VD$3!060*?V:MIA*DL&:K(X;@.VQ-M7N1A%8NX0$X$ 48XPWDY&SW
MFHPI?%MBM"]Q;N]&^!X6S2EBWS!J-I1 DRA^&VPXG#]F@.<!$WOYL%R2@.F%!L
MG,=C?I"^>GP=02%.R]VTU*/GSOE [&&;B$=DFX.7K%5X3!--6+3A$$H'J:3#
M2>0^W["[.*OXUOYSPF3LN5RSD%'H\#UW.XO#\>3^,.*W$-YS'I4C!$W@.]/^#
M_#@.)#Y'H.<?V540INGQU=\RG?D(`^;I?'QPT_'ZO17#04XU/')^N&Z ,_O0'
M:;T)#U06:1CLZ<K"Z]=<#,JNHWV^&@.Z8(S_TVL59/2B[A!=P]22S78FR:
M2_0/%^<?)A=7_]'CS!Z);#<@.WF1=%4/4,5MPR&?'J\S8*$SD)(@.%XO ]+W&
M@.Q8XM8'G3<V/]FA"6>0V/]2-6VBA\U9C^C<2AZS&]&^]-FC(0OY.Q2TATH0<
M/"E/%-+&0ZM)=?J>C7D7.V@.9%%W!9C+V8L33,:PIHJPWHY"VJL?/J4:C?C]B
M!\]&,$:V`WC:V9''HID`V"$H^P?;H4@.8,!L[._JXH0;RXF6+KNQ;8 %P0P]&K
MK3!>CCB [[858IV='76DF3<B%5#Z;&NC31.@.;PN'-RSVN/#+\\$=BX9HB\8)
M:#@.X('*5OU[RT%%.4*^'![QN@. )J^C(<8&=ZO/YWPSXA1_)-IX9IGK$1AJ0[
M3]\`&-W@.#CMY.SF[FAY_O+B OVZPOF :@.[ML]J*=H\G=+GM+_K:W!@.U":$ [
MAM!^T@.\$Y9M+,LKI@.&\=^24#OT3 5RBJ"UWCM;J0T'7=\&'2OF3I>N6W3RX3
MH95U/W9;.K":_>,/TG(UBI1NB\$8E#5'2C'<)& 71<H?:+_\YW+Z.2[2&+TJ
M.F:.E)R$.9'CB%T)`G?=GQ'\' 3>76)9X:[CV:>[N)AK@.)9=CF<=\[5C(]![
M0%UP?6#*XZ7U5N[00C5TFZ<1YZ>'7>='?6:[Q*VT<')T=!$?X 0(&EKK$)8I%
M+,O*BU>UEA7)!1W/IM)QU=%7NP.Y%;E."K2B$.*7*7 $ABZ*@.X9X5K:LXA5&
M,RFM4V*L5M/7ZYCAEJ;I5@..7PS9::!CRP=8ALYHARXGQB/EO,C</M^C2`3"9
MC,,G&C</GN']$DJ56^*A<324?DEJJ[X;U"0R*T9ON']@.'IUPNM%]B$]4:XB/
M&XS:3)@.6_*M@.JA-MZ,/P[3;E!TI-]E\+3M:L38=HZ5'0.%1C,!OMMXDA,D\O
M=)JCE6NS?3'FD9C4S>OK_$D45=^C1Q+75P]1[T)D*W3H/9BVHI;2&JL,E*RL
MG=QPZJ[:>0T7_Y.F--B91\[FUPRL9B+KTX4T3F93M1836I?0Q)Q38Q-=6_Q/
MFM.Z_CQR6K]R>#4SVY@.TIG%RM]0<!-15:;<FHZ:C"$K/LG5.T(YUJCGOQW7!
M_^GG_89?<]Z/OGY)9ILJ"4:XW"252M[B1K(8B=+&QO=\4ZTWE>%V/.0=1G]B
MWSM20@.]47:EKU>+ /K/P0AW#,D;&J=X=+',_EHJ,]*.R:>$$ESQM0$HGB/B<
M8^!7D:S0!W_QX9C.:.U*31DCA#Y>30(HO$V6:S-/UV&QGI7%9XDU\]7YQZL/
M'Z_LB W06ZS,76,SD1>OP!UVC>=VZ('9E"*UC@.J]L]2CO;U7UL[<4HK"H1>6
MDBVCFN1J[VO97LY@.G'H0E%LY(%B9CD60B:5+YM10@.:X-IP:\ED0B^8@./R>YB
MJ)*3"Z:N2I@.LK1)D\7A MY\_"S\W9*1%!T#...16>-P]198@.;LXNKBY/W/9.^
M>!Z'%<CQI-A%1OB".69N,#*E&P8;8"#=1/?G7R;_,3T]/SXZG;X_.O[YY&S2
MC<)P[$_W\OS=U:]'%Y/?55*0WT/I07X_&/Q^H1,W_7[$)UTE"6G5F$<J[6I1
MN"D.UTT@.)+D[# 59WF-Q!X07'.E^`GJ'_;']SJ-!S9[)J110.[SY-N,KY6>;
M4\V5*G1V\/*#^@.VZE7/>V\X:7B0+M']4.2S,#.H!RG[[\%<._FA9YD9M?@.:T
MY%F/[M+JEO&P0F&EDPF^E)TD*"C,U$KV7G2;'[4Y58PU*JYE])2I\(,R.^&O
MW[K;C+![9CX&!W2S4=S1"I$*%5[K10J0_'C\J'$^B))UY%F (&9+&;=E$EF
M+0)B3%_9<YY'0X?>2>@.E3,\:VZ,P"+M-[KX_.S_CZDIK*L"IP<:#Y?S<67E1
M7]A-BM50UDMVU53636/5#-=.']4,MWU9+VU40V$_"Y3%:BA***#*FC^M9_(2
M^'%65==BM*?37$3^/(=9Q9)EDF^:!!IP2BDME$BJ97N)QD\KB,J[6T53('E6
M$[7]3R3-AXG40-R7X7I%9(^#TL^BI-"Z.'SQ",IP/%O;%CG!:<\%%SUFQ5.&
M;TIQ0*X;-/YSV[_,E4EK![E_C>R9S83T-4+@.#Y[!H!]B; _6=U.PKH6 +FM-
M"'N#T5<20NOU2-T.1 N1Z=,`?66'W<5%IAV=\KBUFHJ[=+G$>AAYOF7Q^N,X
MWQ7R'C'4.@.?:SL:>X4K2!^UJYL52:@.SK2'CQ$#M5[G@.([F7Y]MI96#J!7@.[\
M7AJ*,T_RZFH\MEIOD([CY@.8,*L>."(E?Q=7L-BG5M#>'$*J 1<YT,M!3\QV?
M+-<1#SL2SSM?%SC%W3&#AI-^M7%..SOL+7=F\CO.M,N:\X5.R71]SZYST.)Y
M9E^<M7]N$KR+!(W'6Q!AZZGR[BYX89H-;9=F$SC+V+B.\)$^X2<:H3&O=[G/
M@.O>4S-S2V27>2X-<O*NB.>E-O&M/E(-Z\Z(%KK/KU-%:RU8OE5I.8M* : =S
MO#23C\G*6_(,/I8$S:@.I83S-9'7^NSZ?&P?3PGIKZH+-EES:8S4E-AXJCV;P
MK1E)_B01>S6^]>\?XUNOGR&>3<CM;,TT$2'T$..\W.LW@.: CL@._W1'#>&S?X
MB+_5@.9M80OWJBXUN72C?]\,VD83\7S\P_F@.^-]=<CS9QA/)&)"TQ,&?*35[<
MXS$PQRO!S]1PZ8._2PP2OKHX.@.OF_3)4Q%_%L@.V]6!?)9XQ#CS/5-YJ7ZP3E
M/0\N)]7/=%W<W>9EPO3)OHZ(.:?SRL4FDR?(\+C9'0;BB$O"Z)18F5LILF :S
M9,WE+<C7><ZU%<P9KO8?/%6K?4@.1K57^8M]T,G'0-+-[+_=]K4O,\4T.XW]W
M='+Z\6)BQHMV]%SY`@.)77+O+XY$9/3^6Q]Q%SZW,K'Z;QNK,L:TNZ^-';%\@.
M5;^$E2G.Z+@.2O[$,D+Q,XK*BF*LLN=.G_Q?HR53(@.:+413&1" 1Y#M$X:B,2)
M5(OFCDZ\*Q70`%W*6Z(B`'D3%W-X1/L$9_[H)%73#/,\]P^2ZB9BN4&+8V=,
MV!'?7_:=A2R4A7X\-)"N1;AI&,=4<!@.)A'&R%%+J2>5B/-1,P8_FTUE*C%V6
M)V.,R[8,T(;9_,F#]NMRYILHP;.HPM#/VP%BS)(;BJV##J79K) #4$<2,!*/
M%Q$:J^@.]C^T\.3N^< ,[V6MY-M#5<-4S(SVK._0QQLT^"[WZJVT4]B,];0!>
M9=?B\H#UKV$!-.A,W!& 1D[Y/;(O%QB;/QZV3M9$V--9DH*TE$TU0_MR+/D
M8_W]#4,Z)#S_3\P)O)!<2H([ORLC?H(9G^<%QC#*6^20)1S(QKT1'& JH!K3U
MRQ'[D7<,?G0:!]@.82^PTOZVR=]J+=V4B=WF(1A>(B4R%SM 0PA3!>W YF;P-
M]WU[K6V=;AJ_!FI&ECL![:$.N+!$.'J'GTQGE.LV+N[E39FPTL\ VG)KRQ8+E
M\WD9=50-%%/Q\BZ^+]D-BAR=A)2+3AE K&03W[AYE+C;$8'<XMK/*RCY.8>U
M89Y^QB[\*RER1HP-1,NWD7C4'695*9@.XG0.^S:T/<E?V!,L_XNL-!CI#..SI
M7\^#:FU0VC$#U73D;[5.8$FI/+2!@.@.?@.BUB@.+<WXV@.5:V#)'BW&9XQYNF5<T
M/07.&")RL]Y5\.]N4\PX@.^Q]&Z^Q';[TV0L!K YTF2=P,07"K_.2W]%!DR^[
MBU$=O5YH0!3BX1R_$A3ZQL"8]$EUSB_$ES"XU_7@.7EO@.^GC<1/CO`"OE_6J5
M5$4ZXYO^>5HDM$Z7HK4F;M _O@.O-F04A=+F,L'/*`Q([\%U,&VR[TSFW1>BP
M:UB+54UN[S)<:QUQA6EP`>F)<U7&0J1H/V+BC]FS2)\SC.09UBD4D),A&%P>
MV-J&B:CFH? [L.AT8EM3:B=&4>'$F2AE<Y<CT:XR!6)LW0)G3^\&J/2;^"D
M!25$ZI 0?0S!,VY37*%A;*+$*:3@.!8FP1H,(;4KJ=T(=0VMZ0' '75>A0Y'P
MD0H:XU2KQD]'"#LJ!]2U,"JQMS].R2\K9MG)6*P[8=\#I7Z8N&+>-5#6;Z>H
M:YD<>T^<"OQ*27(P>!<]VUWPUY<MI,!\Y?:PL;0V?XS#=,/J!)I3R%):K5]*
MS]0WE5%XR9:-KA!:Y," U2/EY]C%%>.VC,,W7;3;\J Z%7G3E2?,;^//N(+1
M_JO,558;L9H;:5]H5I36YKP0L0B>!XGKWKS/+&30[F _<=?)_L(SR QYD VN
M12!:<'0FKKSB!ZA88,DS9YQ=F7)((UGV59R'PKO<3"'GZI]>T(S%-SKP$%OC
M$D_DJ*O+L_9P0&Y*"$=+A9_OX^*3,W!+!AMS08)78&^LOOV7Q *,Q4YV0RX\2
MB7$,JM9!`-UP.UV1+)!#2,L1^5QF,8QB]W\C7MTH3PQTM+.S-TAZQZME2GM^
M#^Z8\;_MW3\^)'5)'EUL]_R9=#P*2Q>RC;QO6)^CE$XVWKP7!!VP+^AFC=YG
MR5TZ[P5"SIRD]N&8-!MIH2FLCY#.U(W#/*6^OH"8AT(;@.=*1A[J:7@.8F]V'=
MMF+I\'[!99[9L;DZ]QDV+I^BU4M*6Y*^VM;4HW0D\W2Q2&3ZD[YE\/*C50,3
MYT:H/CPOJE'3RH\J3NVVS8ZJP#SW`HS;F2[K4IPX*5;PG*@.D4DZMC\Q A\K"4
MJ"TI.W-HT9VL!WJ4'X5(@.3<;27PM9G4?]]@.B^H+\>(''8WHPV!L$W0J/Q+&'
MUXL$K2LF0RH)\GAV=*= 72FD1-)8-]-^+OP(? VP-LBX&2G;Z,R-999$A@.C3
MEB*[3-WH`W?(C]VZ#R!,#QN]7DWD-?%^J'DCA*3/T CBHB<(40:=-$%]>HC;
MRB#GV8_[7\5VK_Y0MCOA%A6T/(I)CD"6K.^1G+@.9K=HL%IP<^.T^*B OO_-%
M'(>69B&?<(^O^#P9C##6Z$/R$2>KB-4GX96?4*[=2-YWIU4+1_Q%+)BY5W[<
M[+O,C6*JJ6=/=<3LG+DL7"F0)9?YZ7E9\,I*3+XQY4BTPJ B!JK7=+8IZAI=
MI66)RP#N*2+SUY22`D8@.1V;+S1S4;5["_"F+! P#H::N$]CG)--TA=%O8GK%
M,^J^> 1=3Q?W"L/3,KT!!(#,BUC]2>FZX=4=DXR8N"03K^.!,>=9&>EEPSPP
M&V K8?2O\C4#_IN3G,5-4[X!3A<1$V3 !R&=<7,^"F9AMD=A*'1]O2[QE.K\
M5'ZBHBC*D#I/XIK:-C1 BW\.308Z%!QDY;&N34$M/X?;&4=M9*)M6:KEQV,>
MCT^<Y-+!S-&AG-4U%[F&NS&HYQ'<3T=L(+X,_H^3=@.W<!V@.\WLKQ;YB0!N0\
MGMI##[IV__M["%J9WIZ?3:88TA/8F3GV!VX(<L=&)B%A#J*]KE^"_%>&G<#:
M\V'0DG&=[8S]]/'D+<.;ZN:FT4UE\PDM8E9 `U_MZA:Z^B6.L[#%I1X3^C-6
MMYZY2TYX>6RYY/C-;F?E!RY3`KT!_OIO6J&^GH5]9>%!//VD2Y5R4VD;0>/B
M(&Y"\%8)<89=[61"'0]L*>W5P17J:NUI+]\#K?HD>.@.O)R$B'+A'^"+2W4.B
MW5L/?"<(KRO^/6P@.#V^1K$FW$I3WC?D>HH#0BQKR?QATTFCWL[<.A@.DK?&_F
M=EMM3:L-5VCZW9!/_4!2E/Y&7N6>^OY?XB %C5^$:2,:_$,R7XD86$ZP$R(A
MFR#0;HGZQ0[H%\(S0ZL4/,*4O:9-5KR9HXG_)JEP>+V^,$J;&!_[22?,'!/J
M:;ZI9.BAZZ.BG23^(MNW.YP.CZ/MJ!1WM/(G+,MY2,D-A>")R]Y7UV4%.FN)
M@.'EX5(QAP&R^6:WNN;Z;<1B[U!KA`'#5?)+I_26?,6CJ-L43QO=NX+(9&]SA
M`(U]IE^?]1#?90'R%+^(:W#U4&@.=GG(9)]%)VUXZY-07$I6[#WIR^B*FOPVE
M9.'H1SDF@.IJ\!!_>86/?2ZC\^;A6IY4:J'942'-0;,Z'$6+MD>#4)$%N](&G
M0#*K^$M/O._7J'\]``HH^\30D8I?)/.8E*?M7=@.-V:+CLD-RQ&8-M<T*5JWC
MC3!SZ/"//VC:[0`*8]KA#_8_8L?G1Z>3R^-)#].<"E0*X'V@.BKZ]...KT44?L
M"M^-!.11C3VM)EW4M<,G4: (YU",,!3_K8@.!9T+.+J_21 P/&D'BZ>?.+?:
M2R9\9#S++6 U+FQ+,3I5^4DF4XUW8H_U%4Y=#L])O5%CD7O.,X7$BAUP`X^-
M;[)Y4BS)4,8]+:$4(<H!OYK3(2DI^8B$_Q_4&_+YZFZK2G^^\VY/:EFMV[LZ
M^O'T_/@.7]O/YZ5O\(IEZB$GN0\T+'U\/(?1#63>,#16QL(YD(.R42=& ER8/
M(BPJ(L4]PK/ON=KJ70[X#9W$(!2&<'XU^8%B_7D\1AM[:A #QZCH44 B7<DI
M:4-DZ9<X2;,GP@.EOQ+H`ZPD0]&#':A,J<*"<%ZLBO;G!<[H"*70E_*.'S\_'
M2I#>-1]"*?W)W\$!EA;%/ %Z[F4KCQ]BKI:JE07@.7\%:D!"@.QA$F*5+&-9=
M]O\M-""/6C@.B7-SNP:6X/#-U*8_LJ%N,YCGW3<<W>--'DS@.U`BM&)(@.X:-EL
MJ&K3"N=>[@.> M[O]0HC\JJB$;[]1%K(?S.@.Q%2LF#\ID59%30#*JW#S7,[O,
MF0QHP+]TA"7!Z%H*)8]GMP9Y>>'^(NQO6'.J9FR=-Q-*J[,Q)%H$DL8@.NT,S
M!-,*X=3!=^-P'%[GL&W(J!WA:OVRR_'],D5ZCT%SMV%XYT'<1W9Y"OZ?\JNS
M0B<%O&A3<[^K@.T\;E2'GLG@.\O$:WYF&(X+ KUQ*5H5NMNFE&QC!Q=2N]]7*T
MXP?#IKS[IC P.XGY%7BP]Y/7-VE/A2 G(U8DD"S+RUJF!97)=')E-Z35."RZ
MQH912YB6# UO+,Z"&1]"YO; ,+.*OFQ7)[BAJS8.G .R]6QLWXZJTP&:TRFF
M-#BGR*/&M,DY7A?I"D^:?$KN#;R;P@.UO[FZ<$1EE#(H#OY&*_LIDG_P:\ 5(D
M]C3#"2F9NQ"+?V&CP?Y!7VA/).<__"+T'5?2!J*9V+NT*"MVEW1AA(OT!D,:
M\&S*G4S'`<,KT>BP)0Y)#45G2Y6?7W\^.9W@.H0BZP<2][ZLFJYO*@._H).H '
MC\[>3GZ;'I^?.J>5(H$]_%L33L=!!$/UY.<:9.HG_]7C.<;*X4$=B&!C,P\E
M%'P8/S@.\L84I`O:,8"X[=2Z!Y"9L288!%NI(<Q3:HW0BGSB[MTY#B=T !CY_D
MG"+%U"Z>!Y>71BU1)\!D=704JN*'?YXH9-I/NL,''[C#2YKC:^_PJ@.M]5GTR
MIN.)"$:TI$A&+5S*7!A<N+S)%M/FR+R@.<K!(E\O-6CAUT']3MX]Q-B[-@.?>R
M5*?>4&O)WW=YH<]W4R)#[CA@.W'' N.> [9!>*%(H\Y-)Z VDHK6GFY=)U@.OY
M(?K,8[(:8T.CHD^ S=0%)OZVZZ;NA(:D5*.F&JI@.[80:C[3H"E[Q1YRNL3MG
MG+4!<IY*4ZBQ3C:D4[5!V8=K#D'R_6UR@.6.(ZLJ)\S5\T,%2K 6ZNWG[Q^6,O
MW'[(Q>$/NUR]_OITN^#.CO;A!?+_;DO7W&HYWZ*=27NT/LT^]JXZ"XJM'Z'"
M9GV<K]:GN--2CM+]06MUO^ZL&3^Z[J9J,'ND,A/I8F+WH:\C\Y,^\"+C%X#W
M+$&GH]QYDS[G'CRIVPZ/_4;KXI+]/" MSMP%#0C^PV=MS8SH9*(]2@.0*P,;(
MZ:*2<-Q1U%:Z6B_O@.^UPXX,1:7Q#MUW9QCS,`T,-4<SD?,X5X4A9NR*D`6WB
M"3:$MRY+ZP>FF*'D(Q7J.S.<;<I'D9>N0DR5_Z_:4O_W&# ]#)4(.C>/S]^]/
MKG@..HP<Z.C#)(+H5?%.J(/LZ>Z'^*K,YH?M%=/V'X+4!>'G\]WZ(<>T%"H1"
M'-3Q^<>S*UNS"=W4?'YZ^N/1\2^$A\NCXZN3\W!*)[.2@.3I1Q4GNYXYR2!Z*
MG\Y%()E]G]G?>>+U?^S^'2@.*_M5Q!/^PK[3H^OWJ(L2/']X>74TZ#7"^_09O
M;^K\G<_D/\8[P\&KO5?[PX/1'L9X=/Z.$R8OE/\,,,;#E]]^PQOO;&D='L_R
M3&R<#_E7685GBQ"1&-U(OI8&JNZ@.R[%R,3D^/WMW\A/:KG\]N?J9G8-6<W'R
M=H*O_S]02P,$% ````@.`J6.D,%Q7),IV"0``K"4``"$```!&:7AE9" M('-P
M7V%D9&UE<F=E9FEL=&5R(%-0,RYS<6S-&FM3XLCV<ZSR/_0WP(L*ZNC4UF9+
M1N,L>QUP`7>V:FHJ%9)6LT+"IH,N_W[/Z4?2W0D(SOUPF1J$[M/G_>S %GZ8
M)@._QXS*CY%)\3((Y)2YI!+-9^DJ6BRC(*6NTU?9+,%OR_6YC?^_S<']OY%T-
M!S?]S_<CCWSM3WXEPS^\T:A_[8GM_;U@.EM.,++(TI!'280L_B*(YS1 [I0XQ[
MS?T]`J_+Q7(ZB\,@.C].$:"^V8LA36U\[/B Z-.?YX%CB";(\#F>46*\U>!2T
MB4-PQM>VP/%7&B=$'+'PX(XO26C8UN 9($3Z0/(G2O)@."EQ-:9P\<OPT(GG*
M=Z8!4]LF'<%!. N63!)*7H(L? JRYDFGTVFU%1W)JH3\>QG,XH<5$D+T7)B#
M8T-NG<HRB?]>4O^9KM1NG.3@.$9VVTEV:A=2/@.?8L1N_Q0=8%>TIS,HT%H.,X
MP,4-PI$2CM!_8I8C&\4!E,^1"#-019S[;#EE818ON.$E0AV?`",&F%)3JS=&
MC^06H#E)TC!=`N]IHE:/#\3?@.P-R34$]&?<O=B17)9J(;T'$*#Z!MR!:.0XH
MPH*(IK[M1-+V%B"X<QR9#BL4'4<TR>.'&.QEO2P,Z&5O8*B>\),X...8XK$K
M;6Y"U8EI,U>*Z110Z&A^.OV+AKGC%*[9_=!I5: X50FZ&5(`^2\Q?=T>)P<G
M-K@.EE "M%\H`?*$8X,',J?,`3K6$6 -0U<J9*8$NYGHH6T0;TI3O-;&=JEZ^
MC.9A&AE.O%X,S0>K0'S?J=43RX-\R<AF(F$Z6\X3?P9Y0M/"&28W`0G*@.$PP
M#YZASF"Q"9=9!MY/(+\$/&_&C$ BAMP9$4@.KA)<AR!F+HI:H(*?_T+ 0W8VF
MZ1$4KB_CJR<:/O-3VB%Q(GX@.EY=0^X:CGW_I$$"N3L-7`>' PC)+2+/;JLDX
M8PK<QOF*<!I'Q?HPF:UX9AZO6$[GI!...(<6Q')(3$&F.>RTDA@.#72LHA-VT3
MN&Z1,$@.*5%!X29 4-0\*2J 74BO/&2J /%LH`44/D4F?'V9/M@.+(S[\00P5\
M04#A2^BA7@.UWD'7G%.L3U\-/>C$NE3*1E4H6/9%E0=0$RPPE@._O;6V)*@.]QI
M91T<`8%*GJ;T,4[*KYS-(&8TRU#+$#]GIVW2[;;)(?S7,+6L,YJ)U1I-(B4H
M<E$MUI(9KK'J+G1;C7?RV:BB:^S&\$;+U/B.,(W1S$%*L"P3)!&9+UE.L*E,
ML[EJ;;+EC+("$09H6;SL*HR:-*CL;- .*NH<%;6;2BJ*^0S-!+(OBC@.7KLA
M<KU@.DS<YS!2%T1E6&MD$N )/V^XO7/,K><C2.69LGHTT$HR47+\^09XBLJ<W
MU(5<WM_=>:.FC&&:M5RQ<'D)2GJ1WLT!"Q _FKJRIVFV##L`XSM:`'K2DW-E
M@.;;!W?;V<)"\J1C,MHXC:?/6D/\YT.O"*R7/"<PWKYC\8=19D=<`R@.2X882>
M&*.SX9EC_H>GCK5=K4LX09VDXQ1R-D^ZI^>ZF$;FX+"/*="]Z?5O88822UPX
M@.W!=][L%X8OW$.8?Q>17[U_8/%N^>2)=C7N"*QRB$*&HBH)(A:Q=:&2108EM
MXH:;% 3*0LM3Z$9ZN*8%LXH]U:ECF1.?C/C2%<_L^&KJ4HN(:3)CJ3S1OREI
M05&T@.@.E?G[S/_8$9`*->?RP**T;-V<6:O#7R)O>C@.1DGWN!:?=PBH<O.H$SF
M? /C@.E',98%(=,6,#2'/`X++'*64B?Q64WJU$SLFB;,/NZ9I4V!E83$@.N;S[
MP>S*FU&7O[?+)MY5'_P%`J*]V]:HY)+BH^$C4D1F95TEN4RDG <U[YGZ>4\*
M/3O_,>UH[E#4,6!$WD)4+C#J"Y?6_+M$:=28?%Q2U>N;VG.K]R=5)>HU&8-+
MXZ6BS9K0,EN"DPNMQ[.);Z%@.B#9=P3B,A"*"0)D\4K#!!^56N SQ>:Y1"Y>S)
ME8G#',\1PF-YS^S8FJ^!+A4AAEL+N9B!7?6U'F<!I*WQI"ID`P6K"4MYN3(S
ME-3"T#!L<>G0SPN'Z,)"4;A*5S+I-H:?O.N)OX?>^KWR#_*;DU3]E7`>[O
M]\.)-^A]\9HZQM;:4]4#$E:\UU:H1_R*`RG.H](;V\:02H;WD[O[B4HV&JYF
M(X3""066"\HELV6 M08)F.*6P^BX<9M'D'U:<EZIO#" VJ67RZ>*OC HO__;
MUIIFC*\Q:8T_-7X;]@.=^Q;B6EUF6JL&C6<W>;6W&X-8?_=]:O0S!+4Q?$6]W
M^U<%J7$"S4*\\VHVHBQ=;'#$UEKGD7VJYD2'A^2_/7)(/@.DB\)4XNP>I.N-4
M@.T*W.8&\*4;_YA*[K!;JY AET&",C(*=F(-*<_AEQHJ)3>CH'%YV'%6TM4-2
M+.?'...$2:>/Y[>2JH-A:./NDZ(6=W4.EWKBUN53H4 9 <:&74W!D?'Z@.T.""
MVZW/:V54V#NXV'XKE&JW^8[H.,H,I-=E;CKO3^_J3;9!LU>]L4>^_NH-B/=G
M?SP9-\G8NX441_Z?).(`+3)!-KO$NP66.WQ,@.-4R@.#T>VI7T48Z:E6*N!KGM
M\LF:\@.')9!.6VB1OS+PG'_1ANR)\N^C'Y5&MB2OF[KI690?9Z B7;6:Z:%GO7
M$<0:-WI@.9-6EZWVR=359H-Y]&NETM?Y9,O/>JQW9T ^&$QE-,%0+91R\+;2K
MB:QIS11PIZ&[G+/P$6IQ*9]F,>@.DF)5W9'C9B==(+"WFI#<&]#77BE^T2T0Y
M>(O'OEP8MJ A7HSR,2>0.S@.>X45KP!W,NC$MS(PJ%?>0-2HMBH9B4&BUXC2H
MV7RUX-?3]_JE\IOWKB<?WW?OJH^JO2@.JGU;+Y]EX2Z%=U]!<K#,4.<Y135PU
M,W%]FJ-8I8(*?UNKF!K$XI!04'F]YNK/&= BIDOB"I_V73'TZ[=#;P?82>V-
MWH]&F^8>"5#+27\P&=8+W=2IRNY77JGHMR1M8H_/<L4"*'].T":UQ5>^^ ]/
M6-.4637?ZDK'9."RRL&EQ<)EA8>:#H#8+^UQE[",^72KQHAFZUQ1 /5:&94YK
M'[8)Y:^_`BU86?OD36.MRH=X5XY1/D>50#^)[V8N//VH.>$FOS.?=^(_\9L@.
M:#)D8W1 ;D;#+^3;/&"@.\.]'WT!N>"_ST'?LIT:>NDUK5'X^U$"$]W?7O8GG
M;$"SOS?V)L3Y)IXS?W</NYV+TXNS[L>3TS;VS=_PP:G/PB<Z#[!P?W>[Y_M[
M@.K:SF3C[@.9]1=;;]&=6_4$L#!!0````(`&.2!2]9\%($@.P@.``&@.>```C````
M1FEX960@.+2!S<%]-4V%R=&EC;&5C;&5A;G5P(%-0,RYS<6SM65MS&L<2?AZJ
M^ _]= !'$$"*K.08EV5I[9 C"06$G93+M;4L`VP,NWAF5I>7\]O3/;-W[+
M[+?(+BXS/3W=7W=_TSO(K>T&_L);AH+#&_/1=S8<!M!PUNO@.!L+MW%%<-O;B
MZ6MG'>KY7J->>S^JU\;6R>CBW?#]=&S!Q^'5KS#Z8(W'PU/+3-=KQV=7UABV
M(G#YG/:16_M\X@.CEN6N._QT_W-9KK/EF&\Z\.82^]S7DWIS[REMX7.#&)'M_
MHE6O.1(72J[ #]P@.]!4$/@.[,4:M#_L@.@.%"ZWE3-;<V#^M2/<E2.:_9?=5E:,
M_%I[KHH$*^6"&Y\+C0YC\D[2I]ST["_N*C-?,JV5^Y[[A3'/5X6%Z!Z[-R[O
M...>.)@.M3UQZ_L=7=EM];I"3-H;+$C9_R7BQ#;RZ5J!9P']) T^0=JX94<.4&
M<Y20&TRC@.HE?0V=-$9S;6DNEDIEG(J*E[B'*:#XQI01PG*:<JYK&J",,#MI6
M);'A8LEMS$I[XX@.O;K .-[X]\Q04_$GE0G^W) Z10V0UI!OB_W8;5 `S#B["
MQ>?@.+!07$-4(>!(HR<,MZ@.,'9#B3KO!F7%!UL1]?U&N ?R]>P(2[H?#4'9RL
MN/LE&O[1O%M_6"=)8+!^Y[.@.HRM1\.W7ER8>W)E9$?OH,W;["0 1V-X]1JZ
M$(AT-0T8*?K#T5#XT.RUM#V28UFK'? -H'M[T.UV2V7O03B _U>JRNUG*F4`
M&^>VJ3^W8"&"#0&MUT=H2KA9<0R&(95!Q"Y:$T9AB3CK.@.<*S AXX_APB6C#!
MRNP65_L@.DLT0Q !"R87.[R;6&Z4UBXTQ*R4S9A@.;M+VQ#28S0]Q%K3@.DU5)N
M1X[C!O#[='1E71R?6\W4FA;\`(U.`U^SLXG])FK\EKM)@. <Z,8@.I5("F1!CM
M)>0!04AY[2V2%:]>FPPQ&4/?LEG!4G#))<]'<-1>=+9HC&,.UL>$]E&61R]U
MG64)<@.#IEST@.N%E*DCB;?(XG$SJF\.&;#J&9RO(.SAJD3"QG? !$(;GL;!_/1
M)%FZ*":C\C7:@.MR2PKDS@.,) -FE*,E@.K,6<F9I#Y0%"6)#91!$-^^$AICRD4
M1$ENF^2BW%HAR21!,/O/N.M@.&@./Q&$X*CL&:P^P.D+BV<H5*$ 5-<,0Q&-__
M'<-;OO1\$^U+@.407A*1VLT$Y6GD^T:H"(2B";:P2-&!]5]A9:BO)0KT=,951
MB<LU_Z".>>#Y2YA[BP5"X5->T?<V./,Y?8BI,ZUE(MB"@.S3<Z70(HG8[J:C\
M\?24FLK'S]05TJCUQW!R-6GJ>$ZL,^ODBO7TEW?CT3F;_#D9O?T-!R<P,KGY
MVVAX`3@.\G5CC"4S-(!M=P*@.S'9ZB05/]3L,?[7&%AMU:'\*>=X"DCB^.&73
M9#YE**K*M];[X04)?0?7F75Q2J]G$^NI.U7H,@.EF^7%*PZD(MII/"F&E;"1N
M*FJ"X00N1E=P,3T[:^E2X;>>5!*:D54OH,#1F4*+S"RJU.>#H 9C&M*%Y?A:5
M`#.<VFS,M9U:G% K^*[7:"JMX$[&C<O&Z>&"7!:Z!APPW *:C\P6>Z"WPYHE
MTSST(6JQ#;.FV.18#I41*?CA>IWW@.?J.;"=%$.168B[8>H>&M I!T/P/5[ Y9
M2"\-I!68:H\TI)GU#^-I`*T,3]:]5N32[M@.\$!=B_C0LN0@.D1T9E`+)&ZKXQ
MMC%>^D@.36:%F8H(DV*0QJJ0%H&TC22-HSIF]Y' I[)QI$HN&5.ROA+=<<O$H
M$Q+97-?S1"-*MC ])_7!GK\(LKU=MJE[NK,R0%<=!:9AQ4IT?.KQR:,M'FW:
MXZ@.'PNJ(I:CD\+-4CAI$[_"?G2URW$D.XCYR1SYDLS4.0D/"RJ&T57RS#80C
M[J!IDBVJPWZ+G'5@.R\7&\>FXU;/-;(?5@.Y;)<5),S5C4!&42/B^.#Q:YD7Z!
M/>.C(M-6I1S2T2.EQ!*?EWKL$BW"7A,=RJRE!&X,Y0=4W&AI6\P28IZ'E YU/
M)BN/`GAO;4Z6:"WM21-22KS)'$9&0^IYZGOU$T6%[S0_2#9)M.5A?/2IGN,8
M5D5&1:F=W)N0KY]O31-B(&UIMXDTBEV?R7T\>A7FGMQ+1E2PF4D5^.;0N-<F
M1RRLZXV:0E2/[:RZ"V,^I<#3[FVH,.'43SVM:>18\[L8A*1/#33:E(]@.D?
MY<XG,^^>I"D'TQ4^=$I&`8V,BX_&0>-#H[2!>W*^Y/1G-3TG78R65O6QE<^4
M'7EBFD?V#*34=T9*?1.DU#=&ZAE 93/UNZ&5V>2?0I91]<UPR]RCY*\#J7:I
M'[#-=;.ZLX7C1\<O[8/2UW@.^-).[R_W#5MP4M79I'5N79\<GYB$G,X,'2[N!
M+[:&_]$]-&2>2K+[4#QO34!/M,9B.^FLZ7XQ:GI_*-PB(?CF)$^U&G#SN]QO
M/#7F.91CEG\:RCCV+\[/PIDZ;/1$1:U1>F(F)R4^B!B!^$%6_A>&2Y_.22Y$
M@.,VU;ED#UPV%:=WF&87%HSB")WN9EMZL5:Q-#^T'%J?.B.!&YI4LN;_"R 78
MJK;!6YC[*T_J#F+MR/@.J0/LB^((>&A1UXWR3]*/TO%49_K(;X_B:,&>GS@.%S
M^?;J=?1XI"-6YGK&ZN02VBYQO0(Y,V8GD7L:^B65%BG0'>H@.O80V/]NUVV!N
MJQ 6NJF"3QL$EHO/G4_S68"O:95\!GT1%9=)H^07OH966#+!>OV#_:/#EP<_
M'[%+8#W69>U>]^7^RX/>47^?]0YQH,OZW>Y^NWO4[OX$O=XO^T>_]'_N'.SO
MXXP6P(5==K!3+O[79]TGF-([['4/>WTTA^WW'[!$"SS!DBY94J]-+T^/KRRV
M`]UZ;6)=`?M$CX*A_#S(X*.OLS_-',EMZ6)V.S;RY>=![[!>,R%ANV-2K\E_
M\!-P][$_`?\-4$L#!!0````(`+=CI#!H;K=/X0,``.4)```=````1FEX960@.
M+2!S<%]-4V5X8VQA=7-E(%-0,RYS<6RM5E%OVS80?J8`_8<#]F"KLPT[+99@.
MJ M[B=P&3.=A8,02#0$FVSE4A5E)+TW^](2K;L=D:Q[$60>+R[[SY^=Z+*
MHUB*%5]7!8.)?14T8S"&#DU3^015GM"2J4ZO,3_2M#+V4<=UW@.>N$_KGP <WL
M\OUMZ,/=Y>(#!'_Y87AYX5NSZ]"T9 7DA8Q!Y='UG#W'*:T4<QTR*>DR98+'
M7X"+$G/DU9(G4 G^M6(\8:+D*X[.@.%&4ZRA6@.I"QK$0)4KA.PC"206X"@.GBD
M1;RA1?...<#CT6O85UQ@.P,F9I+7^67#3)#Y8-L%W D].]>,>M2XI C^ZP>*)#
MV"<'L M6QC)A%I[KL&<6;Q?'EDQ+(![9JI"9J67'::\-1588H]^'CU/-8\KB
MLFT=PY^WP<*_F5[[74!,1:1C=BN>>.#!K] 9=/#9VF-4XH'."LE2#M0W)9>?
M,:J"IPU#\+6,=CET!7F!I1RL\15,)JPH9/'VW1!DL:U0?^)K58CNR*NQ0Q_^
M8&LNS&=3QO<EZ.0>6'3?(3,R@.&[M;2(10G /&AJ/C!5K1HN2QRG;5H24-E5M
M.?8:-LGD14RZCDY-=F!=QV0E[)FK4G6;8D='(=HBQKI$*I(?(X86E[Y(]!$T
M@.EM%,9S?AO,@.A*O@.?'H%L^E\$<V"\&X:7L *SZ:!@.7FC)GH/=,-$5M.UI+&W
M]W"J:HE';K<T8(W7CR%J\'84C.N9@. $1!X3^] *"FZN_74?F3&C$R!SJ90."
M/9>6'%T&ZDSN&KQWT'*:7(Z'U9U,C'.D2EI6"MZ^@.[[6&EE:D9& ?;+E6GMWP
M,!U'CLI[+1'EC/(4YR_NQ6.9*MBP-&\&IN;<),WH%\8%RJG4ZSUX8A!3`78)
M$E[@.J:3?`,.5FSI4R;(<+!2JM,.RXBD.UQPRB?3',LN09V5RH %,32\<?V A!
M5>RV:8'D>.X@.5Y!OL(/A;##0&_54;B8P_A?TV9NJ<4]4R">%BT.SV)!JS%;7
MVS:L=:U[HS66L%V@.>Q.@.&#]ZT+/6'<%[5JNICI8SJ2LQ&OA%TQ!G"70-Z![@.
M>XE2\<#\R1#!6:^![QGO_7H.A4/^Y_B&CXY1O"EO6]H`N5OCV(AEJF'47QXQ
M#J29?2V21]K"=$=W7HSQO[24S>TZ<2H5LYV9,'V+B/$&8;]=IQ[H0Y.F5O[O
MZ-MR(H=>I/47:"X5J,ZY?^6?+^ 5S,+@.&NXSJA#-P^ >?T?XW$W2![C[X./E
MI+G8[%U"C&!N/UU,%SXY$L)UYOX"R+V=$P_C_FAX^OKTS>CLY'5/'^&]UFRD
MX@.W+:/2(,<:CWUS'YB7_GEB]X/XU_-G[US]02P,$% ````@.`=9'Q+F(V27*Q
M`P``G0D``"<```!&:7AE9" M('-P7TU39F5T8VAI9&5N=&ET>7)A;F=E(%-0
M,RYS<6RE5EMSVC@.4?C8S_(?S!LD"A4UGVX>Z`TV<EMFD9!W3/F0R'E\$*#66
M*\E)TU^_1Q*V9:"9SI1AT.4[.OK.%8DB3%B^HNN2$YB::1YM" ;C0B[*,/4%9
MI)$DHC>HX,<H*S4^Z74['Q?=CN^=+SY?SC\N?0^^SH-/L/CB^?[\PC-PMS.[
M"CP?;OS%N7>AA$017M^NB$PV-"6YI/*91_F:0+<SE5&<$47 <1SQ+-1L@.-M1
M^E *&;(\>W:<F$K4>:LTIR3)(L6<HS:6$L!C-)<6P.('FCH'VRD5DM.XE(S7
M%QW":>P<0XLRSJC8$/XR&JKCAWA.?LA0$*)8Q73=YJ4=X1Q#Y(83L6%9>F"+
M\1E-OL%1,PO.$@.3RQX@.GFXCWS\;C$TND"D$HRJ)@.7!H-@.F0DD98Q[G1ZZ_D8
MV,^S:^\(CL:Z:1PJ6_LG*C3=SG (_\[@.`T%#U-*IKQ2LY D)V5-..-0.:O#O
M9931%26I5F=)X%<0>2#@.0I,W1HJNK"V@.`G(F(2^S#+'8$,+0: !N<-AT7RM%.
MC[/B;*L"B#F$@.@.*8VG0>&,T5IU(0+J#4>P[+@.8U*FNKS.*K=)W0+< =CH&$=%
M4K-L7=XF6C$\8N]_RT7@.J4CT6PI.X"_HC7KX:PG4UV)8')*GVD,Z.I5Z72.H
MU=@.9TG3OT MR;68G3=@.]=5&3)_M9YNYO#.P\=D$-VE85`^7M+>%K$G%)DXP(
MT*X%S<<UM-1EKTZ[G=-32!D4A&^I$!3#DFQ(\HWF:X1>=3OD!TF:;N%"&K.1
M;D><%%EX,[L*.4/&ZDR;4+/H=E3<=BK>O1\#XS"=8L=;^&J%0,ESZ$]V5?"+
M&S<D*ZPFA!)%(OACE2LVM%@.&-\M@.8'4E`$L&ET9"I<S\LN("[]Z#X5;=K39T
M6MD4;[TK[SQH.@.4J]@.-_?MVW*31YU<;2V""U%W53G^EFW6KMO4,_-#?:3::>
M#L 4%G[:3::ULJ7JE'6;J8U;_R'N9 ##(>V0.UUPC6#=IMIE40&BEMEVN&
M0[3NUFXSK<.T'R0<]X/4SJ+AD.944BRUGP1V10`)RU1MJ1Q?89BC-?I;C$QV
MVK:.K0H^4G6UB4-MR@.!V0T-;E^"N0FH%QFY3AU UAJ84S1\_MH)=?IW"I;^X
MAKMM)"3A]Z,[3!G\;9KK/7S]Y.';H'I\_.*-T%-JES<7L\!S7E"F\CH`YT[(
M2);BWAU.QF_.WKR>O/W[3*?$71P)$@.JL\VT4/J(.=_)/MV,8.+]#0?S!NVG\
MN^^F_P%02P,$% ````@.`MG$!+T.6BAYC! ``1PT``"4```!&:7AE9" M('-P
M7TU39V5T=&%B;&5C;VYT96YT<R!34#,N<W%LM5=M3]M($/Z\D?(?1KH/MN^2
MR X0N$H^E0.W107"A=!^0,AR[$VR/<?K>M<$_OWMB^VLK4 /]0ZDO'AF9Y^9
MYYG9#<O#F&9+LBH+#._UQRS:8/#!BM*4;J',DXAC9@.UJ\V.4ELKN6?W>QVF_
M-PO.IM<?+C[>S0+X>C'_!-,OP6QV<1YH<[]W>CD/9G SFYX%Y]*)Y>'5[0IS
M'BU2+()RG'$&_1YZGY<+DD"9D>\E)HEX3)8$%_U>I,P)CM-(XE0+,Q+_#0@.A
MDG'3EN%M&,6</.+]-I+5UHXQ*KC,7*QBSTQ^,HV/1"RMS-EC5,3KJ+ GKF/Z
M%'2[*DD2TU0[[@.G#GK,XE+%>]/A>4HZ3L.4(S8[>X:&SQWN'[D5/6:T*?R=O
MNO@.F:HX:P]Y",UX8*,:.]F-8\,?;=17*.(+AD.4X)E$*HJHD3C$P'O&2P9(6
M$"4)R5:-)5IR7( H1,[6E'>B-C$G@.'XNZB[PG.;@.F2+RH:[.H$.1+XHCEJC:
MVLJBJN4,JK+YZG70B,>OZ$3+@.FY T+O!Q0I7F!ALUUA458O<ATKM49: K1/Q
MVY4469G/]5-9^NJ/%HG(<?'<P(?3VS-AWJY)VA!+&&240U:FJ5RYP"N2J1 ,
M\P[!/HAF?,0%M[.:YX'AXE3+-#MMM<L:RK<Z;_&XW&1UQCI=C4>FJZUY07.Q
MV;,M*ZBK;Q&VBVLYOM?:LI&Y;UW=JLJ&]?0(+?BM8:&UJ-LB_E]WTWEP?7H5
MV+N .K7A\*ID'!*!"_@.:@.S2#39: GPCCS%'8"QP76$Q$M:*Q"0;U?K\V)=#2
MJ4N@.MMYMJ$(]\>=<3=(OE@.:@.R)',:H[Q$X[!MA0>A44EV4U(+\59LB_MMIJ-
MU%L&$6(XA,^G\&>CCMW(HF41XY!N,]E/S<!"YA"*4CFG$YV9Z;,36L?)[S3:
MSEN4M&WJ*MB0<)4M:H/TH1PU,54G(H,.6O7/-THRB;5DN&!0UEU%,Z"C4@.FV
ME._ZN>(0T='+V"O*%'H33!>\R5"G(B8[1@.A'D&Z-)/6OT%<KP"SXGH/$[VY;
M$Q\TBZ7H;$MK_!75B6<Z'PO$X=P6?[*@.HVZ#5FU@.FU-7!6Y-()&I;C(]!*#F
M&:&ZO]2:SNR1J]3&)M)VXL+%<627M9I$3R0?KN\N+TW#:R?$?W! P/[3P9#:
MOC.B1O"'@.>NM9T>UQXLGA[P#B'[@.\ O'FSQ4&X7B=!759/J+3-RN295?'% 7
M0F9.4]T-0I"HO@.(*E=T&E\'97&CDPVQZ!?>;B(D3^F%T+]0B7G<=^@.!?/P7B
MEEA?0_?>%BT5<J\)C3W7_=T[.3J:H!M 'G+1T'./#XX/O9/Q`?(FXH&+QJY[
M,'1/AJX'GOO..W[G>:/#(VE1#F*ABPY?]:O_Q\A]$QAOXKD3;RP`H8/Q#[ H
MAS=@.<=^(Y?\O3+]W=W-^.@._0*X3W>[?!'-"]%NR#;Z :2,7>+R*&0Q:O\28*
MQ?WDP?<F_9Y6"?J13/H]]A._<=Q_]QOG'U!+`P04````" !25Z8P< 3.)?8(
M``"?* ``(P```$9I>&5D("T@.<W!?35-M86ME97AP86YD<')O8R!34#,N<W%L
MQ5I9<]M&$GZ&JO0?NBH/(&U((1SO>A_"K+0QG:AB2PXEK1]<+A:.D8@.(!!@.,
M($K_?KOGPH $Q$.BEQ5')*:GNZ>/KWL&P^>3*,]NDMNJ8' BOV;!C,$0W"!-
M\P54\S@.H&7<]/7P?I)48]]W#@.]\N#@._&HU\OSC^<_78]'L&7LZO?X>*_H_'X
M[/U(#A\>!&G)"I@.7><1BDL/GDT^7L^".L8=YD,4T<'@.`^#F95Z&0KC[\D=-/
M3XW>),0HB=5HDI5ZA%A8$]4\.7AZ*?_^^ K>LR@.-4($@.CI,RR;,@.A?N@.2((P
M91Q>_2CI8D5$RI"L*DO^KE@.2LZQ,;A)6+%&%`6>3+(GN2)^EL ;_R).L:,_-X
M64"&:D33H.CY@.WX7CS5TVCB3-71";A[^A4OK4+AK4,PLR5@.U_S?OE@.0X)R&[
MR0LVN4_8@.IS@.=-,J>>M8:IT7&2M@.+;<-R?![Q2VI;P>#%<*"E5$>,Q5K2X.S
MBI>3:,I:G4N+GY2/<]8V\[9*XBA/=;RN4Y7(!>V3EA02NSPG!J6\IWA$LW@.R
M3UADDRF['!XX1T=PR:*J2,I'$.O&9\D-^/#S+Y#PR8S-0E;TW#B4+G!QEA.R
MVR3#O\[X].P20>%B##W_'V_>OO/ ]STX\HG(03M7108^?F=93,)$$K.41:5.
MPR'(OS=%/J/\GK'BEN&C-(D"2F4.BRG#12CP,DB"^ +7GS^/QCU!S)&H/Y0/
M3DXX*^Y9071]06A()G$XQ(702*^O%4(#E-.$6T"&/\H<0@.818B6+(7R$A_F$
M/;"H8+Q*2\Y*#WANIB^0LF (IQ! R69S$*'OH=P2HGPV$SJ0`S@.Y,8<$I],S
M98IRRF:05\J[AJMB63,DI>HIAG/)'DJ:#OF-G*LGBCD_T'R,`.CQDLU)/DC,
M0W>?7US!^?7'CQX@.@.6#3C \4D:;$"DM%()(U9C<!&@."R*DV-`1&!/\A*0UH0
MG38`Q;G2`\%#FED\DZAFL%G'1 VZ0PB*4GP5E<+&W"&8[U85$?7"A@.!%)B7)
M9S5E(]QX%'):&.-QV=*DS)SA8[.:2_MZQ!9NP0Q%_/!HXAF.]>([V'J$\6
MJ1\-_= 2242EK%,U;0MZ:FS85,LJ`;5:2Y@.N1Y!<9H@.U*F?VX3F*&:^UV $O&
MR!#^O+ZX&IV?AKU1/9ZC1IA#Z,W"ZDEPFB_;_22^FN-I#JU1UI,TBW9*CN[
M2JZ-WI1LEXJAQ#;-!A]7LZQK`<*H=1B+;!<3$+SFK,"<[I%C9<ZX"2_RA9+E
M]H?^ZO)-$=I "RN"7E"+NH8U@.\]*C;Z!Q#^KG( -P4^'[#' 64F /0MBI3Y&
MGUS,8II$4QQXA&EPC^ 4QT#8%D24Y\=:C24=:D?7C_L6;:._&^*Z,RPU9<_N
MS#R+RI[::/DZIQHJ>VJC"^R<JJGZ=B41\^L6`!M\51_J>A>'^;$+KZU^^S6X
MEH,1)](\NQ7%HWYZ>@.E4Y>LV0]6C9@.WQZGZ+IH,K&209IE$IRZ$N43U5A?H@.
M]B(<>K7>_:[%D K8KF@.5A^#7&JHVQ8Y3VBWD6*;#*KW32J *<L<"/R@.NNBZ9
M#8L*5KW$(9R[KMQ!F3FDVDT:D K"E@.V7D3UE+@.F2G]M)7+<IECJ.VGQ#VF#1
MHPKW;7^G1IOF'++%"2L*++?8P T`_QH.XH'NRG9W!";B'Z=P!/^1YL6?K:[!
MS+=Y*S/U!.!2?'N@.<,$31L&.ZBZ92T?TM<7CA)=)AE^$O1JY]]I(UA_<R]9D
M$M?1J,<U^G@.PP/\D2M24$N*)LF6V8+DBR:X-9J)53L1$O>)0>;Y74ZD6!<ED
M@.THC'4+:UH'&#?5/,3\\-E;5X=<`&PH_T7 :"R/90.?B_\%S^W8;@.5.W-[=T
MI6'V; ]_=_?J5!U9,/'"``S6NL193,IHQU#-Q19.'< XCM.*H;&D%J[5UI2V
M;*S%%\O3)I%;3\?I*9;Z>0L7!<@.#L1]UNJ5INE4YMLLV%4@.XVW=%:7(VQ7!'
MEK&-H+LV.*/0>I9#ZXA YWU)TI1VLZ)?0C[R' 27BQOB:5#24(!=%$G(\E(N
M_-^F6J+^[ '3GAM#O7J1_0(TBASF04_NV!I[NS[\`@.-K32)0K<,<TQBP%/-R
MK:K/W1,V=19D\L!Q<L<>R9O^-KJBL5]&W\:NNF6WJ#^K:T.5E_O+=M4'3S>?
M5NS2XE::M2ZDT-V6B;N7:;A@.;TFZ>UINW&&YZ]K9VEB4H\B&%F K5!-T5O...
M>S'"Y V*^9&_8P=&_#?KO.IE9=MT7[6 CK*<->MRMJ8P=Y;,K=RV/Y_MQV%/
M]UX;.K&[Y]K%MR_OV$9C1>PM\-PY\1V,BS&;Y?<M_1/^6PVD]3U5;:U&HW/4
MUE&UMS>M'!#ICGS5XFP.GMM@.I[.+_>2KBY5C33H?HA)*I];UVXM5D'6<MGJU
M=]C<<C/T//Q<M@.WEVMY!U$PSYXTD=NNT$YG<?@.2T-XC<KW,VP,K].FR_WEI"
MR5U2VED#BGM&15CZ[(21NYSI;=EJ[F9<IC<I9@./7VLLOG:.V-#0[]NV#%?M_
M[UWS,W;.QGAZE]9XR^=O9CHZ/P'Q;N,+O6[.(,XAKPJU\UXDY52WB3* /?E#
M6G6#0^H7#GN1Y/;;*T*&&O#J%RD$,TTVVP7"]T@.;9V\1@.>X40;% S,HSMX0P
M+W%]JL%'8+7-8-Z,JY?B'*N1>,E%-YKP7_08(>H9QM;[<R[\)N:J#B=0UYJ
M3AF(\AC@.BNX*5 7'*A*+&PWB=@.,:4,KGAC,)J[(@.BMB<@./T1>)HO/"6#M%GD
M51H#ELLTE;<CN#G+R8OY-,A8+ ^+(D&81RCV6.UGS_,%F4/%$5T46+G#8*Y(
M@.'R/B$QCLD<N#Y]$6M"%C,(3')>O9&"VH%XJ*IK<:;I\Z\7%`"^%,<P;,*&D
M4DU?A9 IHV]/2%5"M$G)YD0MK\#1Y9G1Q]&O5_ */HPO/L'768 4Q;?CKW&8
MX__K%\/?X,OOH_%(WV1Q6V[+N<3R^O/[TZN1\P2CPX/+T14X7WD9E!7_-CSR
M!^]^>O?6_]>;GSQ"XJ^BF> ((;-@.<H\\AOX_#P^D=&>=>/Z,FX.#36\._@.]0
M2P$"% L4"P``" #-D/$NU$4\;<@.I```LO0``(@.`````````!`" `````````
M1FEX960@.+2!S<%]A9&1M97)G96%R=&EC;&4@.4U S+G-Q;%!+`0(4"Q0+```(
M`*ECI#!<5R3*=@.D``*PE```A``````````$`( ````@.J``!&:7AE9" M('-P
M7V%D9&UE<F=E9FEL=&5R(%-0,RYS<6Q02P$"% L4"P``" !CD@.4O6?!2!(,(
M``!H'@.``(P`````````!`" ```"],P``1FEX960@.+2!S<%]-4V%R=&EC;&5C
M;&5A;G5P(%-0,RYS<6Q02P$"% L4"P``" "W8Z0P:&ZW3^$#``#E"0``'0``
M```````!`" ```"!/ ``1FEX960@.+2!S<%]-4V5X8VQA=7-E(%-0,RYS<6Q0
M2P$"% L4"P``" !UD?$N8C9)<K$#``"="0``)P`````````!`" ```"=0 ``
M1FEX960@.+2!S<%]-4V9E=&-H:61E;G1I='ER86YG92!34#,N<W%L4$L!`A0+
M% L```@.`MG$!+T.6BAYC! ``1PT``"4``````````0`@.````DT0``$9I>&5D
M("T@.<W!?35-G971T86)L96-O;G1E;G1S(%-0,RYS<6Q02P$"% L4"P``" !2
M5Z8P< 3.)?8(``"?* ``(P`````````!`" ````Y20``1FEX960@.+2!S<%]-
M4VUA:V5E>'!A;F1P<F]C(%-0,RYS<6Q02P4&``````<`!P`T`@.``<%(`````
`
end
|||Thanks Kestutis,
to clarify though, the issue stems from the fact the tables I'm replicating
are not owned by dbo, right? I am not at an advanced (or even intermediate)
level of sql server administration so executing scripts that I don't
understand make me a little nervous. What I mean is, would dropping
replication, then changing ownership of all the tables to dbo, and then
recreating the merge replication be an alternative fix? If so, I may prefer
that, if not, I will try to get famaliar with the scripts you supplied on a
test server and try to use them.
thanks again.
"Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
news:O2YNs$PZEHA.1152@.TK2MSFTNGP09.phx.gbl...
> I attached fixes to stored procedures which are designed for SQL Server
2000
> SP3a
> They should be executed on master database. Be careful with them, execute
> parts of every script step by step.
> At the end of every script there is update to sysobjects table, which
> restores initial state of stored procedure (which is changed after "alter
> procedure" statement is executed). So before altering procedure, check if
> this update will restore correctly stored procedure status (status in
update
> statement should match status which you will see in resultset, received
from[vbcol=seagreen]
> select statement which is commented near to update).
> Those are procedures which i met on my way of deploying merge replication.
> First of all I fixed four procedures, but when I added publication
> filtering, I had to fix some more Now I am applying those fixes to all
> new servers I am installing (where merge replication is used) and every
> manipulations to merge replication are working smoothly.
> --
> Regards,
> Kestas
>
> "djc" <noone@.nowhere.com> wrote in message
> news:%23d2H5xOZEHA.3368@.TK2MSFTNGP12.phx.gbl...
think[vbcol=seagreen]
issue[vbcol=seagreen]
to[vbcol=seagreen]
> not
MS[vbcol=seagreen]
does[vbcol=seagreen]
> leaves
> table
I[vbcol=seagreen]
are
> (and
>
>
|||Yes of course it is a much more appropriate option to change the owner of
the tables, because this way you don't have to modify system stuff which is
not so nice
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"djc" <noone@.nowhere.com> wrote in message
news:ernO0wQZEHA.2500@.TK2MSFTNGP09.phx.gbl...
> Thanks Kestutis,
> to clarify though, the issue stems from the fact the tables I'm
replicating
> are not owned by dbo, right? I am not at an advanced (or even
intermediate)
> level of sql server administration so executing scripts that I don't
> understand make me a little nervous. What I mean is, would dropping
> replication, then changing ownership of all the tables to dbo, and then
> recreating the merge replication be an alternative fix? If so, I may
prefer
> that, if not, I will try to get famaliar with the scripts you supplied on
a[vbcol=seagreen]
> test server and try to use them.
> thanks again.
>
> "Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
> news:O2YNs$PZEHA.1152@.TK2MSFTNGP09.phx.gbl...
> 2000
execute[vbcol=seagreen]
"alter[vbcol=seagreen]
if[vbcol=seagreen]
> update
> from
replication.[vbcol=seagreen]
all[vbcol=seagreen]
> think
> issue
> to
are[vbcol=seagreen]
> MS
> does
Various[vbcol=seagreen]
just[vbcol=seagreen]
your[vbcol=seagreen]
replication.[vbcol=seagreen]
> I
> are
this:[vbcol=seagreen]
not
>
|||thanks again. Do I also have to enable 'cross database ownership' ? I saw a
similar issue that mentioned this but I don't know if it applies to me?
"Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
news:%23CZMK0QZEHA.996@.TK2MSFTNGP12.phx.gbl...
> Yes of course it is a much more appropriate option to change the owner of
> the tables, because this way you don't have to modify system stuff which
is[vbcol=seagreen]
> not so nice
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
>
> "djc" <noone@.nowhere.com> wrote in message
> news:ernO0wQZEHA.2500@.TK2MSFTNGP09.phx.gbl...
> replicating
> intermediate)
> prefer
on[vbcol=seagreen]
> a
Server[vbcol=seagreen]
> execute
> "alter
> if
received[vbcol=seagreen]
> replication.
> all
every[vbcol=seagreen]
how[vbcol=seagreen]
> are
from[vbcol=seagreen]
SP3a)[vbcol=seagreen]
> Various
> just
it[vbcol=seagreen]
drop[vbcol=seagreen]
> your
are[vbcol=seagreen]
> replication.
elements
> this:
> not
>
|||As far as I understood from your situation description, this should not have
anything to do with 'cross database ownership'
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"djc" <noone@.nowhere.com> wrote in message
news:OMyx$qSZEHA.3716@.TK2MSFTNGP11.phx.gbl...
> thanks again. Do I also have to enable 'cross database ownership' ? I saw
a[vbcol=seagreen]
> similar issue that mentioned this but I don't know if it applies to me?
> "Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
> news:%23CZMK0QZEHA.996@.TK2MSFTNGP12.phx.gbl...
of[vbcol=seagreen]
> is
then[vbcol=seagreen]
> on
> Server
which[vbcol=seagreen]
check[vbcol=seagreen]
in[vbcol=seagreen]
> received
to[vbcol=seagreen]
> every
I[vbcol=seagreen]
the[vbcol=seagreen]
> how
they[vbcol=seagreen]
> from
> SP3a)
> it
> drop
this[vbcol=seagreen]
> are
> elements
should[vbcol=seagreen]
a
>
|||thanks again.
"Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
news:O9kaUAYZEHA.1248@.TK2MSFTNGP11.phx.gbl...
> As far as I understood from your situation description, this should not
have[vbcol=seagreen]
> anything to do with 'cross database ownership'
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
>
> "djc" <noone@.nowhere.com> wrote in message
> news:OMyx$qSZEHA.3716@.TK2MSFTNGP11.phx.gbl...
saw[vbcol=seagreen]
> a
> of
which[vbcol=seagreen]
> then
supplied[vbcol=seagreen]
> which
> check
> in
> to
that[vbcol=seagreen]
> I
> the
out[vbcol=seagreen]
> they
server[vbcol=seagreen]
you[vbcol=seagreen]
because[vbcol=seagreen]
on[vbcol=seagreen]
> this
Fixes[vbcol=seagreen]
get[vbcol=seagreen]
> should
in
> a
>
removed replication via the EM GUI but it failed. All GUI elements are gone
but when I run sp_removedbreplication in query analyzer I get this:
Server: Msg 3701, Level 11, State 5, Line 1
Cannot drop the table 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
because it does not exist in the system catalog.
the weird thing is that the table mentioned in the error should not (and
does not to my knowledge) exist in this database? it exists in a different
database on the same system?
any help is greatly appreciated.
As far as I experienced it, SQL Server 2000 (at least SP3 and SP3a) does not
handle correctly merge replication of tables owned not by dbo. Various merge
replication related actions are failing because of that. One you just
mentioned - you can not properly drop merge replication, because it leaves
conflict tables. As you noticed from error message it tries to drop table
'HesstechUser.conflict_MergeReplLIVE_VendorCustome r'. I guess on your
published database you should find table
'dbo.conflict_MergeReplLIVE_VendorCustomer'.
If you can find it then I can provide you with a solution to this problem -
but it means fixing of couple of system stored procedures. Fixes are
straight forward - correct handling of object owners.
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"djc" <noone@.nowhere.com> wrote in message
news:OdhjTNDZEHA.2944@.TK2MSFTNGP11.phx.gbl...
> I cannot delete a database becuase it ways its part of replication. I
> removed replication via the EM GUI but it failed. All GUI elements are
gone
> but when I run sp_removedbreplication in query analyzer I get this:
> Server: Msg 3701, Level 11, State 5, Line 1
> Cannot drop the table
'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
> because it does not exist in the system catalog.
> the weird thing is that the table mentioned in the error should not (and
> does not to my knowledge) exist in this database? it exists in a different
> database on the same system?
> any help is greatly appreciated.
>
|||thanks for the info...
1) I ran a script posted by Hilary Cotter (thank you Hilary!) that I think
cleaned things up for me... BUT it will only happen again due to the issue
you just informed me about. So I am VERY interested in finding out how to
correct this. Please do let me know.
2) Can I change the owner of tables? if so how? The only reason they are not
owned by dbo is due to how our db person moved them to sql server from MS
Access. I would like them to be owned by dbo.
any help is GREATLY appreciated.
thanks!
"Kestutis Adomavicius" <kicker@.nospam-mail.lt> wrote in message
news:%234qLmOLZEHA.3596@.tk2msftngp13.phx.gbl...
> As far as I experienced it, SQL Server 2000 (at least SP3 and SP3a) does
not
> handle correctly merge replication of tables owned not by dbo. Various
merge
> replication related actions are failing because of that. One you just
> mentioned - you can not properly drop merge replication, because it leaves
> conflict tables. As you noticed from error message it tries to drop table
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r'. I guess on your
> published database you should find table
> 'dbo.conflict_MergeReplLIVE_VendorCustomer'.
> If you can find it then I can provide you with a solution to this
problem -[vbcol=seagreen]
> but it means fixing of couple of system stored procedures. Fixes are
> straight forward - correct handling of object owners.
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
> "djc" <noone@.nowhere.com> wrote in message
> news:OdhjTNDZEHA.2944@.TK2MSFTNGP11.phx.gbl...
> gone
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
different
>
|||oh one more very important question:
what else do I need to worry about due to this 'owner not being dbo'
problem? I currently have the same setup on a production server that is
about to go live. The issue I just cleaned up (I think) was on a test
server. You said 'various merge replication related actions are failing
because of that'. Is the integrity of my data in danger? can things get out
of sync? Do I need to think about stopping this from going live?
please let me know more. Thanks.
"Kestutis Adomavicius" <kicker@.nospam-mail.lt> wrote in message
news:%234qLmOLZEHA.3596@.tk2msftngp13.phx.gbl...
> As far as I experienced it, SQL Server 2000 (at least SP3 and SP3a) does
not
> handle correctly merge replication of tables owned not by dbo. Various
merge
> replication related actions are failing because of that. One you just
> mentioned - you can not properly drop merge replication, because it leaves
> conflict tables. As you noticed from error message it tries to drop table
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r'. I guess on your
> published database you should find table
> 'dbo.conflict_MergeReplLIVE_VendorCustomer'.
> If you can find it then I can provide you with a solution to this
problem -[vbcol=seagreen]
> but it means fixing of couple of system stored procedures. Fixes are
> straight forward - correct handling of object owners.
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
> "djc" <noone@.nowhere.com> wrote in message
> news:OdhjTNDZEHA.2944@.TK2MSFTNGP11.phx.gbl...
> gone
> 'HesstechUser.conflict_MergeReplLIVE_VendorCustome r',
different
>
|||I attached fixes to stored procedures which are designed for SQL Server 2000
SP3a
They should be executed on master database. Be careful with them, execute
parts of every script step by step.
At the end of every script there is update to sysobjects table, which
restores initial state of stored procedure (which is changed after "alter
procedure" statement is executed). So before altering procedure, check if
this update will restore correctly stored procedure status (status in update
statement should match status which you will see in resultset, received from
select statement which is commented near to update).
Those are procedures which i met on my way of deploying merge replication.
First of all I fixed four procedures, but when I added publication
filtering, I had to fix some more
Now I am applying those fixes to allnew servers I am installing (where merge replication is used) and every
manipulations to merge replication are working smoothly.
Regards,
Kestas
"djc" <noone@.nowhere.com> wrote in message
news:%23d2H5xOZEHA.3368@.TK2MSFTNGP12.phx.gbl...
> thanks for the info...
> 1) I ran a script posted by Hilary Cotter (thank you Hilary!) that I think
> cleaned things up for me... BUT it will only happen again due to the issue
> you just informed me about. So I am VERY interested in finding out how to
> correct this. Please do let me know.
> 2) Can I change the owner of tables? if so how? The only reason they are
not[vbcol=seagreen]
> owned by dbo is due to how our db person moved them to sql server from MS
> Access. I would like them to be owned by dbo.
> any help is GREATLY appreciated.
> thanks!
> "Kestutis Adomavicius" <kicker@.nospam-mail.lt> wrote in message
> news:%234qLmOLZEHA.3596@.tk2msftngp13.phx.gbl...
> not
> merge
leaves[vbcol=seagreen]
table[vbcol=seagreen]
> problem -
(and
> different
>
begin 666 Merge replication fixes.zip
M4$L#!!0````(`,V0\2[413QMR"D``"R]```B````1FEX960@.+2!S<%]A9&1M
M97)G96%R=&EC;&4@.4U S+G-Q;-U];7/;1I+P9Z8J_V&JGJHEZ4 R2<FVDC5=
M4F0ZT466?)*\R=5FBP61H(0S"7 !T+*V[L<_W3WO+P`A6;G<'2NQ2&"F9Z:G
MNZ>GNZ>G7$]G>;9(;S9%P@.[YURQ>)6S,NO%RF=^QS7H>5TG9C>3KS_%R0^^'
MW6^_^>G\VV\N)L?G9^].?OIX,6&_GES]S,[_-KFX.'D[X:^__29>5DG!UD4^
M2^;83KF>QO/Y*BENDKBHTMDR^?8;!I_#]>9ZF<[B*LTS9GS*^Q+[%+&&S_-G
MS*Q-8WCV7, 5K;AU6L*5M6V89;XI9LDTO_[/9%8]&":OS41M&W)UOTX"M01D
MQ'P57R^3;A2$+'M+4!3,>5+.BG3M8C;['!>SV[CHC5Z\Z(_9V <?3TZ@.!I@.E%
M@.9[ER\TJFU9%//N49C<>Z.&@.CWU>Q,O2[3. YK79,OF<+)F"H;%<Q=6F],;I
M`M]DY7T&U&7"!^#R<<3B695^-O"Q+I+IK$B(6*:SU;P&[KS(URZ>`6XWRS,<
MBWS?G2?+I*(G5;')@. :3KH$@.V0Y'WB-Q7\YNDU7,! R-('H\S9VI!=C7:187
M][V#/OP,@.O>!RYXR#JXTFME<ETDU7:3(RK-EO"D3!U\#CK%N: R\&A/U7+:<
M%DF9+S]#@.?
(=+9E%6^8JKV(B_4@.%0;\NTTS19Y#>&S>NR[;1 43P;<9:KSM-J<26,V"%4P)40+5Z'3"!:$=&$2\G*YQ-%B^TU']I=YVWQV=7DZZ40<^T$E9
M@.:D*R$. C2PW*"7>5/DTG2<9%+F?%G%VDYA@..QY8F'"65JS*&?$NX3>#%6&'
M016HS=*2K?.R3*]-A(,4=EOI7*<W:59U[&&ZA40I!QG5+>#^-E_.L5,6D XB
M*EW<*_*9EKAV5;C"4%& -*"QX& &XWE.^."5F"H;L>%8/*MNXTJ_P.$M"IA\
M8.FR2N9"9D=LE<-+6@.5+MHKOV77"8#F#`LL8J=R4N7K"]3)A3KN]BM"@.:-4%
M:@.507&BI\7E4($0JC>_N-JEN$\T`!*9D!AQ.Q!O.WYHV.H>+N*RFJ\T2*N;+
M*5_O<;'VV@.-$N,WQTK2V,YBFS7(N'Q' -?2$2WCL"@..I*5^C8$]60 &B+[LL
M7<!TP1PD&5 >4#*6$H73LMP`?I$`DWAV*Q<-3H;S73$.D&&S3]-U4JR@./(HO
M307(RM=IM8K7V'.8OL&7P4 0-%4K(WPTI$=I5@.)#,7J.CT?T5'1%/=VGIUSP
M\Z<2G3G.: JX6Z9890J3O0;<5-@.#U9MW6(KI4BSYDB*YW#!5G(,CK::\3>8`
M$A?9; I/6) 2$.Y)-D<="$B3J+FZ!2H6-%$"WG""@.%X54)R5&-?=K$0JR3.4
M(H8>%9?L+EDN%5$?7
"1T(.I ,@.+]_@.%&;RZ...G_.^S9^QM`O*^(##EKGB*M(YK3<] V5_$7Q?N"^7DQ54)VL\ 2@.FOJBDSGUV8AW4R\A%5M?C]58\;&W):4
M,"KSZ2(N:OJ#0L80RAV_!*BVFEUKNIQM5E/)%.:JL0*>#>(@.G3/OL\G2?VX2
MWNU%:BT_<NWZ8,PC@.)!3J"#/KUGH$T"AQLYFO<Z+*C1R5Q%VH=F%G16SL7"1
M5+-\[JG$P2Z$4!68)= *IWYIOR JT0&0-5.5I;-/)-BWM4];'R1((?BG*!G\
M8HYF/14]"11<!8;M*#DN"DBQ]L8&$N@.>A>;.SO '
BO'']EHQ^8_/KBARS!M]4DL*B_I)__AHB/Y4DW+))G7\W>10->]3O@.%U1(_6YI]UE)PT&^L,04%8EL-
MVE3A%&[K# J %AQI,1"I(9QK; $H6<M 4<<D`*2G3EBPI2#JYR&XZT^?DOM.
MO<R<PTI3I->@.#UH\V%C8%1;UA4D7J"'$O8&']OEU@.&7J1<%Z:2OR-7,TOYZ&
MP(:A\LU-"[F1EE-S20K0*:AN9?JO[1(`U@.EO9MT"8I-05^*?&U =@.-#F]D@.U
MT[_R<"U5BRFMB"[3FR1$$G(%4A?;#[SWM50087Q=U87J%$L2= T[9H)JC"]H,
M.)^GCF8<1E$,[^*;[>56P$JHJ6TKEX$P`Q(`&;%9=T)J!'!T* T#08+H"-6!K
MN?A+NW*XH%1?JJT%UT4J5I5 23T;7W#A"XF6+RBR0R]@.0%4*>U9@.)-1B.RXM
M7&]6ZREL0 \&G8[W\@.9T_A!09'>2R(%W4.=F`W(87S6)7BR4;4"%W59P7O$^
MX 16*>$#_@.,]:A5_@.OT*[@.AGFZ+ +0L4B:_CDK
28;K!M^<T#0P$E)"[Y)*M5_(EF2E-9CR_SG>!P=]?'N.^@.6H9E7@.-V X='DXN+LXO7K\9X"9)UH:?O$0'
M'FR*C/6&_8#Z?<(G)/T7U\"9H8&CL--X@.>W#0'QV`O_(3U>J_4M4\RQ1B)L:
MYZU-#7X!DY/\MYI8_'>>.N\7,3MV>'@.YN?C;Y.+LZ/VDIA3L'*"@.6#%Z?;N4
MM49SVX,[$J7EA%Z[>I;765>U"0)Q%J@.Q&S(^W>P8YK;ZP=JSD >6WR^MH,Z0:
M4$CWY#!'!T0<O)S 1Z<6,\96A^'8N^_369&7^
BE_]^>ID4^.(2= R8H@._*M]G\AJCCDY(ETYD%D`N21*(I#7\"@.JUJ8CO1O`$DED5"WP70%=SW ,][SD=HB.
MB&^ R$NVZ:.U"-5#?'MT-;DZ>3]AO4E<+'$7^6N:E?TV?7YP"Z=D'&L)WUW.
M&I!"(O<*F!"@.\CWU-NC^&E@./_D.1Y@.6PO@.!N@.M1BVC(#PY*@.&1@._UPE0EOYI
ML9!9<<PV)8@.!8C60S7UN?(3%F...I*2Q7*0H\P;KIO&=;$/MV.W6=8\PN5]--
M^2GB%'I6P!K4&^X/1J\B-AQ&; ?^;VQ=53>6*?==DLWU0_5#XL=1<<?LWS^>
M7TU0E/>L<?79=ZR[VX5_`P5DUT"V$3X"GHS7;UBWR^)L'GX-6$-K*9_6CD 4
M:@.;<[%?=DCDXG2.=Y L6`D'K+BD!O:[><28E;?O5>/'!>,@.G'D?C(@.!&*:B@.
M-QR/^M1C*A=HLB_&JW0(^*WZWNFH.>V-AJ,7+V%*7\HI]6%%RE?3YY6-&>UT
M:-HZ:O*P4<_78;.%7F2\<NATN\X%QWI*S64"*ABQ(V)>JS3X=_+; Y%@.;BW#9
M$DH6JE;"-LR7?%[^Y)U$#LZ_I6+1`TV7C7K6AWC.\DU%5%"NDQE-EW2H";=<
ME=/K9;*H[#XK06!Y\<9L@.;)IO01E>QW/N2/OH&>7"O>E`#)!.4OX^<'RJ.^J
M8E>WB>UK!YDRBS.D\>N$"PBDK-4&R!-]_GFQDD,H-LND5(#(6JZ4:6WE9::
MT51A-=E"3-IR9W]/$VG7A-5UY$I(WA!U>OH?R5+Z&WF;XS&S'T3&IGBLOBDA
M34N6T:G2P !G6>GRL<SK@..:/'SY,+GI*&^V/^0.MGW(^-]75L:6\6@.B&(3T0
MM:/!8&3RO]&_]HA%4;/,[Y*BIR3%& -(NO529W\PE*W62I46%([:KM[T+(A*
MI1,,?1_DF8OA"^N"7@.0B>,X^I\F=XM!L>=^5%2(%2._YA!LE< 4(V$+2 L7.=
M;S(.5?,8*"&@.)@."M`>$$"AK\IC<RU$L%H5O;S=VP$"&]?RRG@.7Z!GH-.2=1H
MIJ" I=EP^E,"8A:V9L<?AM/CR^G19=]4902,LR9<P1 X$M9%ODZ*ZKYGJ"/V
MBM4'5CTI+ZGZCSCX;A]EZY WZ-"E29/#T2M3S7"@.VJ+%)DW]7*U("7JOK=$]
M_:C&[0;UHGY0X?7&$5X&*YQ#O[540(*"_V$_7Q==M76=I#4RK C1(+D]:K9;F
M<OGCY*>3,UMR7!R=7/+**&Y>[1F,;Q6;7'V\.+,%S.3LK;N6-,H#AT>>\1>X
M?L$F77/SH2$CECD@.+N+O4K7DZ67.7/O<-2\BRI%522J0(X$_!Q974&+.2QBD
M`H\1O\J,Q"G-8&O-D$8W'RC4]U_48+E)C%MVJK 21>O8H45:6L]LITI930=(
M^S+ADR3]0[N,=)9YLH@.WRXH;. `A//Q*S;2J3A_3N>1&>]DEQ_)C?A<?NR3_
M#.A?# $+O>66&>Q9Z.V(OZ6H@.=#[/?I7!I'9C LL>'K^*ZD&;O1:*SG/SLZO
MV FP5YOP-3U!'CL;S R+^,MAD,P"K$R<' @.3J#!B(TMHQM&C< .LP8-,D=<$
M'5CCW7UBQ(Q%1)_JJC85"!I29KO)Z>7D21HDW#<U.'SJ!ODD-S4Y>N(F%34U
M-;J'1%$K`K@.'OD8`D*2%=R<5+7^J,FA5&&H$>_%%CHZJ-+NIDQ*&A]_2)$W)
M8$D)CVL'7V+^A7KCOAY\&7%Y(6*DM,[AE]P7)5WMQ"]Y($HN`+_M8-;I<ZR7
M@.YZZS&-0D_O&_LT2S9H6VFN56MK(:.6NBP%\YFEB\,P=%3ZKU4<;!)6G= ^RW
MUSL,8?6HT:.6R0?.@.=B=NYQ<*=(;8^19+#A/*CL."SZP80_1;?H`=/JDG?!F
MJDTG]@.=/VH=:JOD3^N)1=9L^')A]<&Q&.HAIS,Y__+?)\=7TY&TOO*T@.RZ>N
M\'#KR^A5FYT+U:M7+^U]9DK1ASVDO BQ'>%P^\%=%%2A^,B2]<3PGRG+RRQ?
M81QI&38^&T9S`P'ALHQT]B2;%?KBAR+YAB:4 1[.U"X32-J@.UU<(&@.8,'RW
M-'HH]3NJL?#Q/4]J6T.$YU1B$G!/T:$!`,\-T3?Y[>3RZI+U+B>G0&'L60!U
M[R[.WRL;6/*E@.E$D<QETBJSGU_GUY\G%A$D3G+G1M#]'9V^5X4R;H.5;P3NF
M88FVV=^/6D[%PS><1R*F=IV#JAIAF#5#`LPS#+X7LR1B>DVW.[>5TH) 1&:N
MP"H\]S;^G "9)88FLTX*W(OB$98R9]=%G,UNR=Q,9 T;TUN I@.YPJ&HV7+(K
MD6TZAM["AM/1G_4.WV5+DH(1,QC3$%<:2U@.U$.U^<LF-R;#\AEZC4.QZDVE.
MCZ"Y<&5[8@./S9_?/-K&+KK5JW37.8^RX]1G6$$^MI47:9SADR9]VZX<V<T3.
M6UE)\X5;PCZ@.%CAK8)46IC%!`>Y;\^#7V/KIM<H/;(WE-_>]O9D`SD%N&.L-
M@.5O>/3PU]A[5C5NXDZS?@.7%Y_B?_H=>"0Q#V@.\8VU&3X3]UZGO/3>1(Q%B 9
MY5JP/0W>$%QGA_/$+5]_J&'<\-*5HTQ+7,D6?4^_V<*L#J.V8]+C=^^&7D-F
ML-2"2]!$>NQF>5;%:58*_4Z<F9%K&Q,VXC0I(V/7N5FMV69-:RY0]AJJ7:?+
MM+K?H=.-YN:*?]_989=IACX%%-?D(43;/=L;8=!CB?M79USH-E9U-R4N"UA-
M[7*%1QK6IW*S6*2S%!2C77:65\+RZ8!+2P5,*@.=K[C ACZ;V6C)A-24=B)\N
M6XAU4$;V[#J1AE9+TV4^O\N+>2 2]@.OB<NKT*Q0*OY1,'RPIM>(0.$D-L 5T
M@.J_JP,H:0Z]&>%C*8WN35,)=*U[Y7EN$!II9KP;47VI[U3=LJ301]B)G*J-[
M!]^#!C1H].@.%@.^V&CNNDN:,!9(<Z6=/'[P=?WT>/DWD\D%"TI (TSQ,>P@.$T
MO@.16$\=8F"&$I0T>;4FW<<D]?BAWN242GO!U).QZ:Z6@.?/N-[*>*_1/AXN-R
ML^HMD^RFNNT;^QH>SB1W,.,V>SP)\<U+H%P#\=H%:YI$AH.7I J;L>=GL10"D
M1$A?IGF@.^!:]-?:/L+8W&O*S;+;?6"+,.H#%C;(J_@.1JJ4I0I;'>4-4SI\,X
MF#6F@.VV]9_7384=A>1.BI\0\[O6&C?9?T@.;@."1'ES+$Y9;;]Z^5![61'V+$6
MFZ,PT[&?A+46T)+S3:<#/\PVTGI!\1?J;,>8J:\-(7!MN.%/-7;X*H8,'S?5
M-*5HQ.A1VD$3!060*?V:MIA*DL&:K(X;@.VQ-M7N1A%8NX0$X$ 48XPWDY&SW
MFHPI?%MBM"]Q;N]&^!X6S2EBWS!J-I1 DRA^&VPXG#]F@.<!$WOYL%R2@.F%!L
MG,=C?I"^>GP=02%.R]VTU*/GSOE [&&;B$=DFX.7K%5X3!--6+3A$$H'J:3#
M2>0^W["[.*OXUOYSPF3LN5RSD%'H\#UW.XO#\>3^,.*W$-YS'I4C!$W@.]/^#
M_#@.)#Y'H.<?V540INGQU=\RG?D(`^;I?'QPT_'ZO17#04XU/')^N&Z ,_O0'
M:;T)#U06:1CLZ<K"Z]=<#,JNHWV^&@.Z8(S_TVL59/2B[A!=P]22S78FR:
M2_0/%^<?)A=7_]'CS!Z);#<@.WF1=%4/4,5MPR&?'J\S8*$SD)(@.%XO ]+W&
M@.Q8XM8'G3<V/]FA"6>0V/]2-6VBA\U9C^C<2AZS&]&^]-FC(0OY.Q2TATH0<
M/"E/%-+&0ZM)=?J>C7D7.V@.9%%W!9C+V8L33,:PIHJPWHY"VJL?/J4:C?C]B
M!\]&,$:V`WC:V9''HID`V"$H^P?;H4@.8,!L[._JXH0;RXF6+KNQ;8 %P0P]&K
MK3!>CCB [[858IV='76DF3<B%5#Z;&NC31.@.;PN'-RSVN/#+\\$=BX9HB\8)
M:#@.X('*5OU[RT%%.4*^'![QN@. )J^C(<8&=ZO/YWPSXA1_)-IX9IGK$1AJ0[
M3]\`&-W@.#CMY.SF[FAY_O+B OVZPOF :@.[ML]J*=H\G=+GM+_K:W!@.U":$ [
MAM!^T@.\$Y9M+,LKI@.&\=^24#OT3 5RBJ"UWCM;J0T'7=\&'2OF3I>N6W3RX3
MH95U/W9;.K":_>,/TG(UBI1NB\$8E#5'2C'<)& 71<H?:+_\YW+Z.2[2&+TJ
M.F:.E)R$.9'CB%T)`G?=GQ'\' 3>76)9X:[CV:>[N)AK@.)9=CF<=\[5C(]![
M0%UP?6#*XZ7U5N[00C5TFZ<1YZ>'7>='?6:[Q*VT<')T=!$?X 0(&EKK$)8I%
M+,O*BU>UEA7)!1W/IM)QU=%7NP.Y%;E."K2B$.*7*7 $ABZ*@.X9X5K:LXA5&
M,RFM4V*L5M/7ZYCAEJ;I5@..7PS9::!CRP=8ALYHARXGQB/EO,C</M^C2`3"9
MC,,G&C</GN']$DJ56^*A<324?DEJJ[X;U"0R*T9ON']@.'IUPNM%]B$]4:XB/
M&XS:3)@.6_*M@.JA-MZ,/P[3;E!TI-]E\+3M:L38=HZ5'0.%1C,!OMMXDA,D\O
M=)JCE6NS?3'FD9C4S>OK_$D45=^C1Q+75P]1[T)D*W3H/9BVHI;2&JL,E*RL
MG=QPZJ[:>0T7_Y.F--B91\[FUPRL9B+KTX4T3F93M1836I?0Q)Q38Q-=6_Q/
MFM.Z_CQR6K]R>#4SVY@.TIG%RM]0<!-15:;<FHZ:C"$K/LG5.T(YUJCGOQW7!
M_^GG_89?<]Z/OGY)9ILJ"4:XW"252M[B1K(8B=+&QO=\4ZTWE>%V/.0=1G]B
MWSM20@.]47:EKU>+ /K/P0AW#,D;&J=X=+',_EHJ,]*.R:>$$ESQM0$HGB/B<
M8^!7D:S0!W_QX9C.:.U*31DCA#Y>30(HO$V6:S-/UV&QGI7%9XDU\]7YQZL/
M'Z_LB W06ZS,76,SD1>OP!UVC>=VZ('9E"*UC@.J]L]2CO;U7UL[<4HK"H1>6
MDBVCFN1J[VO97LY@.G'H0E%LY(%B9CD60B:5+YM10@.:X-IP:\ED0B^8@./R>YB
MJ)*3"Z:N2I@.LK1)D\7A MY\_"S\W9*1%!T#...16>-P]198@.;LXNKBY/W/9.^
M>!Z'%<CQI-A%1OB".69N,#*E&P8;8"#=1/?G7R;_,3T]/SXZG;X_.O[YY&S2
MC<)P[$_W\OS=U:]'%Y/?55*0WT/I07X_&/Q^H1,W_7[$)UTE"6G5F$<J[6I1
MN"D.UTT@.)+D[# 59WF-Q!X07'.E^`GJ'_;']SJ-!S9[)J110.[SY-N,KY6>;
M4\V5*G1V\/*#^@.VZE7/>V\X:7B0+M']4.2S,#.H!RG[[\%<._FA9YD9M?@.:T
MY%F/[M+JEO&P0F&EDPF^E)TD*"C,U$KV7G2;'[4Y58PU*JYE])2I\(,R.^&O
MW[K;C+![9CX&!W2S4=
S1"I$*%5[K10J0_'C\J'$^B))UY%F (&9+&;=E$EFM+0)B3%_9<YY'0X?>2>@.E3,\:VZ,P"+M-[KX_.S_CZDIK*L"IP<:#Y?S<67E1
M7]A-BM50UDMVU53636/5#-=.']4,MWU9+VU40V$_"Y3%:BA***#*FC^M9_(2
M^'%65==BM*?37$3^/(=9Q9)EDF^:!!IP2BDME$BJ97N)QD\KB,J[6T53('E6
M$[7]3R3-AXG40-R7X7I%9(^#TL^BI-"Z.'SQ",IP/%O;%CG!:<\%%SUFQ5.&
M;TIQ0*X;-/YSV[_,E4EK![E_C>R9S83T-4+@.#Y[!H!]B; _6=U.PKH6 +FM-
M"'N#T5<20NOU2-T.1 N1Z=,`?66'W<5%IAV=\KBUFHJ[=+G$>AAYOF7Q^N,X
MWQ7R'C'4.@.?:SL:>X4K2!^UJYL52:@.SK2'CQ$#M5[G@.([F7Y]MI96#J!7@.[\
M7AJ*,T_RZFH\MEIOD([CY@.8,*L>."(E?Q=7L-BG5M#>'$*J 1<YT,M!3\QV?
M+-<1#SL2SSM?%SC%W3&#AI-^M7%..SOL+7=F\CO.M,N:\X5.R71]SZYST.)Y
M9E^<M7]N$KR+!(W'6Q!AZZGR[BYX89H-;9=F$SC+V+B.\)$^X2<:H3&O=[G/
M@.O>4S-S2V27>2X-<O*NB.>E-O&M/E(-Z\Z(%KK/KU-%:RU8OE5I.8M* : =S
MO#23C\G*6_(,/I8$S:@.I83S-9'7^NSZ?&P?3PGIKZH+-EES:8S4E-AXJCV;P
MK1E)_B01>S6^]>\?XUNOGR&>3<CM;,TT$2'T$..\W.LW@.: CL@._W1'#>&S?X
MB+_5@.9M80OWJBXUN72C?]\,VD83\7S\P_F@.^-]=<CS9QA/)&)"TQ,&?*35[<
MXS$PQRO!S]1PZ8._2PP2OKHX.@.OF_3)4Q%_%L@.V]6!?)9XQ#CS/5-YJ7ZP3E
M/0\N)]7/=%W<W>9EPO3)OHZ(.:?SRL4FDR?(\+C9'0;BB$O"Z)18F5LILF :S
M9,WE+<C7><ZU%<P9KO8?/%6K?4@.1K57^8M]T,G'0-+-[+_=]K4O,\4T.XW]W
M='+Z\6)BQHMV]%SY`@.)77+O+XY$9/3^6Q]Q%SZW,K'Z;QNK,L:TNZ^-';%\@.
M5;^$E2G.Z+@.2O[$,D+Q,XK*BF*LLN=.G_Q?HR53(@.:+413&1" 1Y#M$X:B,2)
M5(OFCDZ\*Q70`%W*6Z(B`'D3%W-X1/L$9_[H)%73#/,\]P^2ZB9BN4&+8V=,
MV!'?7_:=A2R4A7X\-)"N1;AI&,=4<!@.)A'&R%%+J2>5B/-1,P8_FTUE*C%V6
M)V.,R[8,T(;9_,F#]NMRYILHP;.HPM#/VP%BS)(;BJV##J79K) #4$<2,!*/
M%Q$:J^@.]C^T\.3N^< ,[V6MY-M#5<-4S(SVK._0QQLT^"[WZJVT4]B,];0!>
M9=?B\H#UKV$!-.A,W!& 1D[Y/;(O%QB;/QZV3M9$V--9DH*TE$TU0_MR+/D
M8_W]#4,Z)#S_3\P)O)!<2H([ORLC?H(9G^<%QC#*6^20)1S(QKT1'& JH!K3U
MRQ'[D7<,?G0:!]@.82^PTOZVR=]J+=V4B=WF(1A>(B4R%SM 0PA3!>W YF;P-
M]WU[K6V=;AJ_!FI&ECL![:$.N+!$.'J'GTQGE.LV+N[E39FPTL\ VG)KRQ8+E
M\WD9=50-%%/Q\BZ^+]D-BAR=A)2+3AE K&03W[AYE+C;$8'<XMK/*RCY.8>U
M89Y^QB[\*RER1HP-1,NWD7C4'695*9@.XG0.^S:T/<E?V!,L_XNL-!CI#..SI
M7\^#:FU0VC$#U73D;[5.8$FI/+2!@.@.?@.BUB@.+<WXV@.5:V#)'BW&9XQYNF5<T
M/07.&")RL]Y5\.]N4\PX@.^Q]&Z^Q';[TV0L!K YTF2=P,07"K_.2W]%!DR^[
MBU$=O5YH0!3BX1R_$A3ZQL"8]$EUSB_$ES"XU_7@.7EO@.^GC<1/CO`"OE_6J5
M5$4ZXYO^>5HDM$Z7HK4F;M _O@.O-F04A=+F,L'/*`Q([\%U,&VR[TSFW1>BP
M:UB+54UN[S)<:QUQA6EP`>F)<U7&0J1H/V+BC]FS2)\SC.09UBD4D),A&%P>
MV-J&B:CFH? [L.AT8EM3:B=&4>'$F2AE<Y<CT:XR!6)LW0)G3^\&J/2;^"D
M!25$ZI 0?0S!,VY37*%A;*+$*:3@.!8FP1H,(;4KJ=T(=0VMZ0' '75>A0Y'P
MD0H:XU2KQD]'"#LJ!]2U,"JQMS].R2\K9MG)6*P[8=\#I7Z8N&+>-5#6;Z>H
M:YD<>T^<"OQ*27(P>!<]VUWPUY<MI,!\Y?:PL;0V?XS#=,/J!)I3R%):K5]*
MS]0WE5%XR9:-KA!:Y," U2/EY]C%%>.VC,,W7;3;\J Z%7G3E2?,;^//N(+1
M_JO,558;L9H;:5]H5I36YKP0L0B>!XGKWKS/+&30[F _<=?)_L(SR QYD VN
M12!:<'0FKKSB!ZA88,DS9YQ=F7)((UGV59R'PKO<3"'GZI]>T(S%-SKP$%OC
M$D_DJ*O+L_9P0&Y*"$=+A9_OX^*3,W!+!AMS08)78&^LOOV7Q *,Q4YV0RX\2
MB7$,JM9!`-UP.UV1+)!#2,L1^5QF,8QB]W\C7MTH3PQTM+.S-TAZQZME2GM^
M#^Z8\;_MW3\^)'5)'EUL]_R9=#P*2Q>RC;QO6)^CE$XVWKP7!!VP+^AFC=YG
MR5TZ[P5"SIRD]N&8-!MIH2FLCY#.U(W#/*6^OH"8AT(;@.=*1A[J:7@.8F]V'=
MMF+I\'[!99[9L;DZ]QDV+I^BU4M*6Y*^VM;4HW0D\W2Q2&3ZD[YE\/*C50,3
MYT:H/CPOJE'3RH\J3NVVS8ZJP#SW`HS;F2[K4IPX*5;PG*@.D4DZMC\Q A\K"4
MJ"TI.W-HT9VL!WJ4'X5(@.3<;27PM9G4?]]@.B^H+\>(''8WHPV!L$W0J/Q+&'
MUXL$K2LF0RH)\GAV=*= 72FD1-)8-]-^+OP(? VP-LBX&2G;Z,R-999$A@.C3
MEB*[3-WH`W?(C]VZ#R!,#QN]7DWD-?%^J'DCA*3/T CBHB<(40:=-$%]>HC;
MRB#GV8_[7\5VK_Y0MCOA%A6T/(I)CD"6K.^1G+@.9K=HL%IP<^.T^*B OO_-%
M'(>69B&?<(^O^#P9C##6Z$/R$2>KB-4GX96?4*[=2-YWIU4+1_Q%+)BY5W[<
M[+O,C6*JJ6=/=<3LG+DL7"F0)9?YZ7E9\,I*3+XQY4BTPJ B!JK7=+8IZAI=
MI66)RP#N*2+SUY22`D8@.1V;+S1S4;5["_"F+! P#H::N$]CG)--TA=%O8GK%
M,^J^> 1=3Q?W"L/3,KT!!(#,BUC]2>FZX=4=DXR8N"03K^.!,>=9&>EEPSPP
M&V K8?2O\C4#_IN3G,5-4[X!3A<1$V3 !R&=<7,^"F9AMD=A*'1]O2[QE.K\
M5'ZBHBC*D#I/XIK:-C1 BW\.308Z%!QDY;&N34$M/X?;&4=M9*)M6:KEQV,>
MCT^<Y-+!S-&AG-4U%[F&NS&HYQ'<3T=L(+X,_H^3=@.W<!V@.\WLKQ;YB0!N0\
MGMI##[IV__M["%J9WIZ?3:88TA/8F3GV!VX(<L=&)B%A#J*]KE^"_%>&G<#:
M\V'0DG&=[8S]]/'D+<.;ZN:FT4UE\PDM8E9 `U_MZA:Z^B6.L[#%I1X3^C-6
MMYZY2TYX>6RYY/C-;F?E!RY3`KT!_OIO6J&^GH5]9>%!//VD2Y5R4VD;0>/B
M(&Y"\%8)<89=[61"'0]L*>W5P17J:NUI+]\#K?HD>.@.O)R$B'+A'^"+2W4.B
MW5L/?"<(KRO^/6P@.#V^1K$FW$I3WC?D>HH#0BQKR?QATTFCWL[<.A@.DK?&_F
M=EMM3:L-5VCZW9!/_4!2E/Y&7N6>^OY?XB %C5^$:2,:_$,R7XD86$ZP$R(A
MFR#0;HGZQ0[H%\(S0ZL4/,*4O:9-5KR9HXG_)JEP>+V^,$J;&!_[22?,'!/J
M:;ZI9.BAZZ.BG23^(MNW.YP.CZ/MJ!1WM/(G+,MY2,D-A>")R]Y7UV4%.FN)
M@.'EX5(QAP&R^6:WNN;Z;<1B[U!KA`'#5?)+I_26?,6CJ-L43QO=NX+(9&]SA
M`(U]IE^?]1#?90'R%+^(:W#U4&@.=GG(9)]%)VUXZY-07$I6[#WIR^B*FOPVE
M9.'H1SDF@.IJ\!!_>86/?2ZC\^;A6IY4:J'942'-0;,Z'$6+MD>#4)$%N](&G
M0#*K^$M/O._7J'\]``HH^\30D8I?)/.8E*?M7=@.-V:+CLD-RQ&8-M<T*5JWC
MC3!SZ/"//VC:[0`*8]KA#_8_8L?G1Z>3R^-)#].<"E0*X'V@.BKZ]...KT44?L
M"M^-!.11C3VM)EW4M<,G4: (YU",,!3_K8@.!9T+.+J_21 P/&D'BZ>?.+?:
M2R9\9#S++6 U+FQ+,3I5^4DF4XUW8H_U%4Y=#L])O5%CD7O.,X7$BAUP`X^-
M;[)Y4BS)4,8]+:$4(<H!OYK3(2DI^8B$_Q_4&_+YZFZK2G^^\VY/:EFMV[LZ
M^O'T_/@.7]O/YZ5O\(IEZB$GN0\T+'U\/(?1#63>,#16QL(YD(.R42=& ER8/
M(BPJ(L4]PK/ON=KJ70[X#9W$(!2&<'XU^8%B_7D\1AM[:A #QZCH44 B7<DI
M:4-DZ9<X2;,GP@.EOQ+H`ZPD0]&#':A,J<*"<%ZLBO;G!<[H"*70E_*.'S\_'
M2I#>-1]"*?W)W\$!EA;%/ %Z[F4KCQ]BKI:JE07@.7\%:D!"@.QA$F*5+&-9=
M]O\M-""/6C@.B7-SNP:6X/#-U*8_LJ%N,YCGW3<<W>--'DS@.U`BM&)(@.X:-EL
MJ&K3"N=>[@.> M[O]0HC\JJB$;[]1%K(?S.@.Q%2LF#\ID59%30#*JW#S7,[O,
MF0QHP+]TA"7!Z%H*)8]GMP9Y>>'^(NQO6'.J9FR=-Q-*J[,Q)%H$DL8@.NT,S
M!-,*X=3!=^-P'%[GL&W(J!WA:OVRR_'],D5ZCT%SMV%XYT'<1W9Y"OZ?\JNS
M0B<%O&A3<[^K@.T\;E2'GLG@.\O$:WYF&(X+ KUQ*5H5NMNFE&QC!Q=2N]]7*T
MXP?#IKS[IC P.XGY%7BP]Y/7-VE/A2 G(U8DD"S+RUJF!97)=')E-Z35."RZ
MQH912YB6# UO+,Z"&1]"YO; ,+.*OFQ7)[BAJS8.G .R]6QLWXZJTP&:TRFF
M-#BGR*/&M,DY7A?I"D^:?$KN#;R;P@.UO[FZ<$1EE#(H#OY&*_LIDG_P:\ 5(D
M]C3#"2F9NQ"+?V&CP?Y!7VA/).<__"+T'5?2!J*9V+NT*"MVEW1AA(OT!D,:
M\&S*G4S'`<,KT>BP)0Y)#45G2Y6?7W\^.9W@.H0BZP<2][ZLFJYO*@._H).H '
MC\[>3GZ;'I^?.J>5(H$]_%L33L=!!$/UY.<:9.HG_]7C.<;*X4$=B&!C,P\E
M%'P8/S@.\L84I`O:,8"X[=2Z!Y"9L288!%NI(<Q3:HW0BGSB[MTY#B=T !CY_D
MG"+%U"Z>!Y>71BU1)\!D=704JN*'?YXH9-I/NL,''[C#2YKC:^_PJ@.M]5GTR
MIN.)"$:TI$A&+5S*7!A<N+S)%M/FR+R@.<K!(E\O-6CAUT']3MX]Q-B[-@.?>R
M5*?>4&O)WW=YH<]W4R)#[CA@.W'' N.> [9!>*%(H\Y-)Z VDHK6GFY=)U@.OY
M(?K,8[(:8T.CHD^ S=0%)OZVZZ;NA(:D5*.F&JI@.[80:C[3H"E[Q1YRNL3MG
MG+4!<IY*4ZBQ3C:D4[5!V8=K#D'R_6UR@.6.(ZLJ)\S5\T,%2K 6ZNWG[Q^6,O
MW'[(Q>$/NUR]_OITN^#.CO;A!?+_;DO7W&HYWZ*=27NT/LT^]JXZ"XJM'Z'"
M9GV<K]:GN--2CM+]06MUO^ZL&3^Z[J9J,'ND,A/I8F+WH:\C\Y,^\"+C%X#W
M+$&GH]QYDS[G'CRIVPZ/_4;KXI+]/" MSMP%#0C^PV=MS8SH9*(]2@.0*P,;(
MZ:*2<-Q1U%:Z6B_O@.^UPXX,1:7Q#MUW9QCS,`T,-4<SD?,X5X4A9NR*D`6WB
M"3:$MRY+ZP>FF*'D(Q7J.S.<;<I'D9>N0DR5_Z_:4O_W&# ]#)4(.C>/S]^]/
MKG@..HP<Z.C#)(+H5?%.J(/LZ>Z'^*K,YH?M%=/V'X+4!>'G\]WZ(<>T%"H1"
M'-3Q^<>S*UNS"=W4?'YZ^N/1\2^$A\NCXZN3\W!*)[.2@.3I1Q4GNYXYR2!Z*
MG\Y%()E]G]G?>>+U?^S^'2@.*_M5Q!/^PK[3H^OWJ(L2/']X>74TZ#7"^_09O
M;^K\G<_D/\8[P\&KO5?[PX/1'L9X=/Z.$R8OE/\,,,;#E]]^PQOO;&D='L_R
M3&R<#_E7685GBQ"1&-U(OI8&JNZ@.R[%R,3D^/WMW\A/:KG\]N?J9G8-6<W'R
M=H*O_S]02P,$% ````@.`J6.D,%Q7),IV"0``K"4``"$```!&:7AE9" M('-P
M7V%D9&UE<F=E9FEL=&5R(%-0,RYS<6S-&FM3XLCV<ZSR/_0WP(L*ZNC4UF9+
M1N,L>QUP`7>V:FHJ%9)6LT+"IH,N_W[/Z4?2W0D(SOUPF1J$[M/G_>S %GZ8
M)@._QXS*CY%)\3((Y)2YI!+-9^DJ6BRC(*6NTU?9+,%OR_6YC?^_S<']OY%T-
M!S?]S_<CCWSM3WXEPS^\T:A_[8GM_;U@.EM.,++(TI!'280L_B*(YS1 [I0XQ[
MS?T]`J_+Q7(ZB\,@.C].$:"^V8LA36U\[/B Z-.?YX%CB";(\#F>46*\U>!2T
MB4-PQM>VP/%7&B=$'+'PX(XO26C8UN 9($3Z0/(G2O)@."EQ-:9P\<OPT(GG*
M=Z8!4]LF'<%!. N63!)*7H(L? JRYDFGTVFU%1W)JH3\>QG,XH<5$D+T7)B#
M8T-NG<HRB?]>4O^9KM1NG.3@.$9VVTEV:A=2/@.?8L1N_Q0=8%>TIS,HT%H.,X
MP,4-PI$2CM!_8I8C&\4!E,^1"#-019S[;#EE818ON.$E0AV?`",&F%)3JS=&
MC^06H#E)TC!=`N]IHE:/#\3?@.P-R34$]&?<O=B17)9J(;T'$*#Z!MR!:.0XH
MPH*(IK[M1-+V%B"X<QR9#BL4'4<TR>.'&.QEO2P,Z&5O8*B>\),X...8XK$K
M;6Y"U8EI,U>*Z110Z&A^.OV+AKGC%*[9_=!I5: X50FZ&5(`^2\Q?=T>)P<G
M-K@.EE "M%\H`?*$8X,',J?,`3K6$6 -0U<J9*8$NYGHH6T0;TI3O-;&=JEZ^
MC.9A&AE.O%X,S0>K0'S?J=43RX-\R<AF(F$Z6\X3?P9Y0M/"&28W`0G*@.$PP
M#YZASF"Q"9=9!MY/(+\$/&_&C$ BAMP9$4@.KA)<AR!F+HI:H(*?_T+ 0W8VF
MZ1$4KB_CJR<:/O-3VB%Q(GX@.EY=0^X:CGW_I$$"N3L-7`>' PC)+2+/;JLDX
M8PK<QOF*<!I'Q?HPF:UX9AZO6$[GI!...(<6Q')(3$&F.>RTDA@.#72LHA-VT3
MN&Z1,$@.*5%!X29 4-0\*2J 74BO/&2J /%LH`44/D4F?'V9/M@.+(S[\00P5\
M04#A2^BA7@.UWD'7G%.L3U\-/>C$NE3*1E4H6/9%E0=0$RPPE@._O;6V)*@.]QI
M91T<`8%*GJ;T,4[*KYS-(&8TRU#+$#]GIVW2[;;)(?S7,+6L,YJ)U1I-(B4H
M<E$MUI(9KK'J+G1;C7?RV:BB:^S&\$;+U/B.,(W1S$%*L"P3)!&9+UE.L*E,
ML[EJ;;+EC+("$09H6;SL*HR:-*CL;- .*NH<%;6;2BJ*^0S-!+(OBC@.7KLA
M<KU@.DS<YS!2%T1E6&MD$N )/V^XO7/,K><C2.69LGHTT$HR47+\^09XBLJ<W
MU(5<WM_=>:.FC&&:M5RQ<'D)2GJ1WLT!"Q _FKJRIVFV##L`XSM:`'K2DW-E
M@.;;!W?;V<)"\J1C,MHXC:?/6D/\YT.O"*R7/"<PWKYC\8=19D=<`R@.2X882>
M&*.SX9EC_H>GCK5=K4LX09VDXQ1R-D^ZI^>ZF$;FX+"/*="]Z?5O88822UPX
M@.W!=][L%X8OW$.8?Q>17[U_8/%N^>2)=C7N"*QRB$*&HBH)(A:Q=:&2108EM
MXH:;% 3*0LM3Z$9ZN*8%LXH]U:ECF1.?C/C2%<_L^&KJ4HN(:3)CJ3S1OREI
M05&T@.@.E?G[S/_8$9`*->?RP**T;-V<6:O#7R)O>C@.1DGWN!:?=PBH<O.H$SF
M? /C@.E',98%(=,6,#2'/`X++'*64B?Q64WJU$SLFB;,/NZ9I4V!E83$@.N;S[
MP>S*FU&7O[?+)MY5'_P%`J*]V]:HY)+BH^$C4D1F95TEN4RDG <U[YGZ>4\*
M/3O_,>UH[E#4,6!$WD)4+C#J"Y?6_+M$:=28?%Q2U>N;VG.K]R=5)>HU&8-+
MXZ6BS9K0,EN"DPNMQ[.);Z%@.B#9=P3B,A"*"0)D\4K#!!^56N SQ>:Y1"Y>S)
ME8G#',\1PF-YS^S8FJ^!+A4AAEL+N9B!7?6U'F<!I*WQI"ID`P6K"4MYN3(S
ME-3"T#!L<>G0SPN'Z,)"4;A*5S+I-H:?O.N)OX?>^KWR#_*;DU3]E7`>[O
M]\.)-^A]\9HZQM;:4]4#$E:\UU:H1_R*`RG.H](;V\:02H;WD[O[B4HV&JYF
M(X3""066"\HELV6 M08)F.*6P^BX<9M'D'U:<EZIO#" VJ67RZ>*OC HO__;
MUIIFC*\Q:8T_-7X;]@.=^Q;B6EUF6JL&C6<W>;6W&X-8?_=]:O0S!+4Q?$6]W
M^U<%J7$"S4*\\VHVHBQ=;'#$UEKGD7VJYD2'A^2_/7)(/@.DB\)4XNP>I.N-4
M@.T*W.8&\*4;_YA*[K!;JY AET&",C(*=F(-*<_AEQHJ)3>CH'%YV'%6TM4-2
M+.?'...$2:>/Y[>2JH-A:./NDZ(6=W4.EWKBUN53H4 9 <:&74W!D?'Z@.T.""
MVZW/:V54V#NXV'XKE&JW^8[H.,H,I-=E;CKO3^_J3;9!LU>]L4>^_NH-B/=G
M?SP9-\G8NX441_Z?).(`+3)!-KO$NP66.WQ,@.-4R@.#T>VI7T48Z:E6*N!KGM
M\LF:\@.')9!.6VB1OS+PG'_1ANR)\N^C'Y5&MB2OF[KI690?9Z B7;6:Z:%GO7
M$<0:-WI@.9-6EZWVR=359H-Y]&NETM?Y9,O/>JQW9T ^&$QE-,%0+91R\+;2K
MB:QIS11PIZ&[G+/P$6IQ*9]F,>@.DF)5W9'C9B==(+"WFI#<&]#77BE^T2T0Y
M>(O'OEP8MJ A7HSR,2>0.S@.>X45KP!W,NC$MS(PJ%?>0-2HMBH9B4&BUXC2H
MV7RUX-?3]_JE\IOWKB<?WW?OJH^JO2@.JGU;+Y]EX2Z%=U]!<K#,4.<Y135PU
M,W%]FJ-8I8(*?UNKF!K$XI!04'F]YNK/&= BIDOB"I_V73'TZ[=#;P?82>V-
MWH]&F^8>"5#+27\P&=8+W=2IRNY77JGHMR1M8H_/<L4"*'].T":UQ5>^^ ]/
M6-.4637?ZDK'9."RRL&EQ<)EA8>:#H#8+^UQE[",^72KQHAFZUQ1 /5:&94YK
M'[8)Y:^_`BU86?OD36.MRH=X5XY1/D>50#^)[V8N//VH.>$FOS.?=^(_\9L@.
M:#)D8W1 ;D;#+^3;/&"@.\.]'WT!N>"_ST'?LIT:>NDUK5'X^U$"$]W?7O8GG
M;$"SOS?V)L3Y)IXS?W</NYV+TXNS[L>3TS;VS=_PP:G/PB<Z#[!P?W>[Y_M[
M@.K:SF3C[@.9]1=;;]&=6_4$L#!!0````(`&.2!2]9\%($@.P@.``&@.>```C````
M1FEX960@.+2!S<%]-4V%R=&EC;&5C;&5A;G5P(%-0,RYS<6SM65MS&L<2?AZJ
M^ _]= !'$$"*K.08EV5I[9 C"06$G93+M;4L`VP,NWAF5I>7\]O3/;-W[
+M[+?(+BXS/3W=7W=_TSO(K>T&_L);AH+#&_/1=S8<!M!PUNO@.!L+MW%%<-O;B
MZ6MG'>KY7J->>S^JU\;6R>CBW?#]=&S!Q^'5KS#Z8(W'PU/+3-=KQV=7UABV
M(G#YG/:16_M\X@.CEN6N._QT_W-9KK/EF&\Z\.82^]S7DWIS[REMX7.#&)'M_
MHE6O.1(72J[ #]P@.]!4$/@.[,4:M#_L@.@.%"ZWE3-;<V#^M2/<E2.:_9?=5E:,
M_%I[KHH$*^6"&Y\+C0YC\D[2I]ST["_N*C-?,JV5^Y[[A3'/5X6%Z!Z[-R[O
M...>.)@.M3UQZ_L=7=EM];I"3-H;+$C9_R7BQ#;RZ5J!9P']) T^0=JX94<.4&
M<Y20&TRC@.HE?0V=-$9S;6DNEDIEG(J*E[B'*:#XQI01PG*:<JYK&J",,#MI6
M);'A8LEMS$I[XX@.O;K .-[X]\Q04_$GE0G^W) Z10V0UI!OB_W8;5 `S#B["
MQ>?@.+!07$-4(>!(HR<,MZ@.,'9#B3KO!F7%!UL1]?U&N ?R]>P(2[H?#4'9RL
MN/LE&O[1O%M_6"=)8+!^Y[.@.HRM1\.W
7ER8>W)E9$?OH,W;["0 1V-X]1JZM$(AT-0T8*?K#T5#XT.RUM#V28UFK'? -H'M[T.UV2V7O03B _U>JRNUG*F4`
M&^>VJ3^W8"&"#0&MUT=H2KA9<0R&(95!Q"Y:$T9AB3CK.@.<*S AXX_APB6C#!
MRNP65_L@.DLT0Q !"R87.[R;6&Z4UBXTQ*R4S9A@.;M+VQ#28S0]Q%K3@.DU5)N
M1X[C!O#[='1E71R?6\W4FA;\`(U.`U^SLXG])FK\EKM)@. <Z,8@.I5("F1!CM
M)>0!04AY[2V2%:]>FPPQ&4/?LEG!4G#))<]'<-1>=+9HC&,.UL>$]E&61R]U
MG64)<@.#IEST@.N%E*DCB;?(XG$SJF\.&;#J&9RO(.SAJD3"QG? !$(;GL;!_/1
M)%FZ*":C\C7:@.MR2PKDS@.,) -FE*,E@.K,6<F9I#Y0%"6)#91!$-^^$AICRD4
M1$ENF^2BW%HAR21!,/O/N.M@.&@./Q&$X*CL&:P^P.D+BV<H5*$ 5-<,0Q&-__
M'<-;OO1\$^U+@.407A*1VLT$Y6GD^T:H"(2B";:P2-&!]5]A9:BO)0KT=,951
MB<LU_Z".>>#Y2YA[BP5"X5->T?<V./,Y?8BI,ZUE(MB"@.S3<Z70(HG8[J:C\
M\?24FLK'S]05TJCUQW!R-6GJ>$ZL,^ODBO7TEW?CT3F;_#D9O?T-!R<P,KGY
MVVAX`3@.\G5CC"4S-(!M=P*@.S'9ZB05/]3L,?[7&%AMU:'\*>=X"DCB^.&73
M9#YE**K*M];[X04)?0?7F75Q2J]G$^NI.U7H,@.EF^7%*PZD(MII/"F&E;"1N
M*FJ"X00N1E=P,3T[:^E2X;>>5!*:D54OH,#1F4*+S"RJU.>#H 9C&M*%Y?A:5
M`#.<VFS,M9U:G% K^*[7:"JMX$[&C<O&Z>&"7!:Z!APPW *:C\P6>Z"WPYHE
MTSST(6JQ#;.FV.18#I41*?CA>IWW@.?J.;"=%$.168B[8>H>&M I!T/P/5[ Y9
M2"\-I!68:H\TI)GU#^-I`*T,3]:]5N32[M@.\$!=B_C0LN0@.D1T9E`+)&ZKXQ
MMC%>^D@.36:%F8H(DV*0QJJ0%H&TC22-HSIF]Y' I[)QI$HN&5.ROA+=<<O$H
M$Q+97-?S1"-*MC ])_7!GK\(LKU=MJE[NK,R0%<=!:9AQ4IT?.KQR:,M'FW:
MXZ@.'PNJ(I:CD\+-4CAI$[_"?G2URW$D.XCYR1SYDLS4.0D/"RJ&T57RS#80C
M[J!IDBVJPWZ+G'5@.R\7&\>FXU;/-;(?5@.Y;)<5),S5C4!&42/B^.#Q:YD7Z!
M/>.C(M-6I1S2T2.EQ!*?EWKL$BW"7A,=RJRE!&X,Y0=4W&AI6\P28IZ'E YU/
M)BN/`GAO;4Z6:"WM21-22KS)'$9&0^IYZGOU$T6%[S0_2#9)M.5A?/2IGN,8
M5D5&1:F=W)N0KY]O31-B(&UIMXDTBEV?R7T\>A7FGMQ+1E2PF4D5^.;0N-<F
M1RRLZXV:0E2/[:RZ"
V,^I<#3[FVH,.'43SVM:>18\[L8A*1/#33:E(]@.D?MY<XG,^^>I"D'TQ4^=$I&`8V,BX_&0>-#H[2!>W*^Y/1G-3TG78R65O6QE<^4
M'7EBFD?V#*34=T9*?1.DU#=&ZAE 93/UNZ&5V>2?0I91]<UPR]RCY*\#J7:I
M'[#-=;.ZLX7C1\<O[8/2UW@.^-).[R_W#5MP4M79I'5N79\<GYB$G,X,'2[N!
M+[:&_]$]-&2>2K+[4#QO34!/M,9B.^FLZ7XQ:GI_*-PB(?CF)$^U&G#SN]QO
M/#7F.91CEG\:RCCV+\[/PIDZ;/1$1:U1>F(F)R4^B!B!^$%6_A>&2Y_.22Y$
M@.,VU;ED#UPV%:=WF&87%HSB")WN9EMZL5:Q-#^T'%J?.B.!&YI4LN;_"R 78
MJK;!6YC[*T_J#F+MR/@.J0/LB^((>&A1UXWR3]*/TO%49_K(;X_B:,&>GS@.%S
M^?;J=?1XI"-6YGK&ZN02VBYQO0(Y,V8GD7L:^B65%BG0'>H@.O80V/]NUVV!N
MJQ 6NJF"3QL$EHO/G4_S68"O:95\!GT1%9=)H^07OH966#+!>OV#_:/#EP<_
M'[%+8#W69>U>]^7^RX/>47^?]0YQH,OZW>Y^NWO4[OX$O=XO^T>_]'_N'.SO
MXXP6P(5==K!3+O[79]TGF-([['4/>WTTA^WW'[!$"SS!DBY94J]-+T^/KRRV
M`]UZ;6)=`?M$CX*A_#S(X*.OLS_-',EMZ6)V.S;RY>=![[!>,R%ANV-2K\E_
M\!-P][$_`?\-4$L#!!0````(`+=CI#!H;K=/X0,``.4)```=````1FEX960@.
M+2!S<%]-4V5X8VQA=7-E(%-0,RYS<6RM5E%OVS80?J8`_8<#]F"KLPT[+99@.
MJ M[B=P&3
.=A8,02#0$FVSE4A5E)+TW^](2K;L=D:Q[$60>+R[[SY^=Z+*MHUB*%5]7!8.)?14T8S"&#DU3^015GM"2J4ZO,3_2M#+V4<=UW@.>N$_KGP <WL
M\OUMZ,/=Y>(#!'_Y87AYX5NSZ]"T9 7DA8Q!Y='UG#W'*:T4<QTR*>DR98+'
M7X"+$G/DU9(G4 G^M6(\8:+D*X[.@.%&4ZRA6@.I"QK$0)4KA.PC"206X"@.GBD
M1;RA1?...<#CT6O85UQ@.P,F9I+7^67#3)#Y8-L%W D].]>,>M2XI C^ZP>*)#
MV"<'L M6QC)A%I[KL&<6;Q?'EDQ+(![9JI"9J67'::\-1588H]^'CU/-8\KB
MLFT=PY^WP<*_F5[[74!,1:1C=BN>>.#!K] 9=/#9VF-4XH'."LE2#M0W)9>?
M,:J"IPU#\+6,=CET!7F!I1RL\15,)JPH9/'VW1!DL:U0?^)K58CNR*NQ0Q_^
M8&LNS&=3QO<EZ.0>6'3?(3,R@.&[M;2(10G /&AJ/C!5K1HN2QRG;5H24-E5M
M.?8:-LGD14RZCDY-=F!=QV0E[)FK4G6;8D='(=HBQKI$*I(?(X86E[Y(]!$T
M@.EM%,9S?AO,@.A*O@.?'H%L^E\$<V"\&X:7L *SZ:!@.7FC)GH/=,-$5M.UI+&W
M]W"J:HE';K<T8(W7CR%J\'84C.N9@. $1!X3^] *"FZN_74?F3&C$R!SJ90."
M/9>6'%T&ZDSN&KQWT'*:7(Z'U9U,C'.D2EI6"MZ^@.[[6&EE:D9& ?;+E6GMWP
M,!U'CLI[+1'EC/(4YR_NQ6.9*MBP-&\&IN;<),WH%\8%RJG4ZSUX8A!3`78)
M$E[@.J:3?`,.5FSI4R;(<+!2JM,.RXBD.UQPRB?3',LN09V5RH %,32\<?V A!
M5>RV:8'D>.X@.5Y!OL(/A;##0&_54;B8P_A?TV9NJ<4]4R">%BT.SV)!JS%;7
MVS:L=:U[HS66L%V@.>Q.@.&#]ZT+/6'<%[5JNICI8SJ2LQ&OA%TQ!G"70-Z![@.
M>XE2\<#\R1#!6:^![QGO_7H.A4/^Y_B&CXY1O"EO6]H`N5OCV(AEJF'47QXQ
M#J29?2V21]K"=$=W7HSQO[24S>TZ<2H5LYV9,'V+B/$&8;]=IQ[H0Y.F5O[O
MZ-MR(H=>I/47:"X5J,ZY?^6?+^ 5S,+@.&NXSJA#-P^ >?T?XW$W2![C[X./E
MI+G8[%U"C&!N/UU,%SXY$L)UYOX"R+V=$P_C_FAX^OKTS>CLY'5/'^&]UFRD
MX@.W+:/2(,<:CWUS'YB7_GEB]X/XU_-G[US]02P,$% ````@.`=9'Q+F(V27*Q
M`P``G0D``"<```!&:7AE9" M('-P7TU39F5T8VAI9&5N=&ET>7)A;F=E(%-0
M,RYS<6RE5EMSVC@.4?C8S_(?S!LD"A4UGVX>Z`TV<EMFD9!W3/F0R'E\$*#66
M*\E)TU^_1Q*V9:"9SI1AT.4[.OK.%8DB3%B^HNN2$YB::1YM" ;C0B[*,/4%9
MI)$DHC>HX,<H*S4^Z74['Q?=CN^=+SY?SC\N?0^^SH-/L/CB^?[\PC-PMS.[
M"CP?;OS%N7>AA$017M^NB$PV-"6YI/*91_F:0+<SE5&<$47 <1SQ+-1L@.-M1
M^E *&;(\>W:<F$K4>:LTIR3)(L6<HS:6$L!C-)<6P.('FCH'VRD5DM.XE(S7
M%QW":>P<0XLRSJC8$/XR&JKCAWA.?LA0$*)8Q73=YJ4=X1Q#Y(83L6%9>F"+
M\1E-OL%1,PO.$@.3RQX@.GFXCWS\;C$TND"D$HRJ)@.7!H-@.F0DD98Q[G1ZZ_D8
MV,^S:^\(CL:Z:1PJ6_LG*C3=SG (_\[@.`T%#U-*IKQ2LY D)V5-..-0.:O#O
M9931%26I5F=)X%<0>2#@.0I,W1HJNK"V@.`G(F(2^S#+'8$,+0: !N<-AT7RM%.
MC[/B;*L"B#F$@.@.*8VG0>&,T5IU(0+J#4>P[+@.8U*FNKS.*K=)W0+< =CH&$=%
M4K-L7=XF6C$\8N]_RT7@.J4CT6PI.X"_HC7KX:PG4UV)8')*GVD,Z.I5Z72.H
MU=@.9TG3OT MR;68G3=@.]=5&3)_M9YNYO#.P\=D$-VE85`^7M+>%K$G%)DXP(
MT*X%S<<UM-1EKTZ[G=-32!D4A&^I$!3#DFQ(\HWF:X1>=3OD!TF:;N%"&K.1
M;D><%%EX,[L*.4/&ZDR;4+/H=E3<=BK>O1\#XS"=8L=;^&J%0,ESZ$]V5?"+
M&S<D*ZPFA!)%(OACE2LVM%@.&-\M@.8'4E`$L&ET9"I<S\LN("[]Z#X5;=K39T
M6MD4;[TK[SQH.@.4J]@.-_?MVW*31YU<;2V""U%W53G^EFW6KMO4,_-#?:3::>
M#L 4%G[:3::ULJ7JE'6;J8U;_R'N9 ##(>
V0.UUPC6#=IMIE40&BEMEVN&M0[3NUFXSK<.T'R0<]X/4SJ+AD.944BRUGP1V10`)RU1MJ1Q?89BC-?I;C$QV
MVK:.K0H^4G6UB4-MR@.!V0T-;E^"N0FH%QFY3AU UAJ84S1\_MH)=?IW"I;^X
MAKMM)"3A]Z,[3!G\;9KK/7S]Y.';H'I\_.*-T%-JES<7L\!S7E"F\CH`YT[(
M2);BWAU.QF_.WKR>O/W[3*?$71P)$@.JL\VT4/J(.=_)/MV,8.+]#0?S!NVG\
MN^^F_P%02P,$% ````@.`MG$!+T.6BAYC! ``1PT``"4```!&:7AE9" M('-P
M7TU39V5T=&%B;&5C;VYT96YT<R!34#,N<W%LM5=M3]M($/Z\D?(?1KH/MN^2
MR X0N$H^E0.W107"A=!^0,AR[$VR/<?K>M<$_OWMB^VLK4 /]0ZDO'AF9Y^9
MYYG9#<O#F&9+LBH+#._UQRS:8/#!BM*4;J',DXAC9@.UJ\V.4ELKN6?W>QVF_
M-PO.IM<?+C[>S0+X>C'_!-,OP6QV<1YH<[]W>CD/9G SFYX%Y]*)Y>'5[0IS
M'BU2+()RG'$&_1YZGY<+DD"9D>\E)HEX3)8$%_U>I,P)CM-(XE0+,Q+_#0@.A
MDG'3EN%M&,6</.+]-I+5UHXQ*KC,7*QBSTQ^,HV/1"RMS-EC5,3KJ+ GKF/Z
M%'2[*DD2TU0[[@.G#GK,XE+%>]/A>4HZ3L.4(S8[>X:&SQWN'[D5/6:T*?R=O
MNO@.F:HX:P]Y",UX8*,:.]F-8\,?;=17*.(+AD.4X)E$*HJHD3C$P'O&2P9(6
M$"4)R5:-)5IR7( H1,[6E'>B-C$G@.'XNZB[PG.;@.F2+RH:[.H$.1+XHCEJC:
MVLJBJN4,JK+YZG70B,>OZ$3+@.FY T+O!Q0I7F!ALUUA458O<ATKM49: K1/Q
MVY4469G/]5-9^NJ/%HG(<?'<P(?3VS-AWJY)VA!+&&240U:FJ5RYP"N2J1 ,
M\P[!/HAF?,0%M[.:YX'AXE3+-#MMM<L:RK<Z;_&XW&1UQCI=C4>FJZUY07.Q
MV;,M*ZBK;Q&VBVLYOM?:LI&Y;UW=JLJ&]?0(+?BM8:&UJ-LB_E]WTWEP?7H5
MV+N .K7A\*ID'!*!"_@.:@.S2#39: GPCCS%'8"QP76$Q$M:*Q"0;U?K\V)=#2
MJ4N@.MMYMJ$(]\>=<3=(OE@.:@.R)',:H[Q$X[!MA0>A44EV4U(+\59LB_MMIJ-
MU%L&$6(XA,^G\&>CCMW(HF41XY!N,]E/S<!"YA"*4CFG$YV9Z;,36L?)[S3:
MSEN4M&WJ*MB0<)4M:H/TH1PU,54G(H,.6O7/-THRB;5DN&!0UEU%,Z"C4@.FV
ME._ZN>(0T='+V"O*%'H33!>\R5"G(B8[1@.A'D&Z-)/6OT%<KP"SXGH/$[VY;
M$Q\TBZ7H;$MK_!75B6<Z'PO$X=P6?[*@.HVZ#5FU@.FU-7!6Y-()&I;C(]!*#F
M&:&ZO]2:SNR1J]3&)M)VXL+%<627M9I$3R0?KN\N+TW#:R?$?W! P/[3P9#:
MOC.B1O"'@.>NM9T>UQXLGA[P#B'[@.\ O'FSQ4&X7B=!759/J+3-RN295?'% 7
M0F9.4]T-0I"HO@.(*E=T&E\'97&CDPVQZ!?>;B(D3^F%T+]0B7G<=^@.!?/P7B
MEEA?0_?>%BT5<J\)C3W7_=T[.3J:H!M 'G+1T'./#XX/O9/Q`?(FXH&+QJY[
M,'1/AJX'GOO..W[G>:/#(VE1#F*ABPY?]:O_Q\A]$QAOXKD3;RP`H8/Q#[ H
MAS=@.<=^(Y?\O3+]W=W-^.@._0*X3W>[?!'-"]%NR#;Z :2,7>+R*&0Q:O\28*
MQ?WDP?<F_9Y6"?J13/H]]A._<=Q_]QOG'U!+`P04````" !25Z8P< 3.)?8(
M``"?* ``(P```$9I>&5D("T@.<W!?35-M86ME97AP86YD<')O8R!34#,N<W%L
MQ5I9<]M&$GZ&JO0?NBH/(&U((1SO>A_"K+0QG:AB2PXEK1]<+A:.D8@.(!!@.,
M($K_?KOGPH $Q$.BEQ5')*:GNZ>/KWL&P^>3*,]NDMNJ8' BOV;!C,$0W"!-
M\P54\S@.H&7<]/7P?I)48]]W#@.]\N#@._&HU\OSC^<_78]'L&7LZO?X>*_H_'X
M[/U(#A\>!&G)"I@.7><1BDL/GDT^7L^".L8=YD,4T<'@.`^#F95Z&0KC[\D=-/
M3XW>),0HB=5HDI5ZA%A8$]4\.7AZ*?_^^ K>LR@.-4($@.CI,RR;,@.A?N@.2((P
M91Q>_2CI8D5$RI"L*DO^KE@.2LZQ,;A)6+%&%`6>3+(GN2)^EL ;_R).L:,_-X
M64"&:D33H.CY@.WX7CS5TVCB3-71";A[^A4OK4+AK4,PLR5@.U_S?OE@.0X)R&[
MR0LVN4_8@.IS@.=-,J>>M8:IT7&2M@.+;<-R?![Q2VI;P>#%<*"E5$>,Q5K2X.S
MBI>3:,I:G4N+GY2/<]8V\[9*XBA/=;RN4Y7(!>V3EA02NSPG!J6\IWA$LW@.R
M3UADDRF['!XX1T=PR:*J2,I'$.O&9\D-^/#S+Y#PR8S-0E;TW#B4+G!QEA.R
MVR3#O\[X].P20>%B##W_'V_>OO/ ]STX\HG(03M7108^?F=93,)$$K.41:5.
MPR'(OS=%/J/\GK'BEN&C-(D"2F4.BRG#12CP,DB"^ +7GS^/QCU!S)&H/Y0/
M3DXX*^Y9071]06A()G$XQ(702*^O%4(#E-.$6T"&/\H<0@.818B6+(7R$A_F$
M/;"H8+Q*2\Y*#WANIB^0LF (IQ! R69S$*'OH=P2HGPV$SJ0`S@.Y,8<$I],S
M98IRRF:05\J[AJMB63,DI>HIAG/)'DJ:#OF-G*LGBCD_T'R,`.CQDLU)/DC,
M0W>?7US!^?7'CQX@.@.6#3C \4D:;$"DM%()(U9C<!&@."R*DV-`1&!/\A*0UH0
MG38`Q;G2`\%#FED\DZAFL%G'1 VZ0PB*4GP5E<+&W"&8[U85$?7"A@.!%)B7)
M9S5E(]QX%
'):&.-QV=*DS)SA8[.:2_MZQ!9NP0Q%_/!HXAF.]>([V'J$\6MJ1\-_= 2242EK%,U;0MZ:FS85,LJ`;5:2Y@.N1Y!<9H@.U*F?VX3F*&:^UV $O&
MR!#^O+ZX&IV?AKU1/9ZC1IA#Z,W"ZDEPFB_;_22^FN-I#JU1UI,TBW9*CN[
M2JZ-WI1LEXJAQ#;-!A]7LZQK`<*H=1B+;!<3$+SFK,"<[I%C9<ZX"2_RA9+E
M]H?^ZO)-$=I "RN"7E"+NH8U@.\]*C;Z!Q#^KG( -P4^'[#' 64F /0MBI3Y&
MGUS,8II$4QQXA&EPC^ 4QT#8%D24Y\=:C24=:D?7C_L6;:._&^*Z,RPU9<_N
MS#R+RI[::/DZIQHJ>VJC"^R<JJGZ=B41\^L6`!M\51_J>A>'^;$+KZU^^S6X
MEH,1)](\NQ7%HWYZ>@.E4Y>LV0]6C9@.WQZGZ+IH,K&209IE$IRZ$N43U5A?H@.
M]B(<>K7>_:[%D K8KF@.5A^#7&JHVQ8Y3VBWD6*;#*KW32J *<L<"/R@.NNBZ9
M#8L*5KW$(9R[KMQ!F3FDVDT:D K"E@.V7D3UE+@.F2G]M)7+<IECJ.VGQ#VF#1
MHPKW;7^G1IOF'++%"2L*++?8P T`_QH.XH'NRG9W!";B'Z=P!/^1YL6?K:[!
MS+=Y*S/U!.!2?'N@.<,$31L&.ZBZ92T?TM<7CA)=)AE^$O1JY]]I(UA_<R]9D
M$M?1J,<U^G@.PP/\D2M24$N*)LF6V8+DBR:X-9J)53L1$O>)0>;Y74ZD6!<ED
M@.THC'4+:UH'&#?5/,3\\-E;5X=<`&PH_T7 :"R/90.?B_\%S^W8;@.5.W-[=T
MI6'V; ]_=_?J5!U9,/'"``S6NL193,IHQU#-Q19.'< XCM.*H;&D%J[5UI2V
M;*S%%\O3)I%;3\?I*9;Z>0L7!<@.#L1]UNJ5INE4YMLLV%4@.XVW=%:7(VQ7!'
MEK&-H+LV.*/0>I9#ZXA YWU)TI1VLZ)?0C[R' 27BQOB:5#24(!=%$G(\E(N
M_-^F6J+^[ '3GAM#O7J1_0(TBASF04_NV!I[NS[\`@.-K32)0K<,<TQBP%/-R
MK:K/W1,V=19D\L!Q<L<>R9O^-KJBL5]&W\:NNF6WJ#^K:T.5E_O+=M4'3S>?
M5NS2XE::M2ZDT-V6B;N7:;A@.;TFZ>UINW&&YZ]K9VEB4H\B&%F K5!-T5O...
M>S'"Y V*^9&_8P=&_#?KO.IE9=MT7[6 CK*<->MRMJ8P=Y;,K=RV/Y_MQV%/
M]UX;.K&[Y]K%MR_OV$9C1>PM\-PY\1V,BS&;Y?<M_1/^6PVD]3U5;:U&HW/4
MUE&UMS>M'!#ICGS5XFP.GMM@.I[.+_>2KBY5C33H?HA)*I];UVXM5D'6<MGJU
M=]C<<C/T//Q<M@.WEVMY!U$PSYXTD=NNT$YG<?@.2T-XC<KW,VP,K].FR_WEI"
MR5U2VED#BGM&15CZ[(21NYSI;=EJ[F9<IC<I9@./7VLLOG:.V-#0[]NV#%?M_
M[UWS,W;.QGAZE]9XR^=O9CHZ/P'Q;N,+O6[.(,XAKPJU\UXDY52WB3* /?E#
M6G6#0^H7#GN1Y/;;*T*&&O#J%RD$,TTVVP7"]T@.;9V\1@.>X40;% S,HSMX0P
M+W%]JL%'8+7-8-Z,JY?B'*N1>,E%-YKP7_08(>H9QM;[<R[\)N:J#B=0UYJ
M3AF(\AC@.BNX*5 7'*A*+&PWB=@.,:4,KGAC,)J[(@.BMB<@./T1>)HO/"6#M%GD
M51H#ELLTE;<CN#G+R8OY-,A8+ ^+(D&81RCV6.UGS_,%F4/%$5T46+G#8*Y(
M@.'R/B$QCLD<N#Y]$6M"%C,(3')>O9&"VH%XJ*IK<:;I\Z\7%`"^%,<P;,*&D
M4DU?A9 IHV]/2%5"M$G)YD0MK\#1Y9G1Q]&O5_ */HPO/L'768 4Q;?CKW&8
MX__K%\/?X,OOH_%(WV1Q6V[+N<3R^O/[TZN1\P2CPX/+T14X7WD9E!7_-CSR
M!^]^>O?6_]>;GSQ"XJ^BF> ((;-@.<H\\AOX_#P^D=&>=>/Z,FX.#36\._@.]0
M2P$"% L4"P``" #-D/$NU$4\;<@.I```LO0``(@.`````````!`" `````````
M1FEX960@.+2!S<%]A9&1M97)G96%R=&EC;&4@.4U S+G-Q;%!+`0(4"Q0+```(
M`*ECI#!<5R3*=@.D``*PE```A``````````$`( ````@.J``!&:7AE9" M('-P
M7V%D9&UE<F=E9FEL=&5R(%-0,RYS<6Q02P$"% L4"P``" !CD@.4O6?!2!(,(
M``!H'@.``(P`````````!`" ```"],P``1FEX960@.+2!S<%]-4V%R=&EC;&5C
M;&5A;G5P(%-0,RYS<6Q02P$"% L4"P``" "W8Z0P:&ZW3^$#``#E"0``'0``
M```````!`" ```"!/ ``1FEX960@.+2!S<%]-4V5X8VQA=7-E(%-0,RYS<6Q0
M2P$"% L4"P``" !UD?$N8C9)<K$#``"="0``)P`````````!`" ```"=0 ``
M1FEX960@.+2!S<%]-4V9E=&-H:61E;G1I='ER86YG92!34#,N<W%L4$L!`A0+
M% L```@.`MG$!+T.6BAYC! ``1PT``"4``````````0`@.````DT0``$9I>&5D
M("T@.<W!?35-G971T86)L96-O;G1E;G1S(%-0,RYS<6Q02P$"% L4"P``" !2
M5Z8P< 3.)?8(``"?* ``(P`````````!`" ````Y20``1FEX960@.+2!S<%]-
M4VUA:V5E>'!A;F1P<F]C(%-0,RYS<6Q02P4&``````<`!P`T`@.``<%(`````
`
end
|||Thanks Kestutis,
to clarify though, the issue stems from the fact the tables I'm replicating
are not owned by dbo, right? I am not at an advanced (or even intermediate)
level of sql server administration so executing scripts that I don't
understand make me a little nervous. What I mean is, would dropping
replication, then changing ownership of all the tables to dbo, and then
recreating the merge replication be an alternative fix? If so, I may prefer
that, if not, I will try to get famaliar with the scripts you supplied on a
test server and try to use them.
thanks again.
"Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
news:O2YNs$PZEHA.1152@.TK2MSFTNGP09.phx.gbl...
> I attached fixes to stored procedures which are designed for SQL Server
2000
> SP3a
> They should be executed on master database. Be careful with them, execute
> parts of every script step by step.
> At the end of every script there is update to sysobjects table, which
> restores initial state of stored procedure (which is changed after "alter
> procedure" statement is executed). So before altering procedure, check if
> this update will restore correctly stored procedure status (status in
update
> statement should match status which you will see in resultset, received
from[vbcol=seagreen]
> select statement which is commented near to update).
> Those are procedures which i met on my way of deploying merge replication.
> First of all I fixed four procedures, but when I added publication
> filtering, I had to fix some more
Now I am applying those fixes to all> new servers I am installing (where merge replication is used) and every
> manipulations to merge replication are working smoothly.
> --
> Regards,
> Kestas
>
> "djc" <noone@.nowhere.com> wrote in message
> news:%23d2H5xOZEHA.3368@.TK2MSFTNGP12.phx.gbl...
think[vbcol=seagreen]
issue[vbcol=seagreen]
to[vbcol=seagreen]
> not
MS[vbcol=seagreen]
does[vbcol=seagreen]
> leaves
> table
I[vbcol=seagreen]
are
> (and
>
>
|||Yes of course it is a much more appropriate option to change the owner of
the tables, because this way you don't have to modify system stuff which is
not so nice
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"djc" <noone@.nowhere.com> wrote in message
news:ernO0wQZEHA.2500@.TK2MSFTNGP09.phx.gbl...
> Thanks Kestutis,
> to clarify though, the issue stems from the fact the tables I'm
replicating
> are not owned by dbo, right? I am not at an advanced (or even
intermediate)
> level of sql server administration so executing scripts that I don't
> understand make me a little nervous. What I mean is, would dropping
> replication, then changing ownership of all the tables to dbo, and then
> recreating the merge replication be an alternative fix? If so, I may
prefer
> that, if not, I will try to get famaliar with the scripts you supplied on
a[vbcol=seagreen]
> test server and try to use them.
> thanks again.
>
> "Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
> news:O2YNs$PZEHA.1152@.TK2MSFTNGP09.phx.gbl...
> 2000
execute[vbcol=seagreen]
"alter[vbcol=seagreen]
if[vbcol=seagreen]
> update
> from
replication.[vbcol=seagreen]
all[vbcol=seagreen]
> think
> issue
> to
are[vbcol=seagreen]
> MS
> does
Various[vbcol=seagreen]
just[vbcol=seagreen]
your[vbcol=seagreen]
replication.[vbcol=seagreen]
> I
> are
this:[vbcol=seagreen]
not
>
|||thanks again. Do I also have to enable 'cross database ownership' ? I saw a
similar issue that mentioned this but I don't know if it applies to me?
"Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
news:%23CZMK0QZEHA.996@.TK2MSFTNGP12.phx.gbl...
> Yes of course it is a much more appropriate option to change the owner of
> the tables, because this way you don't have to modify system stuff which
is[vbcol=seagreen]
> not so nice
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
>
> "djc" <noone@.nowhere.com> wrote in message
> news:ernO0wQZEHA.2500@.TK2MSFTNGP09.phx.gbl...
> replicating
> intermediate)
> prefer
on[vbcol=seagreen]
> a
Server[vbcol=seagreen]
> execute
> "alter
> if
received[vbcol=seagreen]
> replication.
> all
every[vbcol=seagreen]
how[vbcol=seagreen]
> are
from[vbcol=seagreen]
SP3a)[vbcol=seagreen]
> Various
> just
it[vbcol=seagreen]
drop[vbcol=seagreen]
> your
are[vbcol=seagreen]
> replication.
elements
> this:
> not
>
|||As far as I understood from your situation description, this should not have
anything to do with 'cross database ownership'
Regards,
Kestutis Adomavicius
Consultant
UAB "Baltic Software Solutions"
"djc" <noone@.nowhere.com> wrote in message
news:OMyx$qSZEHA.3716@.TK2MSFTNGP11.phx.gbl...
> thanks again. Do I also have to enable 'cross database ownership' ? I saw
a[vbcol=seagreen]
> similar issue that mentioned this but I don't know if it applies to me?
> "Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
> news:%23CZMK0QZEHA.996@.TK2MSFTNGP12.phx.gbl...
of[vbcol=seagreen]
> is
then[vbcol=seagreen]
> on
> Server
which[vbcol=seagreen]
check[vbcol=seagreen]
in[vbcol=seagreen]
> received
to[vbcol=seagreen]
> every
I[vbcol=seagreen]
the[vbcol=seagreen]
> how
they[vbcol=seagreen]
> from
> SP3a)
> it
> drop
this[vbcol=seagreen]
> are
> elements
should[vbcol=seagreen]
a
>
|||thanks again.
"Kestutis Adomavicius" <kicker.lt@.noads-tut.by> wrote in message
news:O9kaUAYZEHA.1248@.TK2MSFTNGP11.phx.gbl...
> As far as I understood from your situation description, this should not
have[vbcol=seagreen]
> anything to do with 'cross database ownership'
> --
> Regards,
> Kestutis Adomavicius
> Consultant
> UAB "Baltic Software Solutions"
>
> "djc" <noone@.nowhere.com> wrote in message
> news:OMyx$qSZEHA.3716@.TK2MSFTNGP11.phx.gbl...
saw[vbcol=seagreen]
> a
> of
which[vbcol=seagreen]
> then
supplied[vbcol=seagreen]
> which
> check
> in
> to
that[vbcol=seagreen]
> I
> the
out[vbcol=seagreen]
> they
server[vbcol=seagreen]
you[vbcol=seagreen]
because[vbcol=seagreen]
on[vbcol=seagreen]
> this
Fixes[vbcol=seagreen]
get[vbcol=seagreen]
> should
in
> a
>
Cannot remove push subscription on SQL Server 2000
Hi,
We have created replication from one production server to another backup server by using SQL scripts. These scripts have been generated by SQL Server after manual initial setup. When I ran these scripts they did not add the subscription for the backup server because a stored procedure were missing named something like sp_addsubscription. Therefore I ran the script on the production server and created the subscription manually on the backup server. But I made an error, I created a push subscription first but I should have created a pull subscription. Now I can't delete the push subscription. I don't even get a error message. I can't press delete and when right clicking on it I can only choose Help. The subscription has the following properties:
Type: push
Status: retrying
Last action: The process could not connect to distributor 'PSERV'
Replication type: Snapshot
Anyone know how I can delete this push subscription on my backup server?
Best,
/M
When you right-click on the subscription, are you connected to the production/publisher or backup/subscriber.
Try to do this on the publisher and see if you can delete it.
You can also call sp_dropsubscription (with the appropriate parameters) on the production server to drop the subscription.
|||Nothing at all exist on the production server. The distribution and the publication has been removed. Only the push subscription exist at the backup server. And I can't delete that.
How can I use sp_dropsubscription. Can I use that from Query Analyzer. Does anyone have a SQL example for that?
Best
/M
If you just want to get rid of replication on the backup server use sp_removedbreplication.
Note that this will remove all types of replication: merge and Transactional.
Use this only if you wish to remove all of replication.
|||Additionally you can use the following:
sp_subscription_cleanup: for Transactional -- Removes metadata when a subscription is dropped at a Subscriber. For a synchronizing transaction subscription, it also includes immediate-updating triggers. This stored procedure is executed at the Subscriber on the subscription database.
sp_mergesubscription_cleanup: for Merge -- Removes metadata, such as triggers and entries, in sysmergesubscriptions and sysmergearticles after the specified merge push subscription is removed at the Publisher. This stored procedure is run at the Subscriber on the subscription database
|||I used sp_removedbreplication 'db_name' to remove everything at the backup server. It worked as I wanted...
Thanks very much!
Now, I am happy again... for a short time :)
Best
/M
Cannot register subscriber
We are setting up a test laptop to use with Merge replication to a SQL 2K
server that serves as both Publisher and Distributor. I was hoping to
create a push subscription but that needs a register server setup that does
not work. When I go to register the server (MSDE on laptop) from the
Publisher, it shows the laptop computer name in the "Select a SQL Server"
dialog box. But when I select it and choose to connect using either windows
authentication OR SQL server login I get the message "SQL Server does not
exist or access denied". When I setup the laptop with MSDE, I set the
authentication to be "Mixed" and entered a strong sa password. Can someone
tell me why this is happening?
p.s. I can setup the laptop as a subscriber using anonymous settings using
Windows Synchronization Manager from the laptop just fine.
David
Unregister this SQL Server in Enterprise Manager and then add it back again.
I think you are having name resolution problems.
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
"David Chase" <dlchase@.lifetimeinc.com> wrote in message
news:eRe$lX0BGHA.3584@.TK2MSFTNGP11.phx.gbl...
> We are setting up a test laptop to use with Merge replication to a SQL 2K
> server that serves as both Publisher and Distributor. I was hoping to
> create a push subscription but that needs a register server setup that
> does not work. When I go to register the server (MSDE on laptop) from the
> Publisher, it shows the laptop computer name in the "Select a SQL Server"
> dialog box. But when I select it and choose to connect using either
> windows authentication OR SQL server login I get the message "SQL Server
> does not exist or access denied". When I setup the laptop with MSDE, I
> set the authentication to be "Mixed" and entered a strong sa password.
> Can someone tell me why this is happening?
> p.s. I can setup the laptop as a subscriber using anonymous settings using
> Windows Synchronization Manager from the laptop just fine.
> David
>
|||That did not work.
David
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OxlsptDCGHA.1288@.TK2MSFTNGP09.phx.gbl...
> Unregister this SQL Server in Enterprise Manager and then add it back
> again. I think you are having name resolution problems.
> --
> 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
> "David Chase" <dlchase@.lifetimeinc.com> wrote in message
> news:eRe$lX0BGHA.3584@.TK2MSFTNGP11.phx.gbl...
>
|||What is the sa account you are using? It should be the sa account of the
publisher - not the 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
"David Chase" <dlchase@.lifetimeinc.com> wrote in message
news:ORhLPe$CGHA.4080@.TK2MSFTNGP09.phx.gbl...
> That did not work.
> David
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:OxlsptDCGHA.1288@.TK2MSFTNGP09.phx.gbl...
>
sql
server that serves as both Publisher and Distributor. I was hoping to
create a push subscription but that needs a register server setup that does
not work. When I go to register the server (MSDE on laptop) from the
Publisher, it shows the laptop computer name in the "Select a SQL Server"
dialog box. But when I select it and choose to connect using either windows
authentication OR SQL server login I get the message "SQL Server does not
exist or access denied". When I setup the laptop with MSDE, I set the
authentication to be "Mixed" and entered a strong sa password. Can someone
tell me why this is happening?
p.s. I can setup the laptop as a subscriber using anonymous settings using
Windows Synchronization Manager from the laptop just fine.
David
Unregister this SQL Server in Enterprise Manager and then add it back again.
I think you are having name resolution problems.
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
"David Chase" <dlchase@.lifetimeinc.com> wrote in message
news:eRe$lX0BGHA.3584@.TK2MSFTNGP11.phx.gbl...
> We are setting up a test laptop to use with Merge replication to a SQL 2K
> server that serves as both Publisher and Distributor. I was hoping to
> create a push subscription but that needs a register server setup that
> does not work. When I go to register the server (MSDE on laptop) from the
> Publisher, it shows the laptop computer name in the "Select a SQL Server"
> dialog box. But when I select it and choose to connect using either
> windows authentication OR SQL server login I get the message "SQL Server
> does not exist or access denied". When I setup the laptop with MSDE, I
> set the authentication to be "Mixed" and entered a strong sa password.
> Can someone tell me why this is happening?
> p.s. I can setup the laptop as a subscriber using anonymous settings using
> Windows Synchronization Manager from the laptop just fine.
> David
>
|||That did not work.
David
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:OxlsptDCGHA.1288@.TK2MSFTNGP09.phx.gbl...
> Unregister this SQL Server in Enterprise Manager and then add it back
> again. I think you are having name resolution problems.
> --
> 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
> "David Chase" <dlchase@.lifetimeinc.com> wrote in message
> news:eRe$lX0BGHA.3584@.TK2MSFTNGP11.phx.gbl...
>
|||What is the sa account you are using? It should be the sa account of the
publisher - not the 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
"David Chase" <dlchase@.lifetimeinc.com> wrote in message
news:ORhLPe$CGHA.4080@.TK2MSFTNGP09.phx.gbl...
> That did not work.
> David
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:OxlsptDCGHA.1288@.TK2MSFTNGP09.phx.gbl...
>
sql
Tuesday, March 20, 2012
Cannot open database during merge replication
Hi All,
I am replicating an SQL2005 express machine to SQL2005 standard edition server using merge replication.
I am replicating an SQL2005 express machine to SQL2005 standard edition server using merge replication.
I have a simple VB application using ADO polling msMerge_history at the subscriber every second so that i can show the end user the progress of the replication.
When the subscription first subscribes and after the initial snapshot is applied replication downloads all changes from the server that have been changed since the snapshot was created.
Towards the end of this download faze the VB polling application fails with "Cannot open database "DBName" requested by the login. The login failed."
This connection fails 4 or 5 times and then normal polling resumes. The scary thing is that sometimes when the polling connection fails the merge replication does not complete and if i check msMerge_Sessions the "runstatus" is stuck at 3 (InProgress).
1) Is the reason the ADO polling connection fails because of some sort of lock between replication and reading the system tables?
2) Is replication getting stuck because of locks?
3) What can i do to get around this?
cheers,
Tim
Hello Tim,
Please try to use uncommited read isolation level (or SELECT ... WITH (NOLOCK) )when querying msMerge_Sessions table.
But result row set from this query contains uncommitted transactions.
This posting is provided AS IS with no warranties, and confers no rights
Cannot open database during merge replication
Hi All,
I have previously posted in the MSDN forums with no responses, so any
hints on this would be greatly appreciated.
I am replicating an SQL2005 express machine to SQL2005 standard
edition server using merge replication.
I have a simple VB application using ADO polling msMerge_history at
the subscriber every second so that i can show the end user the
progress of the replication.
When the subscription first subscribes and after the initial snapshot
is applied replication downloads all changes from the server that have
been changed since the snapshot was created.
Towards the end of this download faze the VB polling application fails
with "Cannot open database "DBName" requested by the login. The login
failed."
This connection fails 4 or 5 times and then normal polling resumes.
The scary thing is that sometimes when the polling connection fails
the merge replication does not complete and if i check
msMerge_Sessions the "runstatus" is stuck at 3 (InProgress).
1) Is the reason the ADO polling connection fails because of some sort
of lock between replication and reading the system tables?
2) Is replication getting stuck because of locks?
3) What can i do to get around this?
cheers,
Tim
The status event is the best way to monitor progress of your sync.
Merge replication does put schema and application locks on your tables,
including the sysmergerarticles table - this is probably what you are
seeing.
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
"Mar72Vin" <mar72vin@.gmail.com> wrote in message
news:1173826362.218126.53350@.l75g2000hse.googlegro ups.com...
> Hi All,
> I have previously posted in the MSDN forums with no responses, so any
> hints on this would be greatly appreciated.
> I am replicating an SQL2005 express machine to SQL2005 standard
> edition server using merge replication.
> I have a simple VB application using ADO polling msMerge_history at
> the subscriber every second so that i can show the end user the
> progress of the replication.
> When the subscription first subscribes and after the initial snapshot
> is applied replication downloads all changes from the server that have
> been changed since the snapshot was created.
> Towards the end of this download faze the VB polling application fails
> with "Cannot open database "DBName" requested by the login. The login
> failed."
> This connection fails 4 or 5 times and then normal polling resumes.
> The scary thing is that sometimes when the polling connection fails
> the merge replication does not complete and if i check
> msMerge_Sessions the "runstatus" is stuck at 3 (InProgress).
> 1) Is the reason the ADO polling connection fails because of some sort
> of lock between replication and reading the system tables?
> 2) Is replication getting stuck because of locks?
> 3) What can i do to get around this?
> cheers,
> Tim
>
|||Hi Hilary,
Thanks for the quick reply.
We are not using the replication component to start replication so we
can't use the "status event"
We run replmerg.exe independently so that replication can be started
via windows Task Scheduler. This way we do not need to have our
replication monitor open whilst replicating.
However when we do have our replication monitor open the replmerg.exe
disappears out of the taskmanager and leaves replication stuck at the
"in progress" status. This only happens after applying the initial
snapshot. (subsequent replications succeed)
The last message recorded to msMerge_History is usually "Web
Syncronization progress xx% Complete."
Why would the replmerge.exe just "give up" at this stage?
thanks for your time.
Cheers,
Tim
On Mar 14, 12:45 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:[vbcol=seagreen]
> The status event is the best way to monitor progress of your sync.
> Merge replication does put schema and application locks on your tables,
> including the sysmergerarticles table - this is probably what you are
> seeing.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Mar72Vin" <mar72...@.gmail.com> wrote in message
> news:1173826362.218126.53350@.l75g2000hse.googlegro ups.com...
>
>
>
>
|||Looks like i have been barking up the wrong tree. The connections from
the ado application are not causing this error.
I ran replmerg.exe and captured the results (see below), It looks like
replication is trying to use the SYSTEM login at some point to access
the database and it does not have access.
The SQL2005Express instance is running under the system account, I
can't see why it should have troubles connecting to this database.
Any Ideas?
cheers,
Tim
2007-03-14 04:56:34.347 Connecting to Subscriber 'BARNEYXP\MDSZINC'
2007-03-14 04:56:34.347 Connecting to OLE DB Subscriber at datasource:
'BARNEYXP\MDSZINC', location: '', catalog: 'MDS200703146',
providerstring: '' using provider 'SQLNCLI'
2007-03-14 04:56:36.811 Percent Complete: 0
2007-03-14 04:56:36.811 Category:AGENT
Source: BARNEYXP\MDSZINC
Number: 20052
Message: The process could not access database 'MDS200703146' on
server 'BARNEYXP\MDSZINC'.
2007-03-14 04:56:36.811 Percent Complete: 0
2007-03-14 04:56:36.811 Category:SQLSERVER
Source: BARNEYXP\MDSZINC
Number: 4060
Message: Cannot open database "MDS200703146" requested by the login.
The login failed.
2007-03-14 04:56:36.811 Percent Complete: 0
2007-03-14 04:56:36.811 Category:SQLSERVER
Source: BARNEYXP\MDSZINC
Number: 18456
Message: Login failed for user 'NT AUTHORITY\SYSTEM'.
|||It sounds like one of the accounts you are trying to connect to the
publisher/distributor/or subscriber is not defined. You will need to use an
account which is in the pal on the publisher and in the sysadmin or dbo_role
on the subscriber. It will need rights to read, and list files and folders
on the snapshot share.
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
"Mar72Vin" <mar72vin@.gmail.com> wrote in message
news:1173852824.327599.170440@.n59g2000hsh.googlegr oups.com...
> Looks like i have been barking up the wrong tree. The connections from
> the ado application are not causing this error.
> I ran replmerg.exe and captured the results (see below), It looks like
> replication is trying to use the SYSTEM login at some point to access
> the database and it does not have access.
> The SQL2005Express instance is running under the system account, I
> can't see why it should have troubles connecting to this database.
> Any Ideas?
> cheers,
> Tim
>
> 2007-03-14 04:56:34.347 Connecting to Subscriber 'BARNEYXP\MDSZINC'
> 2007-03-14 04:56:34.347 Connecting to OLE DB Subscriber at datasource:
> 'BARNEYXP\MDSZINC', location: '', catalog: 'MDS200703146',
> providerstring: '' using provider 'SQLNCLI'
> 2007-03-14 04:56:36.811 Percent Complete: 0
> 2007-03-14 04:56:36.811 Category:AGENT
> Source: BARNEYXP\MDSZINC
> Number: 20052
> Message: The process could not access database 'MDS200703146' on
> server 'BARNEYXP\MDSZINC'.
> 2007-03-14 04:56:36.811 Percent Complete: 0
> 2007-03-14 04:56:36.811 Category:SQLSERVER
> Source: BARNEYXP\MDSZINC
> Number: 4060
> Message: Cannot open database "MDS200703146" requested by the login.
> The login failed.
> 2007-03-14 04:56:36.811 Percent Complete: 0
> 2007-03-14 04:56:36.811 Category:SQLSERVER
> Source: BARNEYXP\MDSZINC
> Number: 18456
> Message: Login failed for user 'NT AUTHORITY\SYSTEM'.
>
sql
I have previously posted in the MSDN forums with no responses, so any
hints on this would be greatly appreciated.
I am replicating an SQL2005 express machine to SQL2005 standard
edition server using merge replication.
I have a simple VB application using ADO polling msMerge_history at
the subscriber every second so that i can show the end user the
progress of the replication.
When the subscription first subscribes and after the initial snapshot
is applied replication downloads all changes from the server that have
been changed since the snapshot was created.
Towards the end of this download faze the VB polling application fails
with "Cannot open database "DBName" requested by the login. The login
failed."
This connection fails 4 or 5 times and then normal polling resumes.
The scary thing is that sometimes when the polling connection fails
the merge replication does not complete and if i check
msMerge_Sessions the "runstatus" is stuck at 3 (InProgress).
1) Is the reason the ADO polling connection fails because of some sort
of lock between replication and reading the system tables?
2) Is replication getting stuck because of locks?
3) What can i do to get around this?
cheers,
Tim
The status event is the best way to monitor progress of your sync.
Merge replication does put schema and application locks on your tables,
including the sysmergerarticles table - this is probably what you are
seeing.
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
"Mar72Vin" <mar72vin@.gmail.com> wrote in message
news:1173826362.218126.53350@.l75g2000hse.googlegro ups.com...
> Hi All,
> I have previously posted in the MSDN forums with no responses, so any
> hints on this would be greatly appreciated.
> I am replicating an SQL2005 express machine to SQL2005 standard
> edition server using merge replication.
> I have a simple VB application using ADO polling msMerge_history at
> the subscriber every second so that i can show the end user the
> progress of the replication.
> When the subscription first subscribes and after the initial snapshot
> is applied replication downloads all changes from the server that have
> been changed since the snapshot was created.
> Towards the end of this download faze the VB polling application fails
> with "Cannot open database "DBName" requested by the login. The login
> failed."
> This connection fails 4 or 5 times and then normal polling resumes.
> The scary thing is that sometimes when the polling connection fails
> the merge replication does not complete and if i check
> msMerge_Sessions the "runstatus" is stuck at 3 (InProgress).
> 1) Is the reason the ADO polling connection fails because of some sort
> of lock between replication and reading the system tables?
> 2) Is replication getting stuck because of locks?
> 3) What can i do to get around this?
> cheers,
> Tim
>
|||Hi Hilary,
Thanks for the quick reply.
We are not using the replication component to start replication so we
can't use the "status event"
We run replmerg.exe independently so that replication can be started
via windows Task Scheduler. This way we do not need to have our
replication monitor open whilst replicating.
However when we do have our replication monitor open the replmerg.exe
disappears out of the taskmanager and leaves replication stuck at the
"in progress" status. This only happens after applying the initial
snapshot. (subsequent replications succeed)
The last message recorded to msMerge_History is usually "Web
Syncronization progress xx% Complete."
Why would the replmerge.exe just "give up" at this stage?
thanks for your time.
Cheers,
Tim
On Mar 14, 12:45 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:[vbcol=seagreen]
> The status event is the best way to monitor progress of your sync.
> Merge replication does put schema and application locks on your tables,
> including the sysmergerarticles table - this is probably what you are
> seeing.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Mar72Vin" <mar72...@.gmail.com> wrote in message
> news:1173826362.218126.53350@.l75g2000hse.googlegro ups.com...
>
>
>
>
|||Looks like i have been barking up the wrong tree. The connections from
the ado application are not causing this error.
I ran replmerg.exe and captured the results (see below), It looks like
replication is trying to use the SYSTEM login at some point to access
the database and it does not have access.
The SQL2005Express instance is running under the system account, I
can't see why it should have troubles connecting to this database.
Any Ideas?
cheers,
Tim
2007-03-14 04:56:34.347 Connecting to Subscriber 'BARNEYXP\MDSZINC'
2007-03-14 04:56:34.347 Connecting to OLE DB Subscriber at datasource:
'BARNEYXP\MDSZINC', location: '', catalog: 'MDS200703146',
providerstring: '' using provider 'SQLNCLI'
2007-03-14 04:56:36.811 Percent Complete: 0
2007-03-14 04:56:36.811 Category:AGENT
Source: BARNEYXP\MDSZINC
Number: 20052
Message: The process could not access database 'MDS200703146' on
server 'BARNEYXP\MDSZINC'.
2007-03-14 04:56:36.811 Percent Complete: 0
2007-03-14 04:56:36.811 Category:SQLSERVER
Source: BARNEYXP\MDSZINC
Number: 4060
Message: Cannot open database "MDS200703146" requested by the login.
The login failed.
2007-03-14 04:56:36.811 Percent Complete: 0
2007-03-14 04:56:36.811 Category:SQLSERVER
Source: BARNEYXP\MDSZINC
Number: 18456
Message: Login failed for user 'NT AUTHORITY\SYSTEM'.
|||It sounds like one of the accounts you are trying to connect to the
publisher/distributor/or subscriber is not defined. You will need to use an
account which is in the pal on the publisher and in the sysadmin or dbo_role
on the subscriber. It will need rights to read, and list files and folders
on the snapshot share.
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
"Mar72Vin" <mar72vin@.gmail.com> wrote in message
news:1173852824.327599.170440@.n59g2000hsh.googlegr oups.com...
> Looks like i have been barking up the wrong tree. The connections from
> the ado application are not causing this error.
> I ran replmerg.exe and captured the results (see below), It looks like
> replication is trying to use the SYSTEM login at some point to access
> the database and it does not have access.
> The SQL2005Express instance is running under the system account, I
> can't see why it should have troubles connecting to this database.
> Any Ideas?
> cheers,
> Tim
>
> 2007-03-14 04:56:34.347 Connecting to Subscriber 'BARNEYXP\MDSZINC'
> 2007-03-14 04:56:34.347 Connecting to OLE DB Subscriber at datasource:
> 'BARNEYXP\MDSZINC', location: '', catalog: 'MDS200703146',
> providerstring: '' using provider 'SQLNCLI'
> 2007-03-14 04:56:36.811 Percent Complete: 0
> 2007-03-14 04:56:36.811 Category:AGENT
> Source: BARNEYXP\MDSZINC
> Number: 20052
> Message: The process could not access database 'MDS200703146' on
> server 'BARNEYXP\MDSZINC'.
> 2007-03-14 04:56:36.811 Percent Complete: 0
> 2007-03-14 04:56:36.811 Category:SQLSERVER
> Source: BARNEYXP\MDSZINC
> Number: 4060
> Message: Cannot open database "MDS200703146" requested by the login.
> The login failed.
> 2007-03-14 04:56:36.811 Percent Complete: 0
> 2007-03-14 04:56:36.811 Category:SQLSERVER
> Source: BARNEYXP\MDSZINC
> Number: 18456
> Message: Login failed for user 'NT AUTHORITY\SYSTEM'.
>
sql
Sunday, March 11, 2012
Cannot Modify tables after Replication Switched off
If you run:
select replinfo from sysobjects
where name = 'yourtablename'
What comes back? If there is a 1, then update it to 0. If
it's not a 1 then I'll have a rethink!
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
"Adrian320" wrote:
> What if the number in sysobjects is 3 instead of 1, no problem?
> If I get the error message that ad hoc updates to sysobjects is not
> configured, how do I change that parameter.
> Thanks.
In Enterprise manager: Check "Allow modifications to be made directly to the
system catalogs" under Tools ->SQL Server Configuration Properties ->Server
Settings.
|||What if the number in sysobjects is 3 instead of 1, no problem?
If I get the error message that ad hoc updates to sysobjects is not
configured, how do I change that parameter.
Thanks.
"Paul Ibison" wrote:
> If you run:
> select replinfo from sysobjects
> where name = 'yourtablename'
> What comes back? If there is a 1, then update it to 0. If
> it's not a 1 then I'll have a rethink!
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
select replinfo from sysobjects
where name = 'yourtablename'
What comes back? If there is a 1, then update it to 0. If
it's not a 1 then I'll have a rethink!
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
"Adrian320" wrote:
> What if the number in sysobjects is 3 instead of 1, no problem?
> If I get the error message that ad hoc updates to sysobjects is not
> configured, how do I change that parameter.
> Thanks.
In Enterprise manager: Check "Allow modifications to be made directly to the
system catalogs" under Tools ->SQL Server Configuration Properties ->Server
Settings.
|||What if the number in sysobjects is 3 instead of 1, no problem?
If I get the error message that ad hoc updates to sysobjects is not
configured, how do I change that parameter.
Thanks.
"Paul Ibison" wrote:
> If you run:
> select replinfo from sysobjects
> where name = 'yourtablename'
> What comes back? If there is a 1, then update it to 0. If
> it's not a 1 then I'll have a rethink!
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
Cannot Make Inserts at Subscribers
I'm getting this error message when trying to insert a row on some
tables in my database.
The identity range managed by replication is full and must be updated
by a replication agent. The INSERT conflict occurred in database 'XXX',
table 'tblContact', column 'Number'. Sp_adjustpublisheridentityrange can
be called to get a new identity range.
These subscribers have been running for several months with out issue
and they are now all getting these errors as of yesterday. Running the
merge agent does not remedy the problem and that stored procedure seems
to only work for the publisher which is running just fine.
Running dbcc checkident ('tblContact', NORESEED) returns
Checking identity information: current identity value '94005', current
column value '94005'.
This will increase by one if I try an insert, but the insert fails.
I took everything down. Deleted the databases on the subscribers and
disabled publishing on the publisher, and started from scratch.
After setting up the replication again, some of the tables that were
giving me the problem are now working, but the majority of the tables
are still giving me this error.
I've run out of things to try. I would appreciate any further
suggestions.
Thank you,
David
Basically you have blown your identity range.
http://www.simple-talk.com/sql/database-administration/the-identity-crisis-in-replication/
Automatic identity range management has a check constraint which constrains
the possible identity values which can be used on your publisher and
subscriber. If you do an insert the check constraint will kick back the
insert when you blow the range and increment the current identity value.
the proc Sp_adjustpublisheridentityrange will adjust the identity range on
the Publisher, but not the subscriber. To fix this on your subscribers you
have to sample each one and figure out where they are. Then run the merge
agent one by one. One of the first things it will do when it detects the
range has been blown is to adjust it.
If this fails to work you may have to manually intervene and reset it based
on what all your subscribers are at and the values stored in select * from
distribution.dbo.MSmerge_identity_range_allocation s
You may also need to run your merge agents more frequently or bump up the
ranges to account for the max amount of data inserted on the subscriber at
any one time between syncs.
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
"David TMS" <IdontlikeSpam@.nospam.com> wrote in message
news:MPG.20636a6d184a3e8a989680@.msnews.microsoft.c om...
> I'm getting this error message when trying to insert a row on some
> tables in my database.
> The identity range managed by replication is full and must be updated
> by a replication agent. The INSERT conflict occurred in database 'XXX',
> table 'tblContact', column 'Number'. Sp_adjustpublisheridentityrange can
> be called to get a new identity range.
> These subscribers have been running for several months with out issue
> and they are now all getting these errors as of yesterday. Running the
> merge agent does not remedy the problem and that stored procedure seems
> to only work for the publisher which is running just fine.
> Running dbcc checkident ('tblContact', NORESEED) returns
> Checking identity information: current identity value '94005', current
> column value '94005'.
> This will increase by one if I try an insert, but the insert fails.
> I took everything down. Deleted the databases on the subscribers and
> disabled publishing on the publisher, and started from scratch.
> After setting up the replication again, some of the tables that were
> giving me the problem are now working, but the majority of the tables
> are still giving me this error.
> I've run out of things to try. I would appreciate any further
> suggestions.
> Thank you,
> David
|||Running the merge agent did not fix this problem for me. The identity
ranges on the subscribers were also more than large enough. They had
room for 10,000 inserts on each table and were not able to make any on
most of the tables, but other tables seemed to work just fine. Deleting
the publication and disabling replication, but keeping the original
database seemed to make the problem recur immediately after setting up
the replication. I'm still not sure of the cause of this problem, but I
seem to have a work around. I started a new database with a fresh
schema. I then imported the data from the old database. I set
everything back up using this new database name and it went fairly
smoothly.
Thanks,
Dave
In article <#2pv#P8ZHHA.4720@.TK2MSFTNGP06.phx.gbl>,
hilary.cotter@.gmail.com says...
> Basically you have blown your identity range.
> http://www.simple-talk.com/sql/database-administration/the-identity-crisis-in-replication/
> Automatic identity range management has a check constraint which constrains
> the possible identity values which can be used on your publisher and
> subscriber. If you do an insert the check constraint will kick back the
> insert when you blow the range and increment the current identity value.
> the proc Sp_adjustpublisheridentityrange will adjust the identity range on
> the Publisher, but not the subscriber. To fix this on your subscribers you
> have to sample each one and figure out where they are. Then run the merge
> agent one by one. One of the first things it will do when it detects the
> range has been blown is to adjust it.
> If this fails to work you may have to manually intervene and reset it based
> on what all your subscribers are at and the values stored in select * from
> distribution.dbo.MSmerge_identity_range_allocation s
> You may also need to run your merge agents more frequently or bump up the
> ranges to account for the max amount of data inserted on the subscriber at
> any one time between syncs.
>
tables in my database.
The identity range managed by replication is full and must be updated
by a replication agent. The INSERT conflict occurred in database 'XXX',
table 'tblContact', column 'Number'. Sp_adjustpublisheridentityrange can
be called to get a new identity range.
These subscribers have been running for several months with out issue
and they are now all getting these errors as of yesterday. Running the
merge agent does not remedy the problem and that stored procedure seems
to only work for the publisher which is running just fine.
Running dbcc checkident ('tblContact', NORESEED) returns
Checking identity information: current identity value '94005', current
column value '94005'.
This will increase by one if I try an insert, but the insert fails.
I took everything down. Deleted the databases on the subscribers and
disabled publishing on the publisher, and started from scratch.
After setting up the replication again, some of the tables that were
giving me the problem are now working, but the majority of the tables
are still giving me this error.
I've run out of things to try. I would appreciate any further
suggestions.
Thank you,
David
Basically you have blown your identity range.
http://www.simple-talk.com/sql/database-administration/the-identity-crisis-in-replication/
Automatic identity range management has a check constraint which constrains
the possible identity values which can be used on your publisher and
subscriber. If you do an insert the check constraint will kick back the
insert when you blow the range and increment the current identity value.
the proc Sp_adjustpublisheridentityrange will adjust the identity range on
the Publisher, but not the subscriber. To fix this on your subscribers you
have to sample each one and figure out where they are. Then run the merge
agent one by one. One of the first things it will do when it detects the
range has been blown is to adjust it.
If this fails to work you may have to manually intervene and reset it based
on what all your subscribers are at and the values stored in select * from
distribution.dbo.MSmerge_identity_range_allocation s
You may also need to run your merge agents more frequently or bump up the
ranges to account for the max amount of data inserted on the subscriber at
any one time between syncs.
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
"David TMS" <IdontlikeSpam@.nospam.com> wrote in message
news:MPG.20636a6d184a3e8a989680@.msnews.microsoft.c om...
> I'm getting this error message when trying to insert a row on some
> tables in my database.
> The identity range managed by replication is full and must be updated
> by a replication agent. The INSERT conflict occurred in database 'XXX',
> table 'tblContact', column 'Number'. Sp_adjustpublisheridentityrange can
> be called to get a new identity range.
> These subscribers have been running for several months with out issue
> and they are now all getting these errors as of yesterday. Running the
> merge agent does not remedy the problem and that stored procedure seems
> to only work for the publisher which is running just fine.
> Running dbcc checkident ('tblContact', NORESEED) returns
> Checking identity information: current identity value '94005', current
> column value '94005'.
> This will increase by one if I try an insert, but the insert fails.
> I took everything down. Deleted the databases on the subscribers and
> disabled publishing on the publisher, and started from scratch.
> After setting up the replication again, some of the tables that were
> giving me the problem are now working, but the majority of the tables
> are still giving me this error.
> I've run out of things to try. I would appreciate any further
> suggestions.
> Thank you,
> David
|||Running the merge agent did not fix this problem for me. The identity
ranges on the subscribers were also more than large enough. They had
room for 10,000 inserts on each table and were not able to make any on
most of the tables, but other tables seemed to work just fine. Deleting
the publication and disabling replication, but keeping the original
database seemed to make the problem recur immediately after setting up
the replication. I'm still not sure of the cause of this problem, but I
seem to have a work around. I started a new database with a fresh
schema. I then imported the data from the old database. I set
everything back up using this new database name and it went fairly
smoothly.
Thanks,
Dave
In article <#2pv#P8ZHHA.4720@.TK2MSFTNGP06.phx.gbl>,
hilary.cotter@.gmail.com says...
> Basically you have blown your identity range.
> http://www.simple-talk.com/sql/database-administration/the-identity-crisis-in-replication/
> Automatic identity range management has a check constraint which constrains
> the possible identity values which can be used on your publisher and
> subscriber. If you do an insert the check constraint will kick back the
> insert when you blow the range and increment the current identity value.
> the proc Sp_adjustpublisheridentityrange will adjust the identity range on
> the Publisher, but not the subscriber. To fix this on your subscribers you
> have to sample each one and figure out where they are. Then run the merge
> agent one by one. One of the first things it will do when it detects the
> range has been blown is to adjust it.
> If this fails to work you may have to manually intervene and reset it based
> on what all your subscribers are at and the values stored in select * from
> distribution.dbo.MSmerge_identity_range_allocation s
> You may also need to run your merge agents more frequently or bump up the
> ranges to account for the max amount of data inserted on the subscriber at
> any one time between syncs.
>
Cannot log conflict data
Hi,
I'm having problme when performing the Merge replication and the error as
belows:
1) The process could not log conflict information
follow by
2) Too many arguments were supplied for procedure sp_cft_xxxxxxx
Pls help, it is urgent!!!
Thanks.
Ringo
Message posted via http://www.sqlmonster.com
does this help?
http://support.microsoft.com/default...;en-us;Q241658
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>
|||Hi,
This doesn't really help. Maybe I should address more on my problem. The
problem happened when there;s conflict during replication and try to record
info into the conflict table through sp_cft_xxxxx stored procedure. The
error shows that the parameters passing to the sp_cft_xxxxx SP is more (one
extra parameter which I think is "0x00" as the last parameter).
The above replication is between the SQL CE (PDA) and MS SQL 2000 server
where I'm using the "Synchronize()" method.
BTW, thanks for your help
Message posted via http://www.sqlmonster.com
|||where are you calling this proc? Its on the publisher correct?
--
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
"ringo law via SQLMonster.com" <forum@.SQLMonster.com> wrote in message
news:daf883cd95a9432fba48b2a26852239f@.SQLMonster.c om...
> Hi,
> This doesn't really help. Maybe I should address more on my problem. The
> problem happened when there;s conflict during replication and try to
> record
> info into the conflict table through sp_cft_xxxxx stored procedure. The
> error shows that the parameters passing to the sp_cft_xxxxx SP is more
> (one
> extra parameter which I think is "0x00" as the last parameter).
> The above replication is between the SQL CE (PDA) and MS SQL 2000 server
> where I'm using the "Synchronize()" method.
> BTW, thanks for your help
> --
> Message posted via http://www.sqlmonster.com
|||Hi,
No, I didn't call the stored proc. It's a system stored proc to log
conflict info in publisher table (conflict_tablename) when there's conflict
occurred.
If I try this Merge Replication between SQL Server (2000 to 2000), it can
work and the conflict record is created. But, if between SQL CE and 2000,
then this problem happened.
Thanks.
Ringo
Message posted via http://www.sqlmonster.com
I'm having problme when performing the Merge replication and the error as
belows:
1) The process could not log conflict information
follow by
2) Too many arguments were supplied for procedure sp_cft_xxxxxxx
Pls help, it is urgent!!!
Thanks.
Ringo
Message posted via http://www.sqlmonster.com
does this help?
http://support.microsoft.com/default...;en-us;Q241658
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>
|||Hi,
This doesn't really help. Maybe I should address more on my problem. The
problem happened when there;s conflict during replication and try to record
info into the conflict table through sp_cft_xxxxx stored procedure. The
error shows that the parameters passing to the sp_cft_xxxxx SP is more (one
extra parameter which I think is "0x00" as the last parameter).
The above replication is between the SQL CE (PDA) and MS SQL 2000 server
where I'm using the "Synchronize()" method.
BTW, thanks for your help
Message posted via http://www.sqlmonster.com
|||where are you calling this proc? Its on the publisher correct?
--
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
"ringo law via SQLMonster.com" <forum@.SQLMonster.com> wrote in message
news:daf883cd95a9432fba48b2a26852239f@.SQLMonster.c om...
> Hi,
> This doesn't really help. Maybe I should address more on my problem. The
> problem happened when there;s conflict during replication and try to
> record
> info into the conflict table through sp_cft_xxxxx stored procedure. The
> error shows that the parameters passing to the sp_cft_xxxxx SP is more
> (one
> extra parameter which I think is "0x00" as the last parameter).
> The above replication is between the SQL CE (PDA) and MS SQL 2000 server
> where I'm using the "Synchronize()" method.
> BTW, thanks for your help
> --
> Message posted via http://www.sqlmonster.com
|||Hi,
No, I didn't call the stored proc. It's a system stored proc to log
conflict info in publisher table (conflict_tablename) when there's conflict
occurred.
If I try this Merge Replication between SQL Server (2000 to 2000), it can
work and the conflict record is created. But, if between SQL CE and 2000,
then this problem happened.
Thanks.
Ringo
Message posted via http://www.sqlmonster.com
Friday, February 24, 2012
Cannot insert the value NULL into column 'rowguid'....
Hello
i'm using merge replication in SQL server 2k but when i try to synchronise a
subscriber i get the following error
Cannot insert the value NULL into column 'rowguid'...
This seems to be caused by the fact that the columns are in a different
order
ie. columns we added after the publication
is there a way to cause the publication to name the fields in the insert
therefore eliminating this problem?
Thanks
How did you add the columns after the table was published?
Donna
"kris Palmby" wrote:
> Hello
> i'm using merge replication in SQL server 2k but when i try to synchronise a
> subscriber i get the following error
> Cannot insert the value NULL into column 'rowguid'...
> This seems to be caused by the fact that the columns are in a different
> order
> ie. columns we added after the publication
> is there a way to cause the publication to name the fields in the insert
> therefore eliminating this problem?
> Thanks
>
>
|||I'd like to know this also.
"Donna Lambert" <DonnaLambert@.discussions.microsoft.com> wrote in message
news:E4388B76-FBB2-4F00-8893-1F3F0ACEFB31@.microsoft.com...[vbcol=seagreen]
> How did you add the columns after the table was published?
> Donna
> "kris Palmby" wrote:
i'm using merge replication in SQL server 2k but when i try to synchronise a
subscriber i get the following error
Cannot insert the value NULL into column 'rowguid'...
This seems to be caused by the fact that the columns are in a different
order
ie. columns we added after the publication
is there a way to cause the publication to name the fields in the insert
therefore eliminating this problem?
Thanks
How did you add the columns after the table was published?
Donna
"kris Palmby" wrote:
> Hello
> i'm using merge replication in SQL server 2k but when i try to synchronise a
> subscriber i get the following error
> Cannot insert the value NULL into column 'rowguid'...
> This seems to be caused by the fact that the columns are in a different
> order
> ie. columns we added after the publication
> is there a way to cause the publication to name the fields in the insert
> therefore eliminating this problem?
> Thanks
>
>
|||I'd like to know this also.
"Donna Lambert" <DonnaLambert@.discussions.microsoft.com> wrote in message
news:E4388B76-FBB2-4F00-8893-1F3F0ACEFB31@.microsoft.com...[vbcol=seagreen]
> How did you add the columns after the table was published?
> Donna
> "kris Palmby" wrote:
cannot insert Null value into columns 'nicknames'
We have a merge replication on a database containing dynamic filters. At a
given moment one of the clients gets the following error during replication.
'The process could not make a generation at the Subscriber'
The error message is
'Cannot insert the value NULL into column 'nicknames', table
'vdavenne.dbo.MSMerge_genhistory'; column does not allow nulls.
Nol ,
does the problem resolve itself when you restart the merge agent? If not,
please can you post up the script of your article and publication and I'll
have a play around with it.
Thanks,
Paul Ibison
|||You need SP3a or Microsoft's hot fix. Went through this pain myself about 2 months ago.
Good luck.
C
Originally posted by Paul Ibison
Nol ,
does the problem resolve itself when you restart the merge agent? If not,
please can you post up the script of your article and publication and I'll
have a play around with it.
Thanks,
Paul Ibison
given moment one of the clients gets the following error during replication.
'The process could not make a generation at the Subscriber'
The error message is
'Cannot insert the value NULL into column 'nicknames', table
'vdavenne.dbo.MSMerge_genhistory'; column does not allow nulls.
Nol ,
does the problem resolve itself when you restart the merge agent? If not,
please can you post up the script of your article and publication and I'll
have a play around with it.
Thanks,
Paul Ibison
|||You need SP3a or Microsoft's hot fix. Went through this pain myself about 2 months ago.
Good luck.
C
Quote:
Nol ,
does the problem resolve itself when you restart the merge agent? If not,
please can you post up the script of your article and publication and I'll
have a play around with it.
Thanks,
Paul Ibison
Cannot insert explicit value for identity column
SQL Server 2000 SP4 (Enterprise edition) both publisher and Subscriber.
I have setup Identity column 'Not for Replication' in subscriber.
My error is
Cannot insert explicit value for identity column in table 'tablename' when
IDENTITY_INSERT is set to OFF.
I ran
SET IDENTITY_INSERT 'tablename' ON
I am still getting same error. Pl help
TIA
Sandeep
I am running transactional replication.
Thanks,
Sandeep
"Sandeep Shankar" <sandeep@.discussions.microsoft.com> wrote in message
news:%23yzPifMKIHA.1208@.TK2MSFTNGP03.phx.gbl...
> SQL Server 2000 SP4 (Enterprise edition) both publisher and Subscriber.
> I have setup Identity column 'Not for Replication' in subscriber.
> My error is
>
> Cannot insert explicit value for identity column in table 'tablename' when
> IDENTITY_INSERT is set to OFF.
>
> I ran
> SET IDENTITY_INSERT 'tablename' ON
>
> I am still getting same error. Pl help
> TIA
> Sandeep
>
I have setup Identity column 'Not for Replication' in subscriber.
My error is
Cannot insert explicit value for identity column in table 'tablename' when
IDENTITY_INSERT is set to OFF.
I ran
SET IDENTITY_INSERT 'tablename' ON
I am still getting same error. Pl help
TIA
Sandeep
I am running transactional replication.
Thanks,
Sandeep
"Sandeep Shankar" <sandeep@.discussions.microsoft.com> wrote in message
news:%23yzPifMKIHA.1208@.TK2MSFTNGP03.phx.gbl...
> SQL Server 2000 SP4 (Enterprise edition) both publisher and Subscriber.
> I have setup Identity column 'Not for Replication' in subscriber.
> My error is
>
> Cannot insert explicit value for identity column in table 'tablename' when
> IDENTITY_INSERT is set to OFF.
>
> I ran
> SET IDENTITY_INSERT 'tablename' ON
>
> I am still getting same error. Pl help
> TIA
> Sandeep
>
Cannot insert duplicate key row in object......
Hi,
I am facing following error in transaction replication.
Cannot insert duplicate key row in object 'TableName'
with unique index 'PKConstraintName
Can any one help on this?
Thanks,
Manoj
Is it the distribution agent that is failing with that error? Then it means
that the subscriber already has a row, but the distribution agent is trying
to insert it again.
Have you been making any changes to the subscribing tables? Could it be that
someone inserted a row to the subscribing table, before that row existed on
the publishing table?
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"Manoj Raheja" <manoj_raheja@.hotmail.com> wrote in message
news:2e1ad01c46af7$0a435df0$a501280a@.phx.gbl...
> Hi,
> I am facing following error in transaction replication.
> Cannot insert duplicate key row in object 'TableName'
> with unique index 'PKConstraintName
> Can any one help on this?
> Thanks,
> Manoj
>
|||Thanks Vyas,
The subscriber has more number of records than publisher.
Thanks,
Manoj
>--Original Message--
>Is it the distribution agent that is failing with that
error? Then it means
>that the subscriber already has a row, but the
distribution agent is trying
>to insert it again.
>Have you been making any changes to the subscribing
tables? Could it be that
>someone inserted a row to the subscribing table, before
that row existed on
>the publishing table?
>--
>Vyas, MVP (SQL Server)
>http://vyaskn.tripod.com/
>
>"Manoj Raheja" <manoj_raheja@.hotmail.com> wrote in
message
>news:2e1ad01c46af7$0a435df0$a501280a@.phx.gbl...
>
>.
>
I am facing following error in transaction replication.
Cannot insert duplicate key row in object 'TableName'
with unique index 'PKConstraintName
Can any one help on this?
Thanks,
Manoj
Is it the distribution agent that is failing with that error? Then it means
that the subscriber already has a row, but the distribution agent is trying
to insert it again.
Have you been making any changes to the subscribing tables? Could it be that
someone inserted a row to the subscribing table, before that row existed on
the publishing table?
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"Manoj Raheja" <manoj_raheja@.hotmail.com> wrote in message
news:2e1ad01c46af7$0a435df0$a501280a@.phx.gbl...
> Hi,
> I am facing following error in transaction replication.
> Cannot insert duplicate key row in object 'TableName'
> with unique index 'PKConstraintName
> Can any one help on this?
> Thanks,
> Manoj
>
|||Thanks Vyas,
The subscriber has more number of records than publisher.
Thanks,
Manoj
>--Original Message--
>Is it the distribution agent that is failing with that
error? Then it means
>that the subscriber already has a row, but the
distribution agent is trying
>to insert it again.
>Have you been making any changes to the subscribing
tables? Could it be that
>someone inserted a row to the subscribing table, before
that row existed on
>the publishing table?
>--
>Vyas, MVP (SQL Server)
>http://vyaskn.tripod.com/
>
>"Manoj Raheja" <manoj_raheja@.hotmail.com> wrote in
message
>news:2e1ad01c46af7$0a435df0$a501280a@.phx.gbl...
>
>.
>
Cannot insert duplicate key row in object 'MSmerge_tombstone'
Hi,
I have made a replication since 2004-08-21. it works well, but recently i
got a problem. When i want to delete some records in a table, an error
occur. the message is:
Cannot insert duplicate key row in object 'MSmerge_tombstone' with unique
index 'uc1MSmerge_tombstone'
The statement has been terminated.
whatever how i do, even clear up all the records in table MSmerge_tombstone.
but when i try to delete the records in the table. i still got the error
message. i have searched more web pages for try to got some explain and
solution. but my work is useless. my boss is pressing me to solve this
problem in this week. Friends. Please help and save my life.
Regards
Jackson Chan
My personal opinion is that your unique index 'uc1MSmerge_tombstone' has gone
a bit funny.
Couple of sugestions, delete your unique index
run a checkdb on your database
Re-establish your index.
Peter
"We are all worms. But I believe that I am a glow-worm."
Winston Churchill
"Jackson BF" wrote:
> Hi,
> I have made a replication since 2004-08-21. it works well, but recently i
> got a problem. When i want to delete some records in a table, an error
> occur. the message is:
> Cannot insert duplicate key row in object 'MSmerge_tombstone' with unique
> index 'uc1MSmerge_tombstone'
> The statement has been terminated.
> whatever how i do, even clear up all the records in table MSmerge_tombstone.
> but when i try to delete the records in the table. i still got the error
> message. i have searched more web pages for try to got some explain and
> solution. but my work is useless. my boss is pressing me to solve this
> problem in this week. Friends. Please help and save my life.
> Regards
> Jackson Chan
>
>
>
I have made a replication since 2004-08-21. it works well, but recently i
got a problem. When i want to delete some records in a table, an error
occur. the message is:
Cannot insert duplicate key row in object 'MSmerge_tombstone' with unique
index 'uc1MSmerge_tombstone'
The statement has been terminated.
whatever how i do, even clear up all the records in table MSmerge_tombstone.
but when i try to delete the records in the table. i still got the error
message. i have searched more web pages for try to got some explain and
solution. but my work is useless. my boss is pressing me to solve this
problem in this week. Friends. Please help and save my life.
Regards
Jackson Chan
My personal opinion is that your unique index 'uc1MSmerge_tombstone' has gone
a bit funny.
Couple of sugestions, delete your unique index
run a checkdb on your database
Re-establish your index.
Peter
"We are all worms. But I believe that I am a glow-worm."
Winston Churchill
"Jackson BF" wrote:
> Hi,
> I have made a replication since 2004-08-21. it works well, but recently i
> got a problem. When i want to delete some records in a table, an error
> occur. the message is:
> Cannot insert duplicate key row in object 'MSmerge_tombstone' with unique
> index 'uc1MSmerge_tombstone'
> The statement has been terminated.
> whatever how i do, even clear up all the records in table MSmerge_tombstone.
> but when i try to delete the records in the table. i still got the error
> message. i have searched more web pages for try to got some explain and
> solution. but my work is useless. my boss is pressing me to solve this
> problem in this week. Friends. Please help and save my life.
> Regards
> Jackson Chan
>
>
>
Cannot insert duplicate key row in object MSmerge_tombstone
MSMerge_tombstone is a System Table used for Replication
information. It would appear as though you arent getting
rid of Replication totally after the first time you run
it. Are you dropping the Publication after the first run?
>--Original Message--
>I am working with a VB.Net Windows app that creates a
>publication/subscription on the fly. Essentially, it
takes a database backup
>in a zip file, unzips it, restores the database to the
same server as the
>other database in the setup, creates a publication to the
first database,
>then a subscription from the first database to the new
one, and attempts to
>run it.
>The first time this runs, on a fresh setup of all
databases involved, the
>process works fine. On subsequent runs, however, when we
get to the data
>synchronization part, the following error message comes
up in the agent's
>session detail:
>The schema script \\ROSTERDEV\C$\Program Files\Microsoft
SQL
>Server\MSSQL\ReplData\unc\ROSTERDEV_Case_mgt_HQ_c ase_mgt_H
Q\20040924000502\O
>ffice_78.sch could not be propagated to the subscriber.
>(Source: Merge Replication Provider (Agent); Error
number: -2147201001)
>----
--
>--
>Cannot insert duplicate key row in object
MSmerge_tombstone with unique
>index uc1MSmerge_tombstone.
>(Source: ROSTERDEV (Data source); Error number: 2601)
>----
--
>--
>The schema script file might be different, but the
message itself is the
>same. We're currently testing, so the exact same zip file
is getting reused
>on both first and subsequent attempts. I wouldn't think
this would cause a
>data conflict, but it appears to be.
>Any assistance would be welcome. Thanks.
>--
>Kenneth S. McAndrew
>Software Developer, Information Concepts
>kmcandrew@.infoconcepts.com
>
>.
>
The pull subscription, publication, and database published from are all
being removed, in that order, by the vb.net code. I don't see any left-over
tendrils.
Kenneth S. McAndrew
Software Developer, Information Concepts
kmcandrew@.infoconcepts.com
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:239d01c4a241$308282d0$a401280a@.phx.gbl...[vbcol=seagreen]
> MSMerge_tombstone is a System Table used for Replication
> information. It would appear as though you arent getting
> rid of Replication totally after the first time you run
> it. Are you dropping the Publication after the first run?
>
> takes a database backup
> same server as the
> first database,
> one, and attempts to
> databases involved, the
> get to the data
> up in the agent's
> SQL
> Q\20040924000502\O
> number: -2147201001)
> --
> MSmerge_tombstone with unique
> --
> message itself is the
> is getting reused
> this would cause a
information. It would appear as though you arent getting
rid of Replication totally after the first time you run
it. Are you dropping the Publication after the first run?
>--Original Message--
>I am working with a VB.Net Windows app that creates a
>publication/subscription on the fly. Essentially, it
takes a database backup
>in a zip file, unzips it, restores the database to the
same server as the
>other database in the setup, creates a publication to the
first database,
>then a subscription from the first database to the new
one, and attempts to
>run it.
>The first time this runs, on a fresh setup of all
databases involved, the
>process works fine. On subsequent runs, however, when we
get to the data
>synchronization part, the following error message comes
up in the agent's
>session detail:
>The schema script \\ROSTERDEV\C$\Program Files\Microsoft
SQL
>Server\MSSQL\ReplData\unc\ROSTERDEV_Case_mgt_HQ_c ase_mgt_H
Q\20040924000502\O
>ffice_78.sch could not be propagated to the subscriber.
>(Source: Merge Replication Provider (Agent); Error
number: -2147201001)
>----
--
>--
>Cannot insert duplicate key row in object
MSmerge_tombstone with unique
>index uc1MSmerge_tombstone.
>(Source: ROSTERDEV (Data source); Error number: 2601)
>----
--
>--
>The schema script file might be different, but the
message itself is the
>same. We're currently testing, so the exact same zip file
is getting reused
>on both first and subsequent attempts. I wouldn't think
this would cause a
>data conflict, but it appears to be.
>Any assistance would be welcome. Thanks.
>--
>Kenneth S. McAndrew
>Software Developer, Information Concepts
>kmcandrew@.infoconcepts.com
>
>.
>
The pull subscription, publication, and database published from are all
being removed, in that order, by the vb.net code. I don't see any left-over
tendrils.
Kenneth S. McAndrew
Software Developer, Information Concepts
kmcandrew@.infoconcepts.com
"ChrisR" <anonymous@.discussions.microsoft.com> wrote in message
news:239d01c4a241$308282d0$a401280a@.phx.gbl...[vbcol=seagreen]
> MSMerge_tombstone is a System Table used for Replication
> information. It would appear as though you arent getting
> rid of Replication totally after the first time you run
> it. Are you dropping the Publication after the first run?
>
> takes a database backup
> same server as the
> first database,
> one, and attempts to
> databases involved, the
> get to the data
> up in the agent's
> SQL
> Q\20040924000502\O
> number: -2147201001)
> --
> MSmerge_tombstone with unique
> --
> message itself is the
> is getting reused
> this would cause a
Subscribe to:
Posts (Atom)