I have a branch office I would like to connect to our database, which is
fronted by an Access ADP project. I'm having problems with security (the old
runtime 17), but in other small tests it seems the system is very slow. I
guess I'm not really that surprised.
I am considering using replication to set up a second server. Our workflow
is fairly simple. There are many tables that are effectively read-only, and
could be replicated using any method. There is one table that will see
updates from the remote site, as well as a trigger that fires when that table
is updated (keeping an audit log).
Can anyone suggest the best method for this case? It would seem that Merge
replication would be fine, but the documentation suggests I will have
problems with ACID on merge, and little else. Transactional sounds fine,
there's only about 5 tables that see updates on any sort of daily basis, and
only the one orders table that really gets hit.
However that table uses a auto-incrementing pkey. Will that even work?
MauryFor uni-directional data flow transactional replication will work best.
Identity values will be assigned on the publisher/data source. If you are
replicating to a table which has the identity property on this column you
will need to use the not for replication switch. By default Transactional
replication will not put the identity property on columns on the
subscriber/data destination.
Merge is intended for clients which are frequently offline and when you need
bi-directional replication. With careful partitioning you will avoid the
collisions which will break the d part of ACID.
If you need bi-directional replication you can use bi=-directional
transactional replication.
--
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
"Maury Markowitz" <MauryMarkowitz@.discussions.microsoft.com> wrote in
message news:6016EF86-8F9A-4D0D-9C83-CF08AB06107A@.microsoft.com...
> I have a branch office I would like to connect to our database, which is
> fronted by an Access ADP project. I'm having problems with security (the
old
> runtime 17), but in other small tests it seems the system is very slow. I
> guess I'm not really that surprised.
> I am considering using replication to set up a second server. Our workflow
> is fairly simple. There are many tables that are effectively read-only,
and
> could be replicated using any method. There is one table that will see
> updates from the remote site, as well as a trigger that fires when that
table
> is updated (keeping an audit log).
> Can anyone suggest the best method for this case? It would seem that Merge
> replication would be fine, but the documentation suggests I will have
> problems with ACID on merge, and little else. Transactional sounds fine,
> there's only about 5 tables that see updates on any sort of daily basis,
and
> only the one orders table that really gets hit.
> However that table uses a auto-incrementing pkey. Will that even work?
> Maury|||"Hilary Cotter" wrote:
> For uni-directional data flow transactional replication will work best.
No good here, one of the tables WILL be bi-directional.
> Identity values will be assigned on the publisher/data source.
This is a bit confusing. In my case I am sharing one updating table. If I
turn this off, does this mean that a new row will always be assigned a
"local" identity, one that might be different on the remote machine?
Maurysql
Showing posts with label replication. Show all posts
Showing posts with label replication. Show all posts
Friday, March 30, 2012
Merge or Transaction Replication?
I have a branch office I would like to connect to our database, which is
fronted by an Access ADP project. I'm having problems with security (the old
runtime 17), but in other small tests it seems the system is very slow. I
guess I'm not really that surprised.
I am considering using replication to set up a second server. Our workflow
is fairly simple. There are many tables that are effectively read-only, and
could be replicated using any method. There is one table that will see
updates from the remote site, as well as a trigger that fires when that table
is updated (keeping an audit log).
Can anyone suggest the best method for this case? It would seem that Merge
replication would be fine, but the documentation suggests I will have
problems with ACID on merge, and little else. Transactional sounds fine,
there's only about 5 tables that see updates on any sort of daily basis, and
only the one orders table that really gets hit.
However that table uses a auto-incrementing pkey. Will that even work?
Maury
For uni-directional data flow transactional replication will work best.
Identity values will be assigned on the publisher/data source. If you are
replicating to a table which has the identity property on this column you
will need to use the not for replication switch. By default Transactional
replication will not put the identity property on columns on the
subscriber/data destination.
Merge is intended for clients which are frequently offline and when you need
bi-directional replication. With careful partitioning you will avoid the
collisions which will break the d part of ACID.
If you need bi-directional replication you can use bi=-directional
transactional replication.
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
"Maury Markowitz" <MauryMarkowitz@.discussions.microsoft.com> wrote in
message news:6016EF86-8F9A-4D0D-9C83-CF08AB06107A@.microsoft.com...
> I have a branch office I would like to connect to our database, which is
> fronted by an Access ADP project. I'm having problems with security (the
old
> runtime 17), but in other small tests it seems the system is very slow. I
> guess I'm not really that surprised.
> I am considering using replication to set up a second server. Our workflow
> is fairly simple. There are many tables that are effectively read-only,
and
> could be replicated using any method. There is one table that will see
> updates from the remote site, as well as a trigger that fires when that
table
> is updated (keeping an audit log).
> Can anyone suggest the best method for this case? It would seem that Merge
> replication would be fine, but the documentation suggests I will have
> problems with ACID on merge, and little else. Transactional sounds fine,
> there's only about 5 tables that see updates on any sort of daily basis,
and
> only the one orders table that really gets hit.
> However that table uses a auto-incrementing pkey. Will that even work?
> Maury
|||"Hilary Cotter" wrote:
> For uni-directional data flow transactional replication will work best.
No good here, one of the tables WILL be bi-directional.
> Identity values will be assigned on the publisher/data source.
This is a bit confusing. In my case I am sharing one updating table. If I
turn this off, does this mean that a new row will always be assigned a
"local" identity, one that might be different on the remote machine?
Maury
fronted by an Access ADP project. I'm having problems with security (the old
runtime 17), but in other small tests it seems the system is very slow. I
guess I'm not really that surprised.
I am considering using replication to set up a second server. Our workflow
is fairly simple. There are many tables that are effectively read-only, and
could be replicated using any method. There is one table that will see
updates from the remote site, as well as a trigger that fires when that table
is updated (keeping an audit log).
Can anyone suggest the best method for this case? It would seem that Merge
replication would be fine, but the documentation suggests I will have
problems with ACID on merge, and little else. Transactional sounds fine,
there's only about 5 tables that see updates on any sort of daily basis, and
only the one orders table that really gets hit.
However that table uses a auto-incrementing pkey. Will that even work?
Maury
For uni-directional data flow transactional replication will work best.
Identity values will be assigned on the publisher/data source. If you are
replicating to a table which has the identity property on this column you
will need to use the not for replication switch. By default Transactional
replication will not put the identity property on columns on the
subscriber/data destination.
Merge is intended for clients which are frequently offline and when you need
bi-directional replication. With careful partitioning you will avoid the
collisions which will break the d part of ACID.
If you need bi-directional replication you can use bi=-directional
transactional replication.
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
"Maury Markowitz" <MauryMarkowitz@.discussions.microsoft.com> wrote in
message news:6016EF86-8F9A-4D0D-9C83-CF08AB06107A@.microsoft.com...
> I have a branch office I would like to connect to our database, which is
> fronted by an Access ADP project. I'm having problems with security (the
old
> runtime 17), but in other small tests it seems the system is very slow. I
> guess I'm not really that surprised.
> I am considering using replication to set up a second server. Our workflow
> is fairly simple. There are many tables that are effectively read-only,
and
> could be replicated using any method. There is one table that will see
> updates from the remote site, as well as a trigger that fires when that
table
> is updated (keeping an audit log).
> Can anyone suggest the best method for this case? It would seem that Merge
> replication would be fine, but the documentation suggests I will have
> problems with ACID on merge, and little else. Transactional sounds fine,
> there's only about 5 tables that see updates on any sort of daily basis,
and
> only the one orders table that really gets hit.
> However that table uses a auto-incrementing pkey. Will that even work?
> Maury
|||"Hilary Cotter" wrote:
> For uni-directional data flow transactional replication will work best.
No good here, one of the tables WILL be bi-directional.
> Identity values will be assigned on the publisher/data source.
This is a bit confusing. In my case I am sharing one updating table. If I
turn this off, does this mean that a new row will always be assigned a
"local" identity, one that might be different on the remote machine?
Maury
Merge or Transaction Replication?
I have a branch office I would like to connect to our database, which is
fronted by an Access ADP project. I'm having problems with security (the old
runtime 17), but in other small tests it seems the system is very slow. I
guess I'm not really that surprised.
I am considering using replication to set up a second server. Our workflow
is fairly simple. There are many tables that are effectively read-only, and
could be replicated using any method. There is one table that will see
updates from the remote site, as well as a trigger that fires when that tabl
e
is updated (keeping an audit log).
Can anyone suggest the best method for this case? It would seem that Merge
replication would be fine, but the documentation suggests I will have
problems with ACID on merge, and little else. Transactional sounds fine,
there's only about 5 tables that see updates on any sort of daily basis, and
only the one orders table that really gets hit.
However that table uses a auto-incrementing pkey. Will that even work?
MauryFor uni-directional data flow transactional replication will work best.
Identity values will be assigned on the publisher/data source. If you are
replicating to a table which has the identity property on this column you
will need to use the not for replication switch. By default Transactional
replication will not put the identity property on columns on the
subscriber/data destination.
Merge is intended for clients which are frequently offline and when you need
bi-directional replication. With careful partitioning you will avoid the
collisions which will break the d part of ACID.
If you need bi-directional replication you can use bi=-directional
transactional replication.
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
"Maury Markowitz" <MauryMarkowitz@.discussions.microsoft.com> wrote in
message news:6016EF86-8F9A-4D0D-9C83-CF08AB06107A@.microsoft.com...
> I have a branch office I would like to connect to our database, which is
> fronted by an Access ADP project. I'm having problems with security (the
old
> runtime 17), but in other small tests it seems the system is very slow. I
> guess I'm not really that surprised.
> I am considering using replication to set up a second server. Our workflow
> is fairly simple. There are many tables that are effectively read-only,
and
> could be replicated using any method. There is one table that will see
> updates from the remote site, as well as a trigger that fires when that
table
> is updated (keeping an audit log).
> Can anyone suggest the best method for this case? It would seem that Merge
> replication would be fine, but the documentation suggests I will have
> problems with ACID on merge, and little else. Transactional sounds fine,
> there's only about 5 tables that see updates on any sort of daily basis,
and
> only the one orders table that really gets hit.
> However that table uses a auto-incrementing pkey. Will that even work?
> Maury|||"Hilary Cotter" wrote:
> For uni-directional data flow transactional replication will work best.
No good here, one of the tables WILL be bi-directional.
> Identity values will be assigned on the publisher/data source.
This is a bit confusing. In my case I am sharing one updating table. If I
turn this off, does this mean that a new row will always be assigned a
"local" identity, one that might be different on the remote machine?
Maury
fronted by an Access ADP project. I'm having problems with security (the old
runtime 17), but in other small tests it seems the system is very slow. I
guess I'm not really that surprised.
I am considering using replication to set up a second server. Our workflow
is fairly simple. There are many tables that are effectively read-only, and
could be replicated using any method. There is one table that will see
updates from the remote site, as well as a trigger that fires when that tabl
e
is updated (keeping an audit log).
Can anyone suggest the best method for this case? It would seem that Merge
replication would be fine, but the documentation suggests I will have
problems with ACID on merge, and little else. Transactional sounds fine,
there's only about 5 tables that see updates on any sort of daily basis, and
only the one orders table that really gets hit.
However that table uses a auto-incrementing pkey. Will that even work?
MauryFor uni-directional data flow transactional replication will work best.
Identity values will be assigned on the publisher/data source. If you are
replicating to a table which has the identity property on this column you
will need to use the not for replication switch. By default Transactional
replication will not put the identity property on columns on the
subscriber/data destination.
Merge is intended for clients which are frequently offline and when you need
bi-directional replication. With careful partitioning you will avoid the
collisions which will break the d part of ACID.
If you need bi-directional replication you can use bi=-directional
transactional replication.
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
"Maury Markowitz" <MauryMarkowitz@.discussions.microsoft.com> wrote in
message news:6016EF86-8F9A-4D0D-9C83-CF08AB06107A@.microsoft.com...
> I have a branch office I would like to connect to our database, which is
> fronted by an Access ADP project. I'm having problems with security (the
old
> runtime 17), but in other small tests it seems the system is very slow. I
> guess I'm not really that surprised.
> I am considering using replication to set up a second server. Our workflow
> is fairly simple. There are many tables that are effectively read-only,
and
> could be replicated using any method. There is one table that will see
> updates from the remote site, as well as a trigger that fires when that
table
> is updated (keeping an audit log).
> Can anyone suggest the best method for this case? It would seem that Merge
> replication would be fine, but the documentation suggests I will have
> problems with ACID on merge, and little else. Transactional sounds fine,
> there's only about 5 tables that see updates on any sort of daily basis,
and
> only the one orders table that really gets hit.
> However that table uses a auto-incrementing pkey. Will that even work?
> Maury|||"Hilary Cotter" wrote:
> For uni-directional data flow transactional replication will work best.
No good here, one of the tables WILL be bi-directional.
> Identity values will be assigned on the publisher/data source.
This is a bit confusing. In my case I am sharing one updating table. If I
turn this off, does this mean that a new row will always be assigned a
"local" identity, one that might be different on the remote machine?
Maury
Merge on MSDE: how can do it ?
Hello everybody,
i need to set a MSDE database as 'publisher' for merge replication.
My difficult is that I haven't understand how I cand do it.
I have not Enterprise Manager for set the merge, How I can Do it ?
Thank you so much,
You could create a merge publication on your normal server and get EM to
script it out. This would be in the form of a series of system stored
procedure calls. After changing the servername, you should have a script
that could be run on MSDE.
Alternatively, you could create it using SQLDMO. I don't have an example of
merge, but I do have 2 examples of transactional on
www.replicationanswers.com.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> ha scritto nel messaggio news:%23eBzl8WAFHA.2016@.TK2MSFTNGP15.phx.gbl...
Thank you for your answer,
but i need a tool that make it for me.
There are any open-source/free software that i can use ?
thank you!
ck1;
|||I had a browse of the 3rd party tools for managing MSDE,
but the 3 I looked at didn't list replication
administration. Scripting out a subscriuption is not
difficult, but I can appreciate the functionality you are
looking for and I'll also keep an eye on this thread to
see if anyone else has such a GUI tool.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||What language? I have a library (VB6 and .NET versions) to set up merge
replication programmatically that's been used in a couple of client projects
successfully..
GUI can be put on it relatively easily.
Paul
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:26e001c502c7$94d45ce0$a401280a@.phx.gbl...
> I had a browse of the 3rd party tools for managing MSDE,
> but the 3 I looked at didn't list replication
> administration. Scripting out a subscriuption is not
> difficult, but I can appreciate the functionality you are
> looking for and I'll also keep an eye on this thread to
> see if anyone else has such a GUI tool.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
sql
i need to set a MSDE database as 'publisher' for merge replication.
My difficult is that I haven't understand how I cand do it.
I have not Enterprise Manager for set the merge, How I can Do it ?
Thank you so much,
You could create a merge publication on your normal server and get EM to
script it out. This would be in the form of a series of system stored
procedure calls. After changing the servername, you should have a script
that could be run on MSDE.
Alternatively, you could create it using SQLDMO. I don't have an example of
merge, but I do have 2 examples of transactional on
www.replicationanswers.com.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> ha scritto nel messaggio news:%23eBzl8WAFHA.2016@.TK2MSFTNGP15.phx.gbl...
Thank you for your answer,
but i need a tool that make it for me.
There are any open-source/free software that i can use ?
thank you!
ck1;
|||I had a browse of the 3rd party tools for managing MSDE,
but the 3 I looked at didn't list replication
administration. Scripting out a subscriuption is not
difficult, but I can appreciate the functionality you are
looking for and I'll also keep an eye on this thread to
see if anyone else has such a GUI tool.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||What language? I have a library (VB6 and .NET versions) to set up merge
replication programmatically that's been used in a couple of client projects
successfully..
GUI can be put on it relatively easily.
Paul
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:26e001c502c7$94d45ce0$a401280a@.phx.gbl...
> I had a browse of the 3rd party tools for managing MSDE,
> but the 3 I looked at didn't list replication
> administration. Scripting out a subscriuption is not
> difficult, but I can appreciate the functionality you are
> looking for and I'll also keep an eye on this thread to
> see if anyone else has such a GUI tool.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
sql
Merge Metadata Cleanup
Hello Everyone,
I am running SQL2K with sp3, continuous merge replication, only one
subscriber.
My current setting for Subscription expiration is the default of 7, I
have just recently changed this from the default of 14 days, as our
Subscriber is basically always available.
I am still trying to figure out how to cleanup my merge metadata. From
what I have read and from what I understand ,
sp_mergemetadataretentioncleanup is automatically run, if the agent
running Merge has the Parameter for MetadataRententionCleanup set to 1
I am under the assumption that if I have has the Parameter for
MetadataRententionCleanup set to 1 it should automatically be cleaning
up my metadata. Even though I have it set to 1 it does not appear
like it is actually cleaning out MSmerge_contents or MSmerge_tombstone.
These tables just keep growing.
Now if I had this parameter set to 0 then I would need to use
sp_mergecleanupmetadata to clean up MSmerge_contents or
MSmerge_tombstone.
Would there ever be a reason for running both?
I did go to BOL but I read the following about using
sp_mergecleanupmetadata:
If you want to run sp_mergecleanupmetadata without the subscriptions
being marked for reinitialization:
Stop all updates to the publication and subscription databases.
Unfortunately, I cannot stop all updates as our servers need to be
available 24/7.
Does anyone run this without stopping replication first? And if you do
run it do you have MetadataRententionCleanup set to 0?
If anyone can help I truly would appreciate it.
Thanks,
Barbara
*** Sent via Developersdex http://www.codecomments.com ***
are you using anonymous subscribers? Merge replication does not clean
up the metadata as efficiently with anonymous subscrptions as opposed
to named subscriptions.
|||Thanks Hilary.
Unfortunately no, we do not have any anonymous subscriptions only one
named subscriptions.
Any other ideas?
Barbara
*** Sent via Developersdex http://www.codecomments.com ***
|||I believe I have my answer:
1) sp_mergecleanupmetadata
2) sp_mergemetadataretentioncleanup
The First should be used for topologies with SQL Server 2000 SP1 or less
(which is not my case)
The Second one is the one to control the process manually for SQL Server
> SP1 which is your case and when the MetadataretentionCleanup is set to
0 (not automatic)
There is also a catch though the second sp is executed automatically by
merge Agent at at startup! when MetadataretentionCleanup is set to 1
therefore when in continuous mode it will be called only once.
So I'll need to manually run sp_mergemetadataretentioncleanup or setup a
job that will do it for me on a scheduled basis.
Thanks for your help Hilary.
Barbara
*** Sent via Developersdex http://www.codecomments.com ***
I am running SQL2K with sp3, continuous merge replication, only one
subscriber.
My current setting for Subscription expiration is the default of 7, I
have just recently changed this from the default of 14 days, as our
Subscriber is basically always available.
I am still trying to figure out how to cleanup my merge metadata. From
what I have read and from what I understand ,
sp_mergemetadataretentioncleanup is automatically run, if the agent
running Merge has the Parameter for MetadataRententionCleanup set to 1
I am under the assumption that if I have has the Parameter for
MetadataRententionCleanup set to 1 it should automatically be cleaning
up my metadata. Even though I have it set to 1 it does not appear
like it is actually cleaning out MSmerge_contents or MSmerge_tombstone.
These tables just keep growing.
Now if I had this parameter set to 0 then I would need to use
sp_mergecleanupmetadata to clean up MSmerge_contents or
MSmerge_tombstone.
Would there ever be a reason for running both?
I did go to BOL but I read the following about using
sp_mergecleanupmetadata:
If you want to run sp_mergecleanupmetadata without the subscriptions
being marked for reinitialization:
Stop all updates to the publication and subscription databases.
Unfortunately, I cannot stop all updates as our servers need to be
available 24/7.
Does anyone run this without stopping replication first? And if you do
run it do you have MetadataRententionCleanup set to 0?
If anyone can help I truly would appreciate it.
Thanks,
Barbara
*** Sent via Developersdex http://www.codecomments.com ***
are you using anonymous subscribers? Merge replication does not clean
up the metadata as efficiently with anonymous subscrptions as opposed
to named subscriptions.
|||Thanks Hilary.
Unfortunately no, we do not have any anonymous subscriptions only one
named subscriptions.
Any other ideas?
Barbara
*** Sent via Developersdex http://www.codecomments.com ***
|||I believe I have my answer:
1) sp_mergecleanupmetadata
2) sp_mergemetadataretentioncleanup
The First should be used for topologies with SQL Server 2000 SP1 or less
(which is not my case)
The Second one is the one to control the process manually for SQL Server
> SP1 which is your case and when the MetadataretentionCleanup is set to
0 (not automatic)
There is also a catch though the second sp is executed automatically by
merge Agent at at startup! when MetadataretentionCleanup is set to 1
therefore when in continuous mode it will be called only once.
So I'll need to manually run sp_mergemetadataretentioncleanup or setup a
job that will do it for me on a scheduled basis.
Thanks for your help Hilary.
Barbara
*** Sent via Developersdex http://www.codecomments.com ***
merge job failing
Hello,
Have a problem where a merge replication job is failing. I think I know why
I just don't know how to correct (without reinitialising).
By mistake, one of our guys (tracing another problem) deleted the remote
server on the subscriber which we can call serverS (the remote server
deleted in this case was itself - i.e ServerS is the name of the remote
server and this is on ServerS - it was referencing itself)
Now when the publisher serverP starts to synchronise with this subscriber we
get the following error message :-
The subscription could not be found
Source ServerS error number 20021
The remote server on serverS is set up again and looks just like it did
before but I'm guessing that the system is smart enough to know that this is
not the original and will not see the newly recreated remote server?
Any ideas/advice greatly appreciated..
Thanks
David
...forgot to say : the main error message displayed is
'The subscription to publication 'XXXX' is invalid'
rgds
David
"David Wilce" <david.wilce@.btinternet.com> wrote in message
news:1eqdnWxc4p43bdTYnZ2dnUVZ8qSdnZ2d@.bt.com...
> Hello,
> Have a problem where a merge replication job is failing. I think I know
why
> I just don't know how to correct (without reinitialising).
> By mistake, one of our guys (tracing another problem) deleted the remote
> server on the subscriber which we can call serverS (the remote server
> deleted in this case was itself - i.e ServerS is the name of the remote
> server and this is on ServerS - it was referencing itself)
> Now when the publisher serverP starts to synchronise with this subscriber
we
> get the following error message :-
> The subscription could not be found
> Source ServerS error number 20021
> The remote server on serverS is set up again and looks just like it did
> before but I'm guessing that the system is smart enough to know that this
is
> not the original and will not see the newly recreated remote server?
> Any ideas/advice greatly appreciated..
> Thanks
> David
>
|||Hi Dave,
I know we talked about this offline but for anyone else who needs the
solution......:
Try:
Use Master
go
Select @.@.Servername
This should return your current server name but if it
returns NULL then try:
Use Master
go
Sp_DropServer 'OldName'
GO
Use Master
go
Sp_Addserver 'NewName', 'local'
GO
Stop and Start SQL Services
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Thanks again Paul
Invaluable support as ever!
Regards
Dave
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uItsjMp$GHA.4592@.TK2MSFTNGP03.phx.gbl...
> Hi Dave,
> I know we talked about this offline but for anyone else who needs the
> solution......:
> Try:
> Use Master
> go
> Select @.@.Servername
> This should return your current server name but if it
> returns NULL then try:
> Use Master
> go
> Sp_DropServer 'OldName'
> GO
> Use Master
> go
> Sp_Addserver 'NewName', 'local'
> GO
> Stop and Start SQL Services
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
Have a problem where a merge replication job is failing. I think I know why
I just don't know how to correct (without reinitialising).
By mistake, one of our guys (tracing another problem) deleted the remote
server on the subscriber which we can call serverS (the remote server
deleted in this case was itself - i.e ServerS is the name of the remote
server and this is on ServerS - it was referencing itself)
Now when the publisher serverP starts to synchronise with this subscriber we
get the following error message :-
The subscription could not be found
Source ServerS error number 20021
The remote server on serverS is set up again and looks just like it did
before but I'm guessing that the system is smart enough to know that this is
not the original and will not see the newly recreated remote server?
Any ideas/advice greatly appreciated..
Thanks
David
...forgot to say : the main error message displayed is
'The subscription to publication 'XXXX' is invalid'
rgds
David
"David Wilce" <david.wilce@.btinternet.com> wrote in message
news:1eqdnWxc4p43bdTYnZ2dnUVZ8qSdnZ2d@.bt.com...
> Hello,
> Have a problem where a merge replication job is failing. I think I know
why
> I just don't know how to correct (without reinitialising).
> By mistake, one of our guys (tracing another problem) deleted the remote
> server on the subscriber which we can call serverS (the remote server
> deleted in this case was itself - i.e ServerS is the name of the remote
> server and this is on ServerS - it was referencing itself)
> Now when the publisher serverP starts to synchronise with this subscriber
we
> get the following error message :-
> The subscription could not be found
> Source ServerS error number 20021
> The remote server on serverS is set up again and looks just like it did
> before but I'm guessing that the system is smart enough to know that this
is
> not the original and will not see the newly recreated remote server?
> Any ideas/advice greatly appreciated..
> Thanks
> David
>
|||Hi Dave,
I know we talked about this offline but for anyone else who needs the
solution......:
Try:
Use Master
go
Select @.@.Servername
This should return your current server name but if it
returns NULL then try:
Use Master
go
Sp_DropServer 'OldName'
GO
Use Master
go
Sp_Addserver 'NewName', 'local'
GO
Stop and Start SQL Services
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||Thanks again Paul
Invaluable support as ever!
Regards
Dave
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:uItsjMp$GHA.4592@.TK2MSFTNGP03.phx.gbl...
> Hi Dave,
> I know we talked about this offline but for anyone else who needs the
> solution......:
> Try:
> Use Master
> go
> Select @.@.Servername
> This should return your current server name but if it
> returns NULL then try:
> Use Master
> go
> Sp_DropServer 'OldName'
> GO
> Use Master
> go
> Sp_Addserver 'NewName', 'local'
> GO
> Stop and Start SQL Services
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com .
>
Wednesday, March 28, 2012
merge history ip address
Hi again,
Is there a way I can find out the ip address of the subscriber machine
in a replication? I can't seem to find it in any of the tables under
the distribution database.
Thanks,
Haroldsp_helpmergesubscription should give you the server name, but you'll
probably need to use an external script (or perhaps xp_cmdshell) to
look up the IP address. There might be a better way, though, so you
might want to post in microsoft.public.sqlserver.replication
Simon
Merge heavy on distr cpu
125Gb heavy OLTP publication db w/ Transactional Replication replicating 400
tables to 5 different servers. No problems on remote distributor, cpu hardly
used, sits practically idle most of the day staying under 10%. Ram is used
however not getting taxed.
We added merge replication for 1 table and the cpu's pegged to 90 to 100%
each time the merge agents pick up transactions at pub. Every 20 minutes a
job populated this table w/ 100 to 200 inserts at publisher, the 5 merge
agents kick in immediately (continuously running) and spike cpu bringing
server to a crawl.
Publisher, Distributor, & all Subscribers on LAN w/ 100Mbps connections.
SQL 2000 SP3 on all servers. Distributor is a 6CPU PIII 700Mhz each. New
Distributor hardware not an option. Have to limp along until new budgets kick
in...
Thoughts...?
TIA,
Chris
Chris,
are the 100/200 inserts involving BLOB datatypes? How long does the spike
last? Anyway, I'd change the merge agents from running continuously, in
order to stagger their impact on the publisher.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql
tables to 5 different servers. No problems on remote distributor, cpu hardly
used, sits practically idle most of the day staying under 10%. Ram is used
however not getting taxed.
We added merge replication for 1 table and the cpu's pegged to 90 to 100%
each time the merge agents pick up transactions at pub. Every 20 minutes a
job populated this table w/ 100 to 200 inserts at publisher, the 5 merge
agents kick in immediately (continuously running) and spike cpu bringing
server to a crawl.
Publisher, Distributor, & all Subscribers on LAN w/ 100Mbps connections.
SQL 2000 SP3 on all servers. Distributor is a 6CPU PIII 700Mhz each. New
Distributor hardware not an option. Have to limp along until new budgets kick
in...
Thoughts...?
TIA,
Chris
Chris,
are the 100/200 inserts involving BLOB datatypes? How long does the spike
last? Anyway, I'd change the merge agents from running continuously, in
order to stagger their impact on the publisher.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql
Merge filtering HOST_NAME help
Hello
Im trying to create a merge replication.
I've a 2xSubscribers and a distributor/publisher
My published table has fieldnames describing what server this row should be published. When I create my replication a use a filter like this: ... where target_server = host_name()
I want to publish rows to different subscribers, for instance i have a server with hostname 'BOBAFETT' and another with hostname 'R2D2' and a distributor/publisher with hostname 'SKYWALKER'. When I insert a row into the publisher I cannot get it replicate
d unless i use SKYWALKER as target_server, but I will use BOBAFETT or R2D2 as target_server, thereby getting the correct row to the intended subscriber!!
Another strange thing, when I insert a row into the subscriber it gets deleted and nothing is inserted into the publishers table!!
My own thoughts is that the host_name() only applies to the publisher and not the subscriber, therefore im only able to publish tows with the publisher name as fieldvalue - That's not quite what I would expect.
Ohh btw. If I hardcode BOBAFETT in the filter where clause it gets the correct rows!!
Can anybody help me?
Kind regards
Janus, Denmark
Janus,
as SKYWALKER is your publication server, this should amalgamate all the rows. The other servers BOBAFETT and R2D2 will be restricted to having rows with their own server name in the filtering column ie on R2D2 you can add rows with R2D2 but you can't add
a record having the value SKYWALKER.
BTW, there is another way of setting it up which is less restrictive - you can use -HOSTNAME 'value' as a parameter in the merge agent's job. This means that you aren't restricted to having a column with R2D2 or BOBAFETT in it, and instead you could have
some business indicator.
HTH,
Paul Ibison, London, UK
Im trying to create a merge replication.
I've a 2xSubscribers and a distributor/publisher
My published table has fieldnames describing what server this row should be published. When I create my replication a use a filter like this: ... where target_server = host_name()
I want to publish rows to different subscribers, for instance i have a server with hostname 'BOBAFETT' and another with hostname 'R2D2' and a distributor/publisher with hostname 'SKYWALKER'. When I insert a row into the publisher I cannot get it replicate
d unless i use SKYWALKER as target_server, but I will use BOBAFETT or R2D2 as target_server, thereby getting the correct row to the intended subscriber!!
Another strange thing, when I insert a row into the subscriber it gets deleted and nothing is inserted into the publishers table!!
My own thoughts is that the host_name() only applies to the publisher and not the subscriber, therefore im only able to publish tows with the publisher name as fieldvalue - That's not quite what I would expect.
Ohh btw. If I hardcode BOBAFETT in the filter where clause it gets the correct rows!!
Can anybody help me?
Kind regards
Janus, Denmark
Janus,
as SKYWALKER is your publication server, this should amalgamate all the rows. The other servers BOBAFETT and R2D2 will be restricted to having rows with their own server name in the filtering column ie on R2D2 you can add rows with R2D2 but you can't add
a record having the value SKYWALKER.
BTW, there is another way of setting it up which is less restrictive - you can use -HOSTNAME 'value' as a parameter in the merge agent's job. This means that you aren't restricted to having a column with R2D2 or BOBAFETT in it, and instead you could have
some business indicator.
HTH,
Paul Ibison, London, UK
Merge filter inconsistant - MS Replication Problem.zip (1/1)
begin 644 MS Replication Problem.zip
M4$L#!!0````(`$""LC#YB*C2-`,``$L2```J````35,@.4F5P;&EC871I;VX@.
M4')O8FQE;2]C<F5A=&5?=&5S=%]L;V,N<W%LO5=-;]LP#+T'R'_0K4D1]&O#
M,`S809'H5*LL9Y+<I"<A!89=!NRP_7^,<F+9<CYD9TU9H$`2/_&1(A_IV^NO
M_V77M^/1[37AF[^;U\V?'U^(!6.=+!CI;]LS4IY.FS^#::`6"*>6SJF!0&4\
M^OE[//)_Y8%OW\(S9L!N7G]A^*M"/SEA(4\%'=D;9P#CETV@.-WQ>W#2\)N,1
M>EP)MR@.%CVF42GPO07!05F0"--'%RC_%"DE488DJI20<,EI*_``KP2?3676<
M7?8YSIL_8U93Z"((GLY$3N7D_L/L;EI_V6"X>#;`.CCV2/7DXY1$%OFQ+X[%
MKBK,YRYF%^,6MP#EM%$Q\B0NY.:*7.WR0M?[0=8Q/K1";/GU&%/./>D&FL`L
M-7=S6#ANVWZP%JS(@.;2MP?CG,R&=QX8$]?`#B@._RXY\?ZL=H!MTK.Y+[!F-+
MZXK,R=S20##!S>"C73=][YB:A=I=,V7VV2G\WSXLE'(48O>8NU"D+%_&>4V1
MSZS8)W_8:\!(U(2\&':!VLAGUQ6,1'-+`]+1DKL5ZDX-3&*0&^BXBA/<EKKX
M-K106*&,U50H2Y9/KE'&I<;,Z1?R!"^$3'8!3\>CZ65&!69'6(Q5DB%V^5'1
M\-J."G^+'*R,[O_\4=%O\GB+Y3C0:&,3XP*/TPZO.VN75$JNUAC]4`RF#S<.
MXVAK[@.=N][.'`]PRH:3S6D_YMX!+8'P.<K"/4<4GJMUCZ"*W^YC[DQC#5.PL
MX2?3OH:`(M)JNTM>(F^X-C!EV2`U@.K5U>^.N)R8:7:G1(%C?T=#$4SB]Q'!*
M
64\'..(I^CE+'J-4T>JU[4[)?3/A0!/S[),+N\]M6\PI+L/R4&W\65KZ81
M01/*5P&P'/&-1P=@.2BG:&)6W,)_N8E`'XUO1FN;GPY48Q53YT(6,MKQ4=U'S
MM+?*]\%TM[P^F+B'D]U5Y<'+2SH/L6)R)2-0C\Z'-7L<XJ?*-9,FV\OU\9>F
M]U*E*OP*=.[FW-GF=@.V\M\N%1FZ+VGA$I<6>.ZX$V\OEO.TF"VZ<A@.PT*'Q9
MJ==(DA4:!#+PGEM+Y#\+PY^GK>0&J.)U@.&&3_"L_[]/8C^`U!+`P04````
M"`!`@.K(P48FJY#D#``!-$@.``*@.```$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO
M8W)E871E7W1E<W1?<F5P+G-Q;+U738_;(!"]1\I_X+;)*MJO5JNJ4@.\$<)8-
MQB[@.3?:$LE+52Z4>VO^O#DZ,P?G`3C<[D2(YX3%O!N;-^/;ZVW_9]>UX='N-
MZ.;OYFWSY\=79)@.V5K$2];?M'BE/I\WM013#AB&*#9YCS3R5\>CG[_'(?:J#
MO[Z';\B!V;S]@.@.2L"K6TW+`\%79D[YP#R(!H0[VA\^*FY349C\#CBMM%Q6E,
MHY+\>\4X9=+PC#.%5+%RJT@.AD"P,DI40B+(,5P(>V(K3R716; V?*/MLY<WO,
M&@.I=!(+="<^QF-Q_FMU-FQ];#.4OFI$.CCQA-?D\19%%?LRK);&K&O.EB]G%
MN,4MF+1*RQAY$N=S<X6N=GG!Z_T@.FQ@.?@.A`#OPZCJ[DCW4(3F %)1.V<+2TWH
M!^Z"X3E#H;48MS[CPCJL3U`//TS207[<^J%^M"*L>V1'<M]B3&5LD5F1&^P)
M)KAI6-IUT_>,L5[(W3%C8EZLA.]P,W^5HQ"[V]SY2TKR,LYKBGQF^#[YPUX]
M1H`FY,6P`U1:O-BN8"2*6V@.F+*ZH78'N-,`D!K@.Q%=_B!+=2%<]#+PHII#8*
M<VE0N;2M,I8*,J=>T9*](C39!3P=CZ9-LW@./B6Y;!62'&XA5H"%V^5;1\MJV
M"G>*E!D1G?_YK
?YW$6R[&G$6(3[0*V4Q:..PNO5$JNUA #]4`RD#V8.;7'0
M]SVW^]G#`6X9E\(ZK<?TV>,2&)>#G)FGZ,8G;KO#X$5N]C'W)S&:R-A9PD^F
M(`F"84`:97;)2^0-Q@.8B#1FD1FQM[%Z[ZXF)6E>J-7#2MS6T\116E1!.Q8*0
M$G[.4>1SE#)6O;;(8]6+BOURV@.<BX-HG&F:7U[Z&EQ^2W5.B\5U<^1H:$32A
M?#4`KB.\\R@./3"E%B)%Y@.'F\BT$=C"M%H]N_#]_$**;:ARI$-.6EJ@.OKY=XH
MWP?3G?+Z8.(:3E97G0<G+^D\Q(I)I8A`/2J?K<G3$#]UKHG0V5ZNC[\T?90J
MU>'7H',GY\XTMRO@.O5G.%W(H:N,1%@.9J[K@.2;`^7TM!-YMW`ZHPI)N%EI1DC
M458HQH&!\QP,D=L@._'I]]/6\A30<3[#T,GZ$9_/_1Q#]!U!+`P04````"``2
MB+(P!=H#;H8!``!C`P``+````$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO9D=E
M=$-U<G)E;G15<V5R240N<W%LI5)-3\,P##VO4O^#;TW'/L2-RPZE2T?02$?2
M2B`A55V;;4&C14DJX-^3M@.,);1I"^)9G/]O/>=/A[%\QG+K.=`B;A3!AHY2H
M3*J%(G/X0_0]?IMT/MH>KB,W(-ZE-AJ0%GM1&+"KJ?H%](>NU\\6T.`Z@.\';
M3B@.!LH09]'`F2^0=B?!\R*NR8PSBZUL<)BL6KS!+'I$L1^`1S8M\GZNHJ0H C
MZ\K6S^#2=YU2U:^P.:#'QW&=;0WMOAPG<)_&"9YG9(YI0B*"& 4!,^U1`.<EH
MNESR%K.,1=RR0H:#!$.4TC`A%C\^/K([,)RDC'(H=KE"5Q8(>$N^Q@.M"O[*@.
MF[4V2E9;Q%..6<9I<(>1/T+A3<`(G>,'Y#UY(_B1]2\N;<42TY\D'\9PEN;;
M)3#MU)\3'T4GU+=@.KWX\;JQ(4/5>0"5$J2$O"J$UF!K,3NKON]LY*J^,=80H
M&B/`_D2YKB<G?L,R@.S189>W[:[O.UD9H`])T#CT8JBMD>#4YV0M9QVCP#O;I
M>WT"4$L#!!0````(`!:'LC!AZP$74@.8``%P9```I````35,@.4 F5P;&EC871I
M;VX@.4')O8FQE;2]S=6)?;&]C86Q?=&5S="YS<6SM&-MRTT;TF<SD'_;-<1J;
M))0.9$C)34/3<>S4=DH[P&A6TI$CD':%=F7PW_><75T=QUSB\H0>;.?<[^<H
MCW>/'_3L/M[>>OQ31O5L3@.:[R&3*5.XI/XM2'4FAV-<_F[)C,U+0&Y9`-@..6
MYG'<<NK'N-'KF7"FD9@.Q?0OW&6/]-0\[@.UDDCMC$X)B6S`.6Y8)QS2:6Q8/L
M"$TTCPD5:K&\`B`@.%A[@.UVVD6!0R/@..A&?Y&(&)5Z@.9H$1=2+!*9*X/>WLH5
ML#=39S)U!Z/S=]M;KT;;6\@.,GR.E%=M1$(.OV2X+,YDPM5#2>X\`Q;:W'CWZ
M=`L9L"A@.Q\R"W2C8Z5Q-,DCCR.?DH-NJITZWBWSWBE_#V="7YEY)@.XH[QO:Q
M<]WI&AKX#'[IJPDZQ;R5_Y.V@.&$M8:_`*=1C,-<W9X/+R1_.>.*,_W;&P],K
MY^7+ERTZ-_#:0HJ\7*!G&DSNW\32Y_$[]EYZ;$UP$Q5X_<"3?8PRDBIFW14\
M`?+SBISIE6IZ9]S_D*<=BJ?SCW-^,W4:`M!]H]XEE2?XX192AO>(V9A9DX7P
M'VR4$=)L#4<$W]88-@.E":NRV#&Q+8!O@.AUC@.'V+6[_>WM\A&JI4,$CF'P&M4
M'SL)O-+%LCLZ5NXFQL-/&?6S.1GL%,?]RZPC8W^3<C87)VQLJN^:Q]NRA\<
MB)B;+RS#([9ZWAZ5+E0_OGEMUK-AU;XK=P9.B'4KXT%K86_]WE&5J:Y>I'8J
M5JNZ06#L<=,LDEFD%TBVW]\W#Y'@.V&QPYUHFJ,PG[@.!J9ZJ!V]JD,JPK)>":
M>QP#91;`=>7[:K_['1O%.B4C<PS@.1/X3)_UJIGK85UJK%'F44:8S+A3WC7';
M6XQ=..>#T['#3E#HY04[NQR>CO_=.?BMVT*.0>>9.)<!L,OAE %`39^"<3UL8
MC!IA`O!CCMOA1$$VA\R,>S'GF7_+LYTG^T:P`MW"'[.=4N!)[ 5"W)0Y7FR^3
MA(N@.(>YP_Z`6V*"@.;/2^%&)64UR<%>6+(7M7P(L4-N$7N,JQG+`&,O9FM5"D
MFC2*:DJ%<UC!J&DPL8]^:;EO`,-.DZHRB/JIB9B`GU.17E'(#W"8=):C1"(]
M<X#096D4]'J*OKBJ0W=P^*P5N0;7NH.&6'#L)+G2S)<BC&9T"9A3C(48E3@. 2
M'^@.L-LX9B+D2U,>8A@.A.D#T62`',6S!IEXEKF/M(T:Z>C_$7TMV@.((O-N+FG
METH_S,FD(4E=#4IWK#/F2BO/,U_F0N_L=N]>:5@..,,/Y`$NWVK"#@.@.<]$S"\
MEE]@.4D@.NF9/CJ=J\U'`2NH6819N/`EMFPES^`H<E@.8Q117,>TZV++P-K+\B=
MPJQV3KO6R4(0)F1X,Q@.@.\,QY=3DL<AI`&%%F;!'8;8)"FLZTV WW9M>H"-1X4
MND8WT^N;Z5[K-&W;AC@.0W(N!N`YHXFJ>:5=I2*TD@.N'1&84+-X8YQ"Y^"!W+
M&>(.[^`2'L4TBY81`K0"4RMW4"F^M17PXI@.V\`K4GO)#R9H @./D>%9'Z?5D*9
M7G=5=2!>?A*XC-#V2-0DH]=#9SP882K*I6=*R&3LQ!F/1V/VXG>VS_"[F0&"
M==E,8F/]E4?Z=:1OQS*.*:JV4;\Z;13KNZDSJ6@.FP4\"$HGOD+X/2KE^,?;)
M+U%!B^UB61KP6E;!$&+@.:NK#!K!-FH'&@.')-C8MO4DU@.)#1.&AZ7VI2+(Z:U
MR!$:QGQ6LAG)=6[HHJ$W]GYY#"R0(*DGH$EI-60:&V:O'.`$KD<YE4NQYFLM
MC3>='Y+4/$4;8&4[KNJN'V1566HV:JL,,YAJ1M1!?;"!SO#"'O^4O$@.O'4& &
M"=^%)WQ.JWB9_:C1B]/QZ?!\=#.<,J,N*TB6!!:RCDBC/>',?,V@.7&YXAPGX
MA)-6^[<_='O;/*T[REW[_ZW__S0/&J?4>A6-(UX5QX^;V/HZ:%FP"MM0LQ(?
M9O`Q!^$ORA/_UQ9P:;[4B`QB]&L.ZRA06X8_`6>:;]W<;U&@.8P&G(?5L!7A9
M,%47JK/=2_U=B"O@.N-E60"VUCA)P9>A:94M,;>3ADZ?/GS[?JS:R&U+<\`TH
MF=DTA3Q69BKR&(>(X*FZE1JIXJ`HE;=O5V?R[:0@.)F9\771#G ;8E$M`X75B7
M@.9+Q');TRC",)0]LF;8P]QX8RR]2W_A_K_\`4$L#!!0````(`&B)LC"\<,:V
M<P4``+XE```G````35,@.4F5P;&EC871I;VX@.4')O8FQE;2]415-47U)%4"!P
M=6(N<W%L[5E9;]M&$)[G`OT/>DL*U(:<.@.7Z4#2)';M&?00YF@.<W(&12DM7J
M8$G)COKCFWPSLSR6NSSBU($:"`0/[<Y][>SJP[\[M$,]>DYS&M`536F"KS%&
MEG1-0[P3/&,9#P&QQ'L!B!Y%\HMQ!I0"YEOZAE;RU:.9C"WQG<CX,5W(F^\ A
MO<<=`BH%W:"&?@.2Z"XP7_)[(&$LY$QX_XSZG!_0:LK_",Z"7^ 'J!D>\%6K%=
M^)E(-9:Q&!*KSBFTS3!O@.#/%3!EK"1P>>>#HD^E\Z4CRSH%56S^%)I%C9[]<
M99OXK#<06@.6N'Y.UJIMILV,$JBEP$F#$'KRS5KE[>([PK')P8 Z@.'N`30,WR]
ML'S#/'CL#3VC4SH!G5]!XR7>_/Q=GN>P[!F^?I%K-]>`(XQC<5Z1OF_F4UIC
M+(1<,\Q&EM_G1H\;\;W"<W1,`7D+C%C\?^V-%#\T_^H&/0!WEG8M<C&?>KQA
MGK]#:!#`C@.M`!!)EFH=SL4)!822\TA*-T-@.HD9D)_6-HA2+%R/AUV2A')+;D
MG)N(14=X3XT$37BI8,5BRP5F5?)`O,&2KH0*:S65L:2!5B@.1% (O?4UR!0[W)
M"B/,Q^(KMF`&^XCV*O/LI;%(65!S/5:6J6S#H#8J]VC?X/R%V:&192"R3')8
M]LJU\!N+EMTB*I6<<K-9?1Q#[B;+V)0T9Y;X/<@.]K-DR;*1R8Z(K,K!5J:Z$
MDOJ?_5W0TC5A%Z/'8KL#X"5B1[;A&^&2H#8<TD/ZKB1U)%',DG).A7D^!U*%
M&5_U2%KTYU7M?9X/H<4]L.IWN;HT8U7SI1JI:4ZMOOK[JZXOZN^V"CR1JCRD
MOR6N6(>UV',-:IFV>_1CGA\N;%&%U/L93CT&CTRIJ+UU-/HM-,KV#H7.R,3`
M(J\A37)H;'*LKC\1NDUB.Q*Y6](<#_+,)GGE%'V#)M'IW)**_)@.:79(US[
MN/HM/)MI_$"/Z2>YZRK[GWA?X>WV9I^RON\XL>H;V2>W8ZMFT9AXQ=-\K,LE
MM@.3'3RH9>;<\8CS?JO$,6I]`Z]=XGM,?TA_.!&8BODN$`\=K6M%FTS2YH+=X
MLZ].\7TL^MA>VVSYH]SBO`ZMC-6USJI'-EO^%!3<>.^ZZ\AZC)"F(E^7_8:-
M\SGZ5"EE\$^1'8>(),8XQ/,TQTAI(=4]-+7HEN9D=X;:,=3!7Z$2Z=K?A9N]
MWFFGE77<7?9*<]+>O^@.'>8\YDYC0'`_1\67^*7C8W9QVM8'P&%IQ%8)69.G.
M.ZDXQW0QRI+Z9.1YCA+N8`):.!KU$1O]FNN`CG!E:Z7M6UV94['`3<EC5>[:
M%0XEF\K[B%`Z@.VS?[6(JS:6)P"GY^N?"3FZ?IUY<BB_*]FJ/L(&I&;SV,Y6Y
MX:G=2-:M-_%6V2>867OLQ#Z;@.(;*M9+YZLI?].A%_V&OXW[KU^V&]"2'^UO=
M@.TU,[`;X'>?]1RS1%I9HN;LRCB6.\4#R*)&*FHI&;-\TUZ2IPG[Y^O,6U2!`
M77@.%F<[OM?;X.6WKSK;NM$77MNY\C77G`I"_`?Y$<,_NN?;4< =O6G\VM/ZSO
M+2!XY[&2W.^1[@.@.>"M0T]W,5JCAGUQG.MK%@.WIK3=N81883/6XO3+;9W9NT]
MW,4YV[;Z;:O?U?]VL]X[[,:=N?N5L<1<.;&=D4=Z8D]IH"^OYKIQM'_I6KJ
M]:6JYK9KZ[?*_GE9L3GUT/<OYUTJ8MLY6K6.E>.Q9\5CE_I:AK^/ZEI_RE7F
M[)[/'TF'6,56KD=R[OL<<`=X!DY'F7'@.TW_];]>6SN56WY,6--K[HTN/MN]H
M%^.ZWSZ6T_=#C"G.I8>O']Z5ABO_Q/PG%,C_M\6_1E]O-/G/+;I$DHVYZ7%D
M2[L),?014$L#!!0````(`""2LC!_O5PM)`0``/H*```M````35,@.4F5P;&EC
M871I;VX@.4')O8FQE;2]415-47U)%4%]A=61I=%]D=&PN='ATI5;;;MPX#'V>
M!?8?BKS3("7JPGF31*F;12[%Q$7[Y@.\I\N]+9S*-9YIM@.M3P@.R79$@.\/SZ&O
MRE==M,\WR^>OUWJUN_IV?7KZN?(TZG?S86GW=V/1>1U^OYZWPX=Y*0_]82FW
M-AK7=S?+7+XO1?\]SJQ[W?;YGZ6==BZ?;^>7T4.[V[XP#K;?32^V,!_FXQ'S
MEZ7=S>UT_+Q\.>A2^^?SB6[[/$T\7+?C7O/]<OABGWWMQX4;V_KV7C>#?GC:
MY.^_?I2,5;1VT,056&N`TEV"&&AP#P%#P<?=C]3KZ*4VJ!+7UPK;:R-"[:FK
M.#=2<(\[9.]]VCE$!@.Q`^1.FO<M[+Y.+>+QV=EU=/=_VI@.-,@./X3XO[IWNU(
M)`/:32^3-B=`"'XS9]^_')4^D4W::32Y=#K*\#$F7T-OT(>+P,6BS]0&)$%R
MSF=R/AB^Z-1Q"+88*@.%C(Y!B88@.BY6*Y:*R&3R2(VYU!V!UC0WHU7OQ]O''/
M>1+V+_%:9FMG">`E=&#?&;*G`=E)$C%D&I+%6V2$-LA";5V`F3.4%LBP%<V2
M(U.1E0\70UX/M4C<63`7+-`:%.9+`/9-/)N+ET"/>_NWB(E[CU..&Z`2HD9M
M"3(V!%ZKKQ;+?18A%2E:/!G03HT\H\`8I1DQM4+A,"`T';T%IIK:X\X[8<>O
ME]/[RBU]I-SB'O.$N$%5UT+QOL!`+L"Y&'-M1=78QY6<'N***C,%8<O<L$IC
MR0.J&Q5&356-NV2J...P1$W/\`U07!?A.5&$?W$2(&ZZLBHA]@.S3$BG(85X6R
M2:0VE:2-U&5#Y=4"=V82P5G9,JVH5!.DZ"G&6$OKY:>(-B9!M/=ASW'*^"S=
M2WQ^+5_:E.=O1?<F:R%,YFPO^`H7'!4+Y,S!1!?,YU!-4AI"0NE$K1L^<=V<
M,J&I+*B)KCC39F5P%$I(I9-/<C1!)W_`VL=J,>W)37Z+JI>`-:RJJ<YJ,;`S
MNW8,U=PBL:98>!BJP,/(-%TAJ3DDQVR23`H%K9*ID/?:GUFC#Z/Z.%>(4]H:
MNOAB&G$"KI@.KL!48E!H5FK9LP3,:6D.E/49A,GNQ!...]TZ!Q;&G@.(<.ZF?*(
M6ZXVASK<LYM<.,GZ/?@.^REK<$T]\U@.#8@."5ON]D3L,D&A!N#VAA)J/LG7W39
MG$:JAVR=&>R;##5FBZWXH1J%[#('<1Q].$9MP;C_;P!^)6B[?D+J\0R4`8V_
M`K5N_290AU.4#5#/(R1-':15/?YYU#X4>JS&4"+34WH"&EA\%/!])3(5Z]'2
M&I2<15E=J<%$YSQ)P,O.O'M=*!C/3=O7D:KIW'*)EDLU(Y9H,A^B/J41K1/K
M&DD?K?2N@./9C9"Z(%D0<"*3-GFFX6OQSSSW)GX`V_?/70O+@.TEG*:4VY"Y<I
M/Z^M4S]W&T-\->5,9X[P'U!+`P04````"`"ZD;(PDY9":N$%``!J%```*P``
M`$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215!?=VE?87-G;BYT>'2]
MF,M2&\D2AM=,Q'D'A?;547FIJDSMZHI]S(@.)$'&&L^%!)OSND]5"-C;@.@.3&X
M0XNN5BN[Z^///S/9_N_C7;X^W]^=WWQLV[.M+;^>K5^LB_7L<'EW<]VOGKBR
M__UTI?3SN\.UK=;K5Y<7_:[.VP_Y^M/=X?;!XOJ0'ZS:3;]KAU.4OF_'*./J
M^G#7]A?WRPM;]3_KAP>/J!?7XQAG?OG[93N&61?]ZORX6B.L2[OS/[_]E4ME
MS``NDF?'TMEI@.>H\)8FC!PI9/Y_]U7J,RI"<U%8=YP(N^Y$=\]"1>FD\XN<S
MQDC`]N:E-D#:V//^>_EAOVF7?,OCNT9>H\.O/-I`WX7>,=I\9#\>IQMKYJD
MXXW;V]M;>^!Z>GY0/5Z=Q]9CD#42.Q\<K)%\W`$O/OC[2&=@.*+2)#U35C9R\
MXU2RRQBZ\S5@.PLRY2S44*(&5HCKJ$T7*Q8G6ZK*(-FZ82S!BF((0G&W_O/U_
MCH%7%'G?PH%.4#G=0.\([4]+/@.5Q>TAAN.-VWL2WZ,X$F`'<>.-P/P\>6T+
MGA\#2SL?%MO20V`8!D)-XFRG)H4XU!6N!FP`55$6U&[`3!ZCFR1<T5@.<M\PN
M]Q%=Z:DW11PIX.<SB$3\QL`F+8=A;H!EQ[A(/&W@.!<".R(T"^0W$7;`(<=%X
MTLQSG-`O";X1EJ#7R`-="J8N#@.F=^CCLS0:I4")/9)PZ5""V-QXCF[!\*2YS
M&"[4-GH-#"75R2E8FKUGCF%8Y&URS*<E4'J(`EO61*.[(&QV$U-U`HP.FT21
M2AA*,Q34<A(TR00T0V*0X4IKR27SEQACR;7GB8(YQK>6S$0!& R^[H#N,"_,O
MRS'36%A.TKD'1JF/C(U<+Z8'KF#),\HPXTU9,41,K4Q3ZJ/FWIL]J`?'PYL?
MQ>$=M&KG,+!DDY@.JQ,1O"PQ,.#/'#!C8)RPJK\BQ8P"9*38#6)X:@.2_9<^1#
MCF!Z'NB.:$GQR]_C&8CL'^3Y"G%0+"6GZ'*=-:M6RRST)L)"7<RP:PS!(&8=
MH0ZKA69BEJ?,8C\(8`K-350BPZR%2!&GLW^X.;]6RPW;4<U_'/+'_>93WI_G
MJ\O+'T'[_KAW=A\=KAM`F`R(OD!\:0*F)U"07QB_2<!HVU!,M O<\;*-*YMG-
MH*2J-8<4,PPQ%(%'!C'%>6C14$0S>9^:%7UN9O9`U/K[>[;N`)=$)SF\3$\_
ME8#>+R2GYZW`?*Z&@.*Q<)>[FRLT:I`'!J>3>H.4A*;_8L9`IH ;RY=M+,$"L]
MO+8U3*\V[Z>T\]B+@.'P1,?..04T[(9H7B17R;-6=K"<4G_VL8\(0E,U&1YT2
MFRAP%#=*LCX1C),OOT([8=:QUVG'6,+J-A;`*GE:%$\!?OSMTWH*NP"+_[9I
MZI!&Q6).G:>-%SN3@.NR*[SQ&$!W*!E&Q-VN0O)E/:`&:W+*NP0@.J5I[D!)
MWQUB\#N2Q=,OJX!I![`H?P/,=&:N3=8H^(Y&`H>3'"T?:ZQ6\UH;XM>V?%36
M0D[ZY(I97(EBF\DT6HL*=A@.P4M4W;QG,O$%GCTBX\["P?T4%/'O6BZR1_%H&
M5A0%1FQU-@.-D?2&+U28;W<!5TJXP&J?9(;XP`3&8,Z%-A*U^DB3SO=KE/E^T
M3;NIGWZTZR>/DQ>I`]EX<^XXFX&4WJ"./95&B@.!AQ&Q3&)DM2\LV7O3JJA6N
MG-"&V9)>T5._:QJ964!:\%6J."+`-4+8(<W9`^F?6I_'#3=Q&P02')&8%EC8
M"6-S-0RM8O.ZU?D7S_?OS4EFO4?_"KNY1P`.=8K.9C2KX`K_Q.GQ\)](,U9S
M#HU6W%E!G"9#45,"2=;^<9JS;,2&'(*-_,$0L;763K/:O<V#Y`#F06URBJK^
MK3G98#(W<!S^=:'T2DZX_OL`-T`[`K.J!^7]V59:OF^'&&)5"M$:F^+-9J59
M.V2_&MD2K&GF&.*+6VE&AK?6DY]N[,/:#M&<!=(KYY$UP)Q'S,/,>>)R`G#J
M`<2AS#_#%!LLITGC>8B/FO"_`5!+`P04````"`#FA;(P!^F*K+<#``!H"P``
M+0```$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215!?=V]R:U]I=&5M
M+G1X=*V6VU(C.0R&KWNK]AVHW*O*LF5;FCOY1+'+!"H)S'+5#T+Q[BL3YL#`
M+%F&KE1:MI5.?_U+OWOSY6(]O[EHFV5SN/X:V=SCN5W<[GM=O\X=[M8ZP_.^
M77?[[7%PT'^."3/8WY29]3B^WK6U]/.U'6PP@.W%QN<[)KY>9<=^V8\(,?D[8
M[VI_B@.XWA_5JK)>?#WK,WUOPN*3U<+MN[?LXM-NLGZ^/.>-P<9R\W!_6SU=/
M_[3;7]ZNWZDO]_URU9NV?MG]_7W.\OONZ=ZO=U=_S>O\^<>]YU%)2@.#N90!Y
M92B)/3@.-H[4D:,?#<L_!E5`5(:;4@.0HWD$$)D$A<X=Y8_<."GE)8-G=W/DR.
M+84S.^;#HINS8RAY0;>@."(-+X/#,N4^/GR6EQ3OGYW1PSZ8W9T_'9F;0S/`_
M9,PGMSOT9LMNF1\[-H]L?53MO8&C'H&&JZ!I.,!6+<;ABP9C(Q>R0ZK`*0F0
M=`_:.=D/.%!B06[RL+!WF/Z;+<MWMOP*&[[&5J^VMWUW^,8FI[&)[ZWT[(`Q
M-B!2#QP*@.<>H,6O'D.VF[WV5+,P5[.2!4#N4$"OTD)%B+*V7]+!(8N+?8S/=
MZ$VV$W5KW80@.S,"U52`M".J&&N60D7MI--)D$R>Q^F!LQ1;#8-"&`3)*'$E2
MJ85^9/.GU.0O=&,(^"%L'2L&,I7'4&-SI8!2'!!K&[U&PI+K.]C>K=M'LH6F
MF7VI$'TG*S8>4%K+D%/`E%+1VM78S%2\$U\AT;0<)@.'QI0%*L[9+/?7.#XL3
MB?+(YMYD$Y@.<K]7D2[9W>HG*B'4@.`M5N)D%D@.M2(UG[:6#A9:\G)7N*%Z0TO
M^5:3Z07;$S+ZYVSNW5Z2?//3#("CM1J9-8*H%8PTAZP1;8=HQE91710T+TED
MNIFS0*E-0%4H.VW9U?ZP1/'B3ZS)#]1-]^?;X_)SMDA#D:W+'#:3P30`=KF9
MH5`+J!A"LYN^+Z).G;F-9K5^&X9EK17`O)1B&GU(Y,F&@.K_-AO^7[9?[&T>2
M8'46^O3)K*:@.5&-@.ED;-:XFS)K&XCF7V&_L^MW@.%];8A9F)[,-RJ$4XO24BO
ML_$SMJ-IO&!;?L*(8*PG262./KJ:;13S-:"F9#TS$MCVUIMX/W+TTQ+[...,(
M##6S56GWPVRC=;#=HFCD7$TKLXV<K'4,`^5-B7C6V8D2O=,2.Q-&(0=N6%>1
M3$OTH\`HV;8Q-+]TQ=@.B#V>:31A[QS)=;)OV84"+&)(.MA:T\D.RUZW7)9*7
M;.A>9XL?5'[_`E!+`0(4"Q0````(`$""LC#YB*C2-`,``$L2```J````````
M``$`(`````````!-4R!297!L:6-A=&EO;B!0<F]B;&5M+V-R96%T95]T97-T
M7VQO8RYS<6Q02P$"%`L4````"`!`@.K(P48FJY#D#``!-$@.``*@.`````````!
M`"````!\`P``35,@.4F5P;&EC871I;VX@.4')O8FQE;2]C<F5A=&5?=&5S=%]R
M97`N<W%L4$L!`A0+%`````@.`$HBR,`7:`VZ&`0``8P,``"P`` ````````0`@.
M````_08``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO9D=E=$-U<G)E;G15<V5R
M240N<W%L4$L!`A0+%`````@.`%H>R,&'K`1=2!@.``7!D``"D`` ````````0`@.
M````S0@.``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO<W5B7VQO8V%L7W1E<W0N
M<W%L4$L!`A0+%`````@.`FR,+QPQK9S!0``OB4``"<`````` ````0`@.````
M9@.\``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215`@.<'5B+G-Q;%!+
M`0(4"Q0````(`""2LC!_O5PM)`0``/H*```M``````````$`(````!X5``!-
M4R!297!L:6-A=&EO;B!0<F]B;&5M+U1%4U1?4D507V%U9&ET7V1T;"YT>'10
M2P$"%`L4````"`"ZD;(PDY9":N$%``!J%```*P`````````!` "````"-&0``
M35,@.4F5P;&EC871I;VX@.4')O8FQE;2]415-47U)%4%]W:5]A<V=N+G1X=%!+
M`0(4"Q0````(`.:%LC`'Z8JLMP,``&@.+```M``````````$`( ````+<?``!-
M4R!297!L:6-A=&EO;B!0<F]B;&5M+U1%4U1?4D507W=O<FM?:71E;2YT>'10
52P4&``````@.`"`#%`@.``N2,`````
`
end
Hi Kees,
I am Michael's backup since he is OOF today. We have got your file and will
working on that. Thanks for your understanding.
Best regards
Baisong Wei
Microsoft Online Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.
|||Hello,
Have you been able to reproduce the problem I'm seeing? Do you need
any further information from me?
Thank you.
Kees
On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
(Baisong Wei[MSFT]) wrote:
>Hi Kees,
>I am Michael's backup since he is OOF today. We have got your file and will
>working on that. Thanks for your understanding.
>
>Best regards
>Baisong Wei
>Microsoft Online Support
>----
>Get Secure! - www.microsoft.com/security
>This posting is provided "as is" with no warranties and confers no rights.
>Please reply to newsgroups only. Thanks.
|||Hello Kees,
Actually, one of the Microsoft Engineers has replied to your post. This
reply can be found at
http://groups.google.com/groups?q=la...t&hl=en&lr= &
ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
Please follow the suggested action plan and post if you have any further
questions.
Thanks for using MSDN Newsgroups.
Vikrant Dalwale
Microsoft SQL Server Support Professional
This posting is provided "AS IS" with no warranties, and confers no rights.
Get secure !! For info, please visit http://www.microsoft.com/security.
Please reply to Newsgroups only.
| From: kjvt <kjvt@.newsgroups.nospam>
| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
| Date: Tue, 01 Jun 2004 10:06:18 -0500
| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
<u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
<djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
<tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
<BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
<ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
<ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
| X-Newsreader: Forte Free Agent 2.0/32.652
| MIME-Version: 1.0
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
| Newsgroups: microsoft.public.sqlserver.replication
| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
| Lines: 1
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!tk2msftngp13
.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
| X-Tomcat-NG: microsoft.public.sqlserver.replication
|
| Hello,
|
| Have you been able to reproduce the problem I'm seeing? Do you need
| any further information from me?
|
| Thank you.
|
| Kees
|
| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
| (Baisong Wei[MSFT]) wrote:
|
| >Hi Kees,
| >
| >I am Michael's backup since he is OOF today. We have got your file and
will
| >working on that. Thanks for your understanding.
| >
| >
| >Best regards
| >
| >Baisong Wei
| >Microsoft Online Support
| >----
| >Get Secure! - www.microsoft.com/security
| >This posting is provided "as is" with no warranties and confers no
rights.
| >Please reply to newsgroups only. Thanks.
|
|
|||Vikrant,
I've read and responded to that post. It proposes another test and
requests that I send my schema and scripts. I've done many tests,
most of them work fine, but my actual scenario does not work.
I sent in my schema and scripts over two weeks ago. I need you to
understand and test my scenario and tell me what to do to make it
work. From Felix's note, that process seemed to be underway. Is it?
If not, who at Microsoft is going to take ownership for resolution of
this problem?
Thank you.
Kees
On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
(Vikrant V Dalwale [MSFT]) wrote:
>Hello Kees,
>Actually, one of the Microsoft Engineers has replied to your post. This
>reply can be found at
>http://groups.google.com/groups?q=la...t&hl=en&lr= &
>ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
>Please follow the suggested action plan and post if you have any further
>questions.
>Thanks for using MSDN Newsgroups.
>Vikrant Dalwale
>Microsoft SQL Server Support Professional
>
>This posting is provided "AS IS" with no warranties, and confers no rights.
>Get secure !! For info, please visit http://www.microsoft.com/security.
>Please reply to Newsgroups only.
>--
>| From: kjvt <kjvt@.newsgroups.nospam>
>| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>| Date: Tue, 01 Jun 2004 10:06:18 -0500
>| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
>| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
><u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
><djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
><tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
><BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
><ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
><ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
>| X-Newsreader: Forte Free Agent 2.0/32.652
>| MIME-Version: 1.0
>| Content-Type: text/plain; charset=us-ascii
>| Content-Transfer-Encoding: 7bit
>| Newsgroups: microsoft.public.sqlserver.replication
>| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
>| Lines: 1
>| Path:
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGP08.phx.gbl!tk2msftngp13
>phx.gbl
>| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
>| X-Tomcat-NG: microsoft.public.sqlserver.replication
>|
>| Hello,
>|
>| Have you been able to reproduce the problem I'm seeing? Do you need
>| any further information from me?
>|
>| Thank you.
>|
>| Kees
>|
>| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
>| (Baisong Wei[MSFT]) wrote:
>|
>| >Hi Kees,
>| >
>| >I am Michael's backup since he is OOF today. We have got your file and
>will
>| >working on that. Thanks for your understanding.
>| >
>| >
>| >Best regards
>| >
>| >Baisong Wei
>| >Microsoft Online Support
>| >----
>| >Get Secure! - www.microsoft.com/security
>| >This posting is provided "as is" with no warranties and confers no
>rights.
>| >Please reply to newsgroups only. Thanks.
>|
>|
|||Vikrant,
Let me correct my prior posting to say that it is Baisong who appeared
to be testing my schema and scripts. I don't know where I came up
with the name Felix, but that's part of the frustration: we've had
five different support people responding to this thread.
Kees
On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
(Vikrant V Dalwale [MSFT]) wrote:
>Hello Kees,
>Actually, one of the Microsoft Engineers has replied to your post. This
>reply can be found at
>http://groups.google.com/groups?q=la...t&hl=en&lr= &
>ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
>Please follow the suggested action plan and post if you have any further
>questions.
>Thanks for using MSDN Newsgroups.
>Vikrant Dalwale
>Microsoft SQL Server Support Professional
>
>This posting is provided "AS IS" with no warranties, and confers no rights.
>Get secure !! For info, please visit http://www.microsoft.com/security.
>Please reply to Newsgroups only.
>--
>| From: kjvt <kjvt@.newsgroups.nospam>
>| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>| Date: Tue, 01 Jun 2004 10:06:18 -0500
>| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
>| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
><u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
><djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
><tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
><BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
><ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
><ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
>| X-Newsreader: Forte Free Agent 2.0/32.652
>| MIME-Version: 1.0
>| Content-Type: text/plain; charset=us-ascii
>| Content-Transfer-Encoding: 7bit
>| Newsgroups: microsoft.public.sqlserver.replication
>| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
>| Lines: 1
>| Path:
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGP08.phx.gbl!tk2msftngp13
>phx.gbl
>| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
>| X-Tomcat-NG: microsoft.public.sqlserver.replication
>|
>| Hello,
>|
>| Have you been able to reproduce the problem I'm seeing? Do you need
>| any further information from me?
>|
>| Thank you.
>|
>| Kees
>|
>| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
>| (Baisong Wei[MSFT]) wrote:
>|
>| >Hi Kees,
>| >
>| >I am Michael's backup since he is OOF today. We have got your file and
>will
>| >working on that. Thanks for your understanding.
>| >
>| >
>| >Best regards
>| >
>| >Baisong Wei
>| >Microsoft Online Support
>| >----
>| >Get Secure! - www.microsoft.com/security
>| >This posting is provided "as is" with no warranties and confers no
>rights.
>| >Please reply to newsgroups only. Thanks.
>|
>|
|||Hello Kees,
I apologize for the confusion which is casused by our internal tool
problem.
From here onwards, please track the thread at
http://groups.google.com/groups?hl=e...txifQEHA.3996%
40cpmsftngxa10.phx.gbl&rnum=1&prev=/groups%3Fq%3Dlanlb%2BMerge%2Bfilter%2Bin
consistant%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DEYOtxifQEHA.3996%2540cpms
ftngxa10.phx.gbl%26rnum%3D1
on which Microsoft Engneer with name LanLewis-Bevan [MS] will be working
with you shortly.
Thanks for using MSDN Managed Newsgroup.
Vikrant Dalwale
Microsoft SQL Server Support Professional
Microsoft highly recommends to all of our customers that they visit the
http://www.microsoft.com/protect site and perform the three straightforward
steps listed to improve your computers security.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
>From: kjvt <kjvt@.newsgroups.nospam>
>Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>Date: Wed, 02 Jun 2004 08:30:56 -0500
>Message-ID: <5glrb0p0jj73amu7boccvvdolmu98qemk6@.4ax.com>
>References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
<u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
<djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
<tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
<BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
<ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
<ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
<6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
<kmY8vOFSEHA.2260@.cpmsftngxa10.phx.gbl>
>X-Newsreader: Forte Free Agent 2.0/32.640
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Newsgroups: microsoft.public.sqlserver.replication
>NNTP-Posting-Host: adsl-67-67-196-3.dsl.austtx.swbell.net 67.67.196.3
>Lines: 1
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP11
.phx.gbl[vbcol=seagreen]
>Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51292
>X-Tomcat-NG: microsoft.public.sqlserver.replication
>Vikrant,
>Let me correct my prior posting to say that it is Baisong who appeared
>to be testing my schema and scripts. I don't know where I came up
>with the name Felix, but that's part of the frustration: we've had
>five different support people responding to this thread.
>Kees
>On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
>(Vikrant V Dalwale [MSFT]) wrote:
=&[vbcol=seagreen]
rights.[vbcol=seagreen]
(1/1)[vbcol=seagreen]
13
>
M4$L#!!0````(`$""LC#YB*C2-`,``$L2```J````35,@.4F5P;&EC871I;VX@.
M4')O8FQE;2]C<F5A=&5?=&5S=%]L;V,N<W%LO5=-;]LP#+T'R'_0K4D1]&O#
M,`S809'H5*LL9Y+<I"<A!89=!NRP_7^,<F+9<CYD9TU9H$`2/_&1(A_IV^NO
M_V77M^/1[37AF[^;U\V?'U^(!6.=+!CI;]LS4IY.FS^#::`6"*>6SJF!0&4\
M^OE[//)_Y8%OW\(S9L!N7G]A^*M"/SEA(4\%'=D;9P#CETV@.-WQ>W#2\)N,1
M>EP)MR@.%CVF42GPO07!05F0"--'%RC_%"DE488DJI20<,EI*_``KP2?3676<
M7?8YSIL_8U93Z"((GLY$3N7D_L/L;EI_V6"X>#;`.CCV2/7DXY1$%OFQ+X[%
MKBK,YRYF%^,6MP#EM%$Q\B0NY.:*7.WR0M?[0=8Q/K1";/GU&%/./>D&FL`L
M-7=S6#ANVWZP%JS(@.;2MP?CG,R&=QX8$]?`#B@._RXY\?ZL=H!MTK.Y+[!F-+
MZXK,R=S20##!S>"C73=][YB:A=I=,V7VV2G\WSXLE'(48O>8NU"D+%_&>4V1
MSZS8)W_8:\!(U(2\&':!VLAGUQ6,1'-+`]+1DKL5ZDX-3&*0&^BXBA/<EKKX
M-K106*&,U50H2Y9/KE'&I<;,Z1?R!"^$3'8!3\>CZ65&!69'6(Q5DB%V^5'1
M\-J."G^+'*R,[O_\4=%O\GB+Y3C0:&,3XP*/TPZO.VN75$JNUAC]4`RF#S<.
MXVAK[@.=N][.'`]PRH:3S6D_YMX!+8'P.<K"/4<4GJMUCZ"*W^YC[DQC#5.PL
MX2?3OH:`(M)JNTM>(F^X-C!EV2`U@.K5U>^.N)R8:7:G1(%C?T=#$4SB]Q'!*
M
64\'..(I^CE+'J-4T>JU[4[)?3/A0!/S[),+N\]M6\PI+L/R4&W\65KZ81M01/*5P&P'/&-1P=@.2BG:&)6W,)_N8E`'XUO1FN;GPY48Q53YT(6,MKQ4=U'S
MM+?*]\%TM[P^F+B'D]U5Y<'+2SH/L6)R)2-0C\Z'-7L<XJ?*-9,FV\OU\9>F
M]U*E*OP*=.[FW-GF=@.V\M\N%1FZ+VGA$I<6>.ZX$V\OEO.TF"VZ<A@.PT*'Q9
MJ==(DA4:!#+PGEM+Y#
\+PY^GK>0&J.)U@.&&3_"L_[]/8C^`U!+`P04````M"`!`@.K(P48FJY#D#``!-$@.``*@.```$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO
M8W)E871E7W1E<W1?<F5P+G-Q;+U738_;(!"]1\I_X+;)*MJO5JNJ4@.\$<)8-
MQB[@.3?:$LE+52Z4>VO^O#DZ,P?G`3C<[D2(YX3%O!N;-^/;ZVW_9]>UX='N-
MZ.;OYFWSY\=79)@.V5K$2];?M'BE/I\WM013#AB&*#9YCS3R5\>CG[_'(?:J#
MO[Z';\B!V;S]@.@.2L"K6TW+`\%79D[YP#R(!H0[VA\^*FY349C\#CBMM%Q6E,
MHY+\>\4X9=+PC#.%5+%RJT@.AD"P,DI40B+(,5P(>V(K3R716; V?*/MLY<WO,
M&@.I=!(+="<^QF-Q_FMU-FQ];#.4OFI$.CCQA-?D\19%%?LRK);&K&O.EB]G%
MN,4MF+1*RQAY$N=S<X6N=GG!Z_T@.FQ@.?@.A`#OPZCJ[DCW4(3F %)1.V<+2TWH
M!^Z"X3E#H;48MS[CPCJL3U`//TS207[<^J%^M"*L>V1'<M]B3&5LD5F1&^P)
M)KAI6-IUT_>,L5[(W3%C8EZLA.]P,W^5HQ"[V]SY2TKR,LYKBGQF^#[YPUX]
M1H`FY,6P`U1:O-BN8"2*6V@.F+*ZH78'N-,`D!K@.Q%=_B!+=2%<]#+PHII#8*
M<VE0N;2M,I8*,J=>T9*](C39!3P=CZ9-LW@./B6Y;!62'&XA5H"%V^5;1\MJV
M"G>*E!D1G?_YK
?YW$6R[&G$6(3[0*V4Q:..PNO5$JNUA #]4`RD#V8.;7'0M]SVW^]G#`6X9E\(ZK<?TV>,2&)>#G)FGZ,8G;KO#X$5N]C'W)S&:R-A9PD^F
M(`F"84`:97;)2^0-Q@.8B#1FD1FQM[%Z[ZXF)6E>J-7#2MS6T\116E1!.Q8*0
M$G[.4>1SE#)6O;;(8]6+BOURV@.<BX-HG&F:7U[Z&EQ^2W5.B\5U<^1H:$32A
M?#4`KB.\\R@./3"E%B)%Y@.'F\BT$=C"M%H]N_#]_$**;:ARI$-.6EJ@.OKY=XH
MWP?3G?+Z8.(:3E97G0<G+^D\Q(I)I8A`/2J?K<G3$#]UKHG0V5ZNC[\T?90J
MU>'7H',GY\XTMRO@.O5G.%W(H:N,1%@.9J[K@.2;`^7TM!-YMW`ZHPI)N%EI1DC
M458HQH&!\QP,D=L@._'I]]/6\A30<3[#T,GZ$9_/_1Q#]!U!+`P04````"``2
MB+(P!=H#;H8!``!C`P``+````$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO9D=E
M=$-U<G)E;G15<V5R240N<W%LI5)-3\,P##VO4O^#;TW'/L2-RPZE2T?02$?2
M2B`A55V;;4&C14DJX-^3M@.,);1I"^)9G/]O/>=/A[%\QG+K.=`B;A3!AHY2H
M3*J%(G/X0_0]?IMT/MH>KB,W(-ZE-AJ0%GM1&+"KJ?H%](>NU\\6T.`Z@.\';
M3B@.!LH09]'`F2^0=B?!\R*NR8PSBZUL<)BL6KS!+'I$L1^`1S8M\GZNHJ0H C
MZ\K6S^#2=YU2U:^P.:#'QW&=;0WMOAPG<)_&"9YG9(YI0B*"& 4!,^U1`.<EH
MNESR%K.,1=RR0H:#!$.4TC`A%C\^/K([,)RDC'(H=KE"5Q8(>$N^Q@.M"O[*@.
MF[4V2E9;Q%..6<9I<(>1/T+A3<`(G>,'Y#UY(_B1]2\N;<42TY\D'\9PEN;;
M)3#MU)\3'T4GU+=@.KWX\;JQ(4/5>0"5$J2$O"J$UF!K,3NKON]LY*J^,=80H
M&B/`_D2YKB<G?L,R@.S189>W[:[O.UD9H`])T#CT8JBMD>#4YV0M9QVCP#O;I
M>WT"4$L#!!0````(`!:'LC!AZP$74@.8``%P9```I````35,@.4 F5P;&EC871I
M;VX@.4')O8FQE;2]S=6)?;&]C86Q?=&5S="YS<6SM&-MRTT;TF<SD'_;-<1J;
M))0.9$C)34/3<>S4=DH[P&A6TI$CD':%=F7PW_><75T=QUSB\H0>;.?<[^<H
MCW>/'_3L/M[>>OQ31O5L3@.:[R&3*5.XI/XM2'4FAV-<_F[)C,U+0&Y9`-@..6
MYG'<<NK'N-'KF7"FD9@.Q?0OW&6/]-0\[@.UDDCMC$X)B6S`.6Y8)QS2:6Q8/L
M"$TTCPD5:K&\`B`@.%A[@.UVVD6!0R/@..A&?Y&(&)5Z@.9H$1=2+!*9*X/>WLH5
ML#=39S)U!Z/S=]M;KT;;6\@.,GR.E%=M1$(.OV2X+,YDPM5#2>X\`Q;:W'CWZ
M=`L9L"A@.Q\R"W2C8Z5Q-,DCCR.?DH-NJITZWBWSWBE_#V="7YEY)@.XH[QO:Q
M<]WI&AKX#'[IJPDZQ;R5_Y.V@.&$M8:_`*=1C,-<W9X/+R1_.>.*,_W;&P],K
MY^7+ERTZ-_#:0HJ\7*!G&DSNW\32Y_$[]EYZ;$UP$Q5X_<"3?8PRDBIFW14\
M`?+SBISIE6IZ9]S_D*<=BJ?SCW-^,W4:`M!]H]XEE2?XX192AO>(V9A9DX7P
M'VR4$=)L#4<$W]88-@.E":NRV#&Q+8!O@.AUC@.'V+6[_>WM\A&JI4,$CF'P&M4
M'SL)O-+%LCLZ5NXFQL-/&?6S.1GL%,?]RZPC8W^3<C87)VQLJN^:Q]NRA\<
MB)B;+RS#([9ZWAZ5+E0_OGEMUK-AU;XK=P9.B'4KXT%K86_]WE&5J:Y>I'8J
M5JNZ06#L<=,LDEFD%TBVW]\W#Y'@.V&QPYUHFJ,PG[@.!J9ZJ!V]JD,JPK)>":
M>QP#91;`=>7[:K_['1O%.B4C<PS@.1/X3)_UJIGK85UJK%'F44:8S+A3WC7';
M6XQ=..>#T['#3E#HY04[NQR>CO_=.?BMVT*.0>>9.)<!L,OAE %`39^"<3UL8
MC!IA`O!CCMOA1$$VA\R,>S'GF7_+LYTG^T:P`MW"'[.=4N!)[ 5"W)0Y7FR^3
MA(N@.(>YP_Z`6V*"@.;/2^%&)64UR<%>6+(7M7P(L4-N$7N,JQG+`&,O9FM5"D
MFC2*:DJ%<UC!J&DPL8]^:;EO`,-.DZHRB/JIB9B`GU.17E'(#W"8=):C1"(]
M<X#096D4]'J*OKBJ0W=P^*P5N0;7NH.&6'#L)+G2S)<BC&9T"9A3C(48E3@. 2
M'^@.L-LX9B+D2U,>8A@.A.D#T62`',6S!IEXEKF/M(T:Z>C_$7TMV@.((O-N+FG
METH_S,FD(4E=#4IWK#/F2BO/,U_F0N_L=N]>:5@..,,/Y`$NWVK"#@.@.<]$S"\
MEE]@.4D@.NF9/CJ=J\U'`2NH6819N/`EMFPES^`H<E@.8Q117,>TZV++P-K+\B=
MPJQV3KO6R4(0)F1X,Q@.@.\,QY=3DL<AI`&%%F;!'8;8)"FLZTV WW9M>H"-1X4
MND8WT^N;Z5[K-&W;AC@.0W(N!N`YHXFJ>:5=I2*TD@.N'1&84+-X8YQ"Y^"!W+
M&>(.[^`2'L4TBY81`K0"4RMW4"F^M17PXI@.V\`K4GO)#R9H @./D>%9'Z?5D*9
M7G=5=2!>?A*XC-#V2-0DH]=#9SP882K*I6=*R&3LQ!F/1V/VXG>VS_"[F0&"
M==E,8F/]E4?Z=:1OQS*.*:JV4;\Z;13KNZDSJ6@.FP4\"$HGOD+X/2KE^,?;)
M+U%!B^UB61KP6E;!$&+@.:NK#!K!-FH'&@.')-C8MO4DU@.)#1.&AZ7VI2+(Z:U
MR!$:QGQ6LAG)=6[HHJ$W]GYY#"R0(*DGH$EI-60:&V:O'.`$KD<YE4NQYFLM
MC3>='Y+4/$4;8&4[KNJN'V1566HV:JL,,YAJ1M1!?;"!SO#"'O^4O$@.O'4& &
M"=^%)WQ.JWB9_:C1B]/QZ?!\=#.<,J,N*TB6!!:RCDBC/>',?,V@.7&YXAPGX
MA)-6^[<_='O;/*T[REW[_ZW__S0/&J?4>A6-(UX5QX^;V/HZ:%FP"MM0LQ(?
M9O`Q!^$ORA/_UQ9P:;[4B`QB]&L.ZRA06X8_`6>:;]W<;U&@.8P&G(?5L!7A9
M,%47JK/=2_U=B"O@.N-E60"VUCA)P9>A:94M,;>3ADZ?/GS[?JS:R&U+<\`TH
MF=DTA3Q69BKR&(>(X*FZE1JIXJ`HE;=O5V?R[:0@.)F9\771#G ;8E$M`X75B7
M@.9+Q');TRC",)0]LF;8P]QX8RR]2W_A_K_\`4$L#!!0````(`&B)LC"\<,:V
M<P4``+XE```G````35,@.4F5P;&EC871I;VX@.4')O8FQE;2]415-47U)%4"!P
M=6(N<W%L[5E9;]M&$)[G`OT/>DL*U(:<.@.7Z4#2)';M&?00YF@.<W(&12DM7J
M8$G)COKCFWPSLSR6NSSBU($:"`0/[<Y][>SJP[\[M$,]>DYS&M`536F"KS%&
MEG1-0[P3/&,9#P&QQ'L!B!Y%\HMQ!I0"YEOZAE;RU:.9C"WQG<CX,5W(F^\ A
MO<<=`BH%W:"&?@.2Z"XP7_)[(&$LY$QX_XSZG!_0:LK_",Z"7^ 'J!D>\%6K%=
M^)E(-9:Q&!*KSBFTS3!O@.#/%3!EK"1P>>>#HD^E\Z4CRSH%56S^%)I%C9[]<
M99OXK#<06@.6N'Y.UJIMILV,$JBEP$F#$'KRS5KE[>([PK')P8 Z@.'N`30,WR]
ML'S#/'CL#3VC4SH!G5]!XR7>_/Q=GN>P[!F^?I%K-]>`(XQC<5Z1OF_F4UIC
M+(1<,\Q&EM_G1H\;\;W"<W1,`7D+C%C\?^V-%#\T_^H&/0!WEG8M<C&?>KQA
MGK]#:!#`C@.M`!!)EFH=SL4)!822\TA*-T-@.HD9D)_6-HA2+%R/AUV2A')+;D
MG)N(14=X3XT$37BI8,5BRP5F5?)`O,&2KH0*:S65L:2!5B@.1% (O?4UR!0[W)
M"B/,Q^(KMF`&^XCV*O/LI;%(65!S/5:6J6S#H#8J]VC?X/R%V:&192"R3')8
M]LJU\!N+EMTB*I6<<K-9?1Q#[B;+V)0T9Y;X/<@.]K-DR;*1R8Z(K,K!5J:Z$
MDOJ?_5W0TC5A%Z/'8KL#X"5B1[;A&^&2H#8<TD/ZKB1U)%',DG).A7D^!U*%
M&5_U2%KTYU7M?9X/H<4]L.IWN;HT8U7SI1JI:4ZMOOK[JZXOZN^V"CR1JCRD
MOR6N6(>UV',-:IFV>_1CGA\N;%&%U/L93CT&CTRIJ+UU-/HM-,KV#H7.R,3`
M(J\A37)H;'*LKC\1NDUB.Q*Y6](<#_+,
)GGE%'V#)M'IW)**_)@.:79(US[MN/HM/)MI_$"/Z2>YZRK[GWA?X>WV9I^RON\XL>H;V2>W8ZMFT9AXQ=-\K,LE
MM@.3'3RH9>;<\8CS?JO$,6I]`Z]=XGM,?TA_.!&8BODN$`\=K6M%FTS2YH+=X
MLZ].\7TL^MA>VVSYH]SBO`ZMC-6USJI'-EO^%!3<>.^ZZ\AZC)"F(E^7_8:-
M\SGZ5"EE\$^1'8>(),8XQ/,TQTAI(=4]-+7HEN9D=X;:,=3!7Z$2Z=K?A9N]
MWFFGE77<7?9*<]+>O^@.'>8\YDYC0'`_1\67^*7C8W9QVM8'P&%IQ%8)69.G.
M.ZDXQW0QRI+Z9.1YCA+N8`):.!KU$1O]FNN`CG!E:Z7M6UV94['`3<EC5>[:
M%0XEF\K[B%`Z@.VS?[6(JS:6)P"GY^N?"3FZ?IUY<BB_*]FJ/L(&I&;SV,Y6Y
MX:G=2-:M-_%6V2>867OLQ#Z;@.(;*M9+YZLI?].A%_V&OXW[KU^V&]"2'^UO=
M@.TU,[`;X'>?]1RS1%I9HN;LRCB6.\4#R*)&*FHI&;-\TUZ2IPG[Y^O,6U2!`
M77@.%F<[OM?;X.6WKSK;NM$77MNY\C77G`I"_`?Y$<,_NN?;4< =O6G\VM/ZSO
M+2!XY[&2W.^1[@.@.>"M0T]W,5JCAGUQG.MK%@.WIK3=N81883/6XO3+;9W9NT]
MW,4YV[;Z;:O?U?]VL]X[[,:=N?N5L<1<.;&=D4=Z8D]IH"^OYKIQM'_I6KJ
M]:6JYK9KZ[?*_GE9L3GUT/<OYUTJ8MLY6K6.E>.Q9\5CE_I:AK^/ZEI_RE7F
M[)[/'TF'6,56KD=R[OL<<`=X!DY'F7'@.TW_];]>6SN56WY,6--K[HTN/MN]H
M%^.ZWSZ6T_=#C"G.I8>O']Z5ABO_Q/PG%,C_M\6_1E]O-/G/+;I$DHVYZ7%D
M2[L),?014$L#!!0````(`""2LC!_O5PM)`0``/H*```M````35,@.4F5P;&EC
M871I;VX@.4')O8FQE;2]415-47U)%4%]A=61I=%]D=&PN='ATI5;;;MPX#'V>
M!?8?BKS3("7JPGF31*F;12[%Q$7[Y@.\I\N]+9S*-9YIM@.M3P@.R79$@.\/SZ&O
MRE==M,\WR^>OUWJUN_IV?7KZN?(TZG?S86GW=V/1>1U^OYZWPX=Y*0_]82FW
M-AK7=S?+7+XO1?\]SJQ[W?;YGZ6==BZ?;^>7T4.[V[XP#K;?32^V,!_FXQ'S
MEZ7=S>UT_+Q\.>A2^^?SB6[[/$T\7+?C7O/]<OABGWWMQX4;V_KV7C>#?GC:
MY.^_?I2,5;1VT,056&N`TEV"&&AP#P%#P<?=C]3KZ*4VJ!+7UPK;:R-"[:FK
M.#=2<(\[9.]]VCE$!@.Q`^1.FO<M[+Y.+>+QV=EU=/=_VI@.-,@./X3XO[IWNU(
M)`/:32^3-B=`"'XS9]^_')4^D4W::32Y=#K*\#$F7T-OT(>+P,6BS]0&)$%R
MSF=R/AB^Z-1Q"+88*@.%C(Y!B88@.BY6*Y:*R&3R2(VYU!V!UC0WHU7OQ]O''/
M>1+V+_%:9FMG">`E=&#?&;*G`=E)$C%D&I+%6V2$-LA";5V`F3.4%LBP%<V2
M(U.1E0\70UX/M4C<63`7+-`:%.9+`/9-/)N+ET"/>_NWB(E[CU..&Z`2HD9M
M"3(V!%ZKKQ;+?18A%2E:/!G03HT\H\`8I1DQM4+A,"`T';T%IIK:X\X[8<>O
ME]/[RBU]I-SB'O.$N$%5UT+QOL!`+L"Y&'-M1=78QY6<'N***C,%8<O<L$IC
MR0.J&Q5&356-NV2J...P1$W/\`U07!?A.5&$?W$2(&ZZLBHA]@.S3$BG(85X6R
M2:0VE:2-U&5#Y=4"=V82P5G9,JVH5!.DZ"G&6$OKY:>(-B9!M/=ASW'*^"S=
M2WQ^+5_:E.=O1?<F:R%,YFPO^`H7'!4+Y,S!1!?,YU!-4AI"0NE$K1L^<=V<
M,J&I+*B)KCC39F5P%$I(I9-/<C1!)W_`VL=J,>W)37Z+JI>`-:RJJ<YJ,;`S
MNW8,U=PBL:98>!BJP,/(-%TAJ3DDQVR23`H%K9*ID/?:GUFC#Z/Z.%>(4]H:
MNOAB&G$"KI@.KL!48E!H5FK9LP3,:6D.E/49A,GNQ!...]TZ!Q;&G@.(<.ZF?*(
M6ZXVASK<LYM<.,GZ/?@.^REK<$T]\U@.#8@."5ON]D3L,D&A!N#VAA)J/LG7W39
MG$:JAVR=&>R;##5FBZWXH1J%[#('<1Q].$9MP;C_;P!^)6B[?D+J\0R4`8V_
M`K5N_290AU.4#5#/(R1-':15/?YYU#X4>JS&4"+34WH"&EA\%/!])3(5Z]'2
M&I2<15E=J<%$YSQ)P,O.O'M=*!C/3=O7D:KIW'*)EDLU(Y9H,A^B/J41K1/K
M&DD?K?2N@./9C9"Z(%D0<"*3-GFFX6OQSSSW)GX`V_?/70O+@.TEG*:4VY"Y<I
M/Z^M4S]W&T-\->5,9X[P'U!+`P04````"`"ZD;(PDY9":N$%``!J%```*P``
M`$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215!?=VE?87-G;BYT>'2]
MF,M2&\D2AM=,Q'D'A?;547FIJDSMZHI]S(@.)$'&&L^%!)OSND]5"-C;@.@.3&X
M0XNN5BN[Z^///S/9_N_C7;X^W]^=WWQLV[.M+;^>K5^LB_7L<'EW<]VOGKBR
M__UTI?3SN\.UK=;K5Y<7_:[.VP_Y^M/=X?;!XOJ0'ZS:3;]KAU.4OF_'*./J
M^G#7]A?WRPM;]3_KAP>/J!?7XQAG?OG[93N&61?]ZORX6B.L2[OS/[_]E4ME
MS``NDF?'TMEI@.>H\)8FC!PI9/Y_]U7J,RI"<U%8=YP(N^Y$=\]"1>FD\XN<S
MQDC`]N:E-D#:V//^>_EAOVF7?,OCNT9>H\.O/-I`WX7>,=I\9#\>IQMKYJD
MXXW;V]M;>^!Z>GY0/5Z=Q]9CD#42.Q\<K)%\W`$O/OC[2&=@.*+2)#U35C9R\
MXU2RRQBZ\S5@.PLRY2S44*(&5HCKJ$T7*Q8G6ZK*(-FZ82S!BF((0G&W_O/U_
MCH%7%'G?PH%.4#G=0.\([4]+/@.5Q>TAAN.-VWL2WZ,X$F`'<>.-P/P\>6T+
MGA\#2SL?%MO20V`8!D)-XFRG)H4XU!6N!FP`55$6U&[`3!ZCFR1<T5@.<M\PN
M]Q%=Z:DW11PIX.<SB$3\QL`F+8=A;H!EQ[A(/&W@.!<".R(T"^0W$7;`(<=%X
MTLQSG-`O";X1EJ#7R`-="J8N#@.F=^CCLS0:I4")/9)PZ5""V-QXCF[!\*2YS
M&"[4-GH-#"75R2E8FKUGCF%8Y&URS*<E4'J(`EO61*.[(&QV$U-U`HP.FT21
M2AA*,Q34<A(TR00T0V*0X4IKR27SEQACR;7GB8(YQK>6S$0!& R^[H#N,"_,O
MRS'36%A.TKD'1JF/C(U<+Z8'KF#),\HPXTU9,41,K4Q3ZJ/FWIL]J`?'PYL?
MQ>$=M&KG,+!DDY@.JQ,1O"PQ,.#/'#!C8)RPJK\BQ8P"9*38#6)X:@.2_9<^1#
MCF!Z'NB.:$GQR]_C&8CL'^3Y"G%0+"6GZ'*=-:M6RRST)L)"7<RP:PS!(&8=
MH0ZKA69BEJ?,8C\(8`K-350BPZR%2!&GLW^X.;]6RPW;4<U_'/+'_>93WI_G
MJ\O+'T'[_KAW=A\=KAM`F`R(OD!\:0*F)U"07QB_2<!HVU!,M O<\;*-*YMG-
MH*2J-8<4,PPQ%(%'!C'%>6C14$0S>9^:%7UN9O9`U/K[>[;N`)=$)SF\3$\_
ME8#>+R2GYZW`?*Z&@.*Q<)>[FRLT:I`'!J>3>H.4A*;_8L9`IH ;RY=M+,$"L]
MO+8U3*\V[Z>T\]B+@.'P1,?..04T[(9H7B17R;-6=K"<4G_VL8\(0E,U&1YT2
MFRAP%#=*LCX1C),OOT([8=:QUVG'6,+J-A;`*GE:%$\!?OSMTWH*NP"+_[9I
MZI!&Q6).G:>-%SN3@.NR*[SQ&$!W*!E&Q-VN0O)E/
:`&:W+*NP0@.J5I[D!)MWQUB\#N2Q=,OJX!I![`H?P/,=&:N3=8H^(Y&`H>3'"T?:ZQ6\UH;XM>V?%36
M0D[ZY(I97(EBF\DT6HL*=A@.P4M4W;QG,O$%GCTBX\["P?T4%/'O6BZR1_%H&
M5A0%1FQU-@.-D?2&+U28;W<!5TJXP&J?9(;XP`3&8,Z%-A*U^DB3SO=KE/E^T
M3;NIGWZTZR>/DQ>I`]EX<^XXFX&4WJ"./95&B@.!AQ&Q3&)DM2\LV7O3JJA6N
MG-"&V9)>T5._:QJ964!:\%6J."+`-4+8(<W9`^F?6I_'#3=Q&P02')&8%EC8
M"6-S-0RM8O.ZU?D7S_?OS4EFO4?_"KNY1P`.=8K.9C2KX`K_Q.GQ\)](,U9S
M#HU6W%E!G"9#45,"2=;^<9JS;,2&'(*-_,$0L;763K/:O<V#Y`#F06URBJK^
MK3G98#(W<!S^=:'T2DZX_OL`-T`[`K.J!^7]V59:OF^'&&)5"M$:F^+-9J59
M.V2_&MD2K&GF&.*+6VE&AK?6DY]N[,/:#M&<!=(KYY$UP)Q'S,/,>>)R`G#J
M`<2AS#_#%!LLITGC>8B/FO"_`5!+`P04````"`#FA;(P!^F*K+<#``!H"P``
M+0```$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215!?=V]R:U]I=&5M
M+G1X=*V6VU(C.0R&KWNK]AVHW*O*LF5;FCOY1+'+!"H)S'+5#T+Q[BL3YL#`
M+%F&KE1:MI5.?_U+OWOSY6(]O[EHFV5SN/X:V=SCN5W<[GM=O\X=[M8ZP_.^
M77?[[7%PT'^."3/8WY29]3B^WK6U]/.U'6PP@.W%QN<[)KY>9<=^V8\(,?D[8
M[VI_B@.XWA_5JK)>?#WK,WUOPN*3U<+MN[?LXM-NLGZ^/.>-P<9R\W!_6SU=/
M_[3;7]ZNWZDO]_URU9NV?MG]_7W.\OONZ=ZO=U=_S>O\^<>]YU%)2@.#N90!Y
M92B)/3@.-H[4D:,?#<L_!E5`5(:;4@.0HWD$$)D$A<X=Y8_<."GE)8-G=W/DR.
M+84S.^;#HINS8RAY0;>@."(-+X/#,N4^/GR6EQ3OGYW1PSZ8W9T_'9F;0S/`_
M9,PGMSOT9LMNF1\[-H]L?53MO8&C'H&&JZ!I.,!6+<;ABP9C(Q>R0ZK`*0F0
M=`_:.=D/.%!B06[RL+!WF/Z;+<MWMOP*&[[&5J^VMWUW^,8FI[&)[ZWT[(`Q
M-B!2#QP*@.<>H,6O'D.VF[WV5+,P5[.2!4#N4$"OTD)%B+*V7]+!(8N+?8S/=
MZ$VV$W5KW80@.S,"U52`M".J&&N60D7MI--)D$R>Q^F!LQ1;#8-"&`3)*'$E2
MJ85^9/.GU.0O=&,(^"%L'2L&,I7'4&-SI8!2'!!K&[U&PI+K.]C>K=M'LH6F
MF7VI$'TG*S8>4%K+D%/`E%+1VM78S%2\$U\AT;0<)@.'QI0%*L[9+/?7.#XL3
MB?+(YMYD$Y@.<K]7D2[9W>HG*B'4@.`M5N)D%D@.M2(UG[:6#A9:\G)7N*%Z0TO
M^5:3Z07;$S+ZYVSNW5Z2?//3#("CM1J9-8*H%8PTAZP1;8=HQE91710T+TED
MNIFS0*E-0%4H.VW9U?ZP1/'B3ZS)#]1-]^?;X_)SMDA#D:W+'#:3P30`=KF9
MH5`+J!A"LYN^+Z).G;F-9K5^&X9EK17`O)1B&GU(Y,F&@.K_-AO^7[9?[&T>2
M8'46^O3)K*:@.5&-@.ED;-:XFS)K&XCF7V&_L^MW@.%];8A9F)[,-RJ$4XO24BO
ML_$SMJ-IO&!;?L*(8*PG262./KJ:;13S-:"F9#TS$MCVUIMX/W+TTQ+[...,(
M##6S56GWPVRC=;#=HFCD7$TKLXV<K'4,`^5-B7C6V8D2O=,2.Q-&(0=N6%>1
M3$OTH\`HV;8Q-+]TQ=@.B#V>:31A[QS)=;)OV84"+&)(.MA:T\D.RUZW7)9*7
M;.A>9XL?5'[_`E!+`0(4"Q0````(`$""LC#YB*C2-`,``$L2```J````````
M``$`(`````````!-4R!297!L:6-A=&EO;B!0<F]B;&5M+V-R96%T95]T97-T
M7VQO8RYS<6Q02P$"%`L4````"`!`@.K(P48FJY#D#``!-$@.``*@.`````````!
M`"````!\`P``35,@.4F5P;&EC871I;VX@.4')O8FQE;2]C<F5A=&5?=&5S=%]R
M97`N<W%L4$L!`A0+%`````@.`$HBR,`7:`VZ&`0``8P,``"P`` ````````0`@.
M````_08``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO9D=E=$-U<G)E;G15<V5R
M240N<W%L4$L!`A0+%`````@.`%H>R,&'K`1=2!@.``7!D``"D`` ````````0`@.
M````S0@.``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO<W5B7VQO8V%L7W1E<W0N
M<W%L4$L!`A0+%`````@.`
FR,+QPQK9S!0``OB4``"<`````` ````0`@.````M9@.\``$U3(%)E<&QI8V%T:6]N(%!R;V)L96TO5$535%]215`@.<'5B+G-Q;%!+
M`0(4"Q0````(`""2LC!_O5PM)`0``/H*```M``````````$`(````!X5``!-
M4R!297!L:6-A=&EO;B!0<F]B;&5M+U1%4U1?4D507V%U9&ET7V1T;"YT>'10
M2P$"%`L4````"`"ZD;(PDY9":N$%``!J%```*P`````````!` "````"-&0``
M35,@.4F5P;&EC871I;VX@.4')O8FQE;2]415-47U)%4%]W:5]A<V=N+G1X=%!+
M`0(4"Q0````(`.:%LC`'Z8JLMP,``&@.+```M``````````$`( ````+<?``!-
M4R!297!L:6-A=&EO;B!0<F]B;&5M+U1%4U1?4D507W=O<FM?:71E;2YT>'10
52P4&``````@.`"`#%`@.``N2,`````
`
end
Hi Kees,
I am Michael's backup since he is OOF today. We have got your file and will
working on that. Thanks for your understanding.
Best regards
Baisong Wei
Microsoft Online Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.
|||Hello,
Have you been able to reproduce the problem I'm seeing? Do you need
any further information from me?
Thank you.
Kees
On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
(Baisong Wei[MSFT]) wrote:
>Hi Kees,
>I am Michael's backup since he is OOF today. We have got your file and will
>working on that. Thanks for your understanding.
>
>Best regards
>Baisong Wei
>Microsoft Online Support
>----
>Get Secure! - www.microsoft.com/security
>This posting is provided "as is" with no warranties and confers no rights.
>Please reply to newsgroups only. Thanks.
|||Hello Kees,
Actually, one of the Microsoft Engineers has replied to your post. This
reply can be found at
http://groups.google.com/groups?q=la...t&hl=en&lr= &
ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
Please follow the suggested action plan and post if you have any further
questions.
Thanks for using MSDN Newsgroups.
Vikrant Dalwale
Microsoft SQL Server Support Professional
This posting is provided "AS IS" with no warranties, and confers no rights.
Get secure !! For info, please visit http://www.microsoft.com/security.
Please reply to Newsgroups only.
| From: kjvt <kjvt@.newsgroups.nospam>
| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
| Date: Tue, 01 Jun 2004 10:06:18 -0500
| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
<u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
<djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
<tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
<BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
<ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
<ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
| X-Newsreader: Forte Free Agent 2.0/32.652
| MIME-Version: 1.0
| Content-Type: text/plain; charset=us-ascii
| Content-Transfer-Encoding: 7bit
| Newsgroups: microsoft.public.sqlserver.replication
| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
| Lines: 1
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!tk2msftngp13
.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
| X-Tomcat-NG: microsoft.public.sqlserver.replication
|
| Hello,
|
| Have you been able to reproduce the problem I'm seeing? Do you need
| any further information from me?
|
| Thank you.
|
| Kees
|
| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
| (Baisong Wei[MSFT]) wrote:
|
| >Hi Kees,
| >
| >I am Michael's backup since he is OOF today. We have got your file and
will
| >working on that. Thanks for your understanding.
| >
| >
| >Best regards
| >
| >Baisong Wei
| >Microsoft Online Support
| >----
| >Get Secure! - www.microsoft.com/security
| >This posting is provided "as is" with no warranties and confers no
rights.
| >Please reply to newsgroups only. Thanks.
|
|
|||Vikrant,
I've read and responded to that post. It proposes another test and
requests that I send my schema and scripts. I've done many tests,
most of them work fine, but my actual scenario does not work.
I sent in my schema and scripts over two weeks ago. I need you to
understand and test my scenario and tell me what to do to make it
work. From Felix's note, that process seemed to be underway. Is it?
If not, who at Microsoft is going to take ownership for resolution of
this problem?
Thank you.
Kees
On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
(Vikrant V Dalwale [MSFT]) wrote:
>Hello Kees,
>Actually, one of the Microsoft Engineers has replied to your post. This
>reply can be found at
>http://groups.google.com/groups?q=la...t&hl=en&lr= &
>ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
>Please follow the suggested action plan and post if you have any further
>questions.
>Thanks for using MSDN Newsgroups.
>Vikrant Dalwale
>Microsoft SQL Server Support Professional
>
>This posting is provided "AS IS" with no warranties, and confers no rights.
>Get secure !! For info, please visit http://www.microsoft.com/security.
>Please reply to Newsgroups only.
>--
>| From: kjvt <kjvt@.newsgroups.nospam>
>| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>| Date: Tue, 01 Jun 2004 10:06:18 -0500
>| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
>| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
><u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
><djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
><tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
><BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
><ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
><ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
>| X-Newsreader: Forte Free Agent 2.0/32.652
>| MIME-Version: 1.0
>| Content-Type: text/plain; charset=us-ascii
>| Content-Transfer-Encoding: 7bit
>| Newsgroups: microsoft.public.sqlserver.replication
>| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
>| Lines: 1
>| Path:
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGP08.phx.gbl!tk2msftngp13
>phx.gbl
>| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
>| X-Tomcat-NG: microsoft.public.sqlserver.replication
>|
>| Hello,
>|
>| Have you been able to reproduce the problem I'm seeing? Do you need
>| any further information from me?
>|
>| Thank you.
>|
>| Kees
>|
>| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
>| (Baisong Wei[MSFT]) wrote:
>|
>| >Hi Kees,
>| >
>| >I am Michael's backup since he is OOF today. We have got your file and
>will
>| >working on that. Thanks for your understanding.
>| >
>| >
>| >Best regards
>| >
>| >Baisong Wei
>| >Microsoft Online Support
>| >----
>| >Get Secure! - www.microsoft.com/security
>| >This posting is provided "as is" with no warranties and confers no
>rights.
>| >Please reply to newsgroups only. Thanks.
>|
>|
|||Vikrant,
Let me correct my prior posting to say that it is Baisong who appeared
to be testing my schema and scripts. I don't know where I came up
with the name Felix, but that's part of the frustration: we've had
five different support people responding to this thread.
Kees
On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
(Vikrant V Dalwale [MSFT]) wrote:
>Hello Kees,
>Actually, one of the Microsoft Engineers has replied to your post. This
>reply can be found at
>http://groups.google.com/groups?q=la...t&hl=en&lr= &
>ie=UTF-8&selm=EYOtxifQEHA.3996%40cpmsftngxa10.phx.gbl&rnu m=1
>Please follow the suggested action plan and post if you have any further
>questions.
>Thanks for using MSDN Newsgroups.
>Vikrant Dalwale
>Microsoft SQL Server Support Professional
>
>This posting is provided "AS IS" with no warranties, and confers no rights.
>Get secure !! For info, please visit http://www.microsoft.com/security.
>Please reply to Newsgroups only.
>--
>| From: kjvt <kjvt@.newsgroups.nospam>
>| Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>| Date: Tue, 01 Jun 2004 10:06:18 -0500
>| Message-ID: <6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
>| References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
><u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
><djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
><tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
><BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
><ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
><ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
>| X-Newsreader: Forte Free Agent 2.0/32.652
>| MIME-Version: 1.0
>| Content-Type: text/plain; charset=us-ascii
>| Content-Transfer-Encoding: 7bit
>| Newsgroups: microsoft.public.sqlserver.replication
>| NNTP-Posting-Host: i147254.cpa.state.tx.us 204.64.147.254
>| Lines: 1
>| Path:
>cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGP08.phx.gbl!tk2msftngp13
>phx.gbl
>| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51274
>| X-Tomcat-NG: microsoft.public.sqlserver.replication
>|
>| Hello,
>|
>| Have you been able to reproduce the problem I'm seeing? Do you need
>| any further information from me?
>|
>| Thank you.
>|
>| Kees
>|
>| On Fri, 21 May 2004 00:28:00 GMT, v-baiwei@.online.microsoft.com
>| (Baisong Wei[MSFT]) wrote:
>|
>| >Hi Kees,
>| >
>| >I am Michael's backup since he is OOF today. We have got your file and
>will
>| >working on that. Thanks for your understanding.
>| >
>| >
>| >Best regards
>| >
>| >Baisong Wei
>| >Microsoft Online Support
>| >----
>| >Get Secure! - www.microsoft.com/security
>| >This posting is provided "as is" with no warranties and confers no
>rights.
>| >Please reply to newsgroups only. Thanks.
>|
>|
|||Hello Kees,
I apologize for the confusion which is casused by our internal tool
problem.
From here onwards, please track the thread at
http://groups.google.com/groups?hl=e...txifQEHA.3996%
40cpmsftngxa10.phx.gbl&rnum=1&prev=/groups%3Fq%3Dlanlb%2BMerge%2Bfilter%2Bin
consistant%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DEYOtxifQEHA.3996%2540cpms
ftngxa10.phx.gbl%26rnum%3D1
on which Microsoft Engneer with name LanLewis-Bevan [MS] will be working
with you shortly.
Thanks for using MSDN Managed Newsgroup.
Vikrant Dalwale
Microsoft SQL Server Support Professional
Microsoft highly recommends to all of our customers that they visit the
http://www.microsoft.com/protect site and perform the three straightforward
steps listed to improve your computers security.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
>From: kjvt <kjvt@.newsgroups.nospam>
>Subject: Re: Merge filter inconsistant - MS Replication Problem.zip (1/1)
>Date: Wed, 02 Jun 2004 08:30:56 -0500
>Message-ID: <5glrb0p0jj73amu7boccvvdolmu98qemk6@.4ax.com>
>References: <r8q4a01mr5avm1nmdve3nk5ri7gstmardm@.4ax.com>
<u2i9pXIOEHA.3348@.TK2MSFTNGP09.phx.gbl>
<djr7a0lkl4u8hbbj6tqn03p4lblo78aq0i@.4ax.com>
<tb7ia05vuffd3o0i5tg64326a2hqbs86pk@.4ax.com>
<BLCzsaNPEHA.3972@.cpmsftngxa10.phx.gbl>
<ol6la0t64cafd8i4qlb90vd3ks8qhn7mm1@.4ax.com>
<ezXExpsPEHA.308@.cpmsftngxa10.phx.gbl>
<6p6pb0l5k7ue4j6h9ud35ffmg262qu20g4@.4ax.com>
<kmY8vOFSEHA.2260@.cpmsftngxa10.phx.gbl>
>X-Newsreader: Forte Free Agent 2.0/32.640
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Newsgroups: microsoft.public.sqlserver.replication
>NNTP-Posting-Host: adsl-67-67-196-3.dsl.austtx.swbell.net 67.67.196.3
>Lines: 1
>Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGP11
.phx.gbl[vbcol=seagreen]
>Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.replication:51292
>X-Tomcat-NG: microsoft.public.sqlserver.replication
>Vikrant,
>Let me correct my prior posting to say that it is Baisong who appeared
>to be testing my schema and scripts. I don't know where I came up
>with the name Felix, but that's part of the frustration: we've had
>five different support people responding to this thread.
>Kees
>On Wed, 02 Jun 2004 03:42:50 GMT, vikrantd@.online.microsoft.com
>(Vikrant V Dalwale [MSFT]) wrote:
=&[vbcol=seagreen]
rights.[vbcol=seagreen]
(1/1)[vbcol=seagreen]
13
>
Merge filter inconsistant
We are doing merge replication between a central server and multiple
anonymous clients. We use a filter on one table and joins to related
tables to determine what records to merge. There are two parts to the
filter, one is user, which merges only records assigned to the user
that is replicating. The second is a merge code, which is set to 0 or
1 and basically serves as a completion code: when the user is done
with the record, it is set to complete and is no longer included in
the merge.
The problem has to do with changes to the merge code. As long as it
is set to 1, replication occurs smoothly. After it is set to 0 and
merged so that client and server are 0, changes made to the client
records continue to be merged with the server until a change is made
to the table on the server. So, if there are two tables A & B, when
table A is changed on the server, local changes to A will no longer be
merged but local changes to B will continue to merge until a change is
made to B on the server. Since A & B are related tables, this is a
serious synchronization issue! It is as though a server change has to
be made to each table to force re-evaluation of the filter criteria
for that table, strange.
Here are the details of our setup:
There are 3 tables for which merge replication is defined on SQL
Server 2000 on NT:
1. WI_ASGN
wi_asgn_guid
wi_guid (fk to work_item constraint)
asgn_to_user_id
dnld_merg_cd
2. WORK_ITEM
wi_guid
office_id
3. WI_DETAIL
dtl_guid
wi_guid (fk to work_item constraint)
start_date
A row filter is defined on the WI_ASGN table: WHERE
[WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM
[dbo].[WI_ASGN] WHERE (ASGN_TO_USER_ID =
dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
fGetCurrentUserID is a user defined function which returns a char(8)
user_id.
Join filters are used to filter WORK_ITEM:
SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
[dbo].[WORK_ITEM] ON [WI_ASGN].[WI_GUID] =
[WORK_ITEM].[WI_GUID]
and WI_DETAIL:
SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
[dbo].[WI_DETAIL] ON [WI_ASGN].[WI_GUID] =
[WI_DETAIL].[WI_GUID]
We begin with DNLD_MERG_CD = 1 and merge replication running smoothly.
After the user has completed working on the assignment, the data no
longer should no longer replicate even if the user makes chagnes. We
reset the DNLD_MERG_CD to 0 so that the replication filter condition
would not be met.
After doing this, the problem occurs. The following steps were
executed to test the replication:
Action:
DNLD_MERG_CD is set to 0.
Merge is executed.
Result:
Merge code is 0 on both databases (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local changes are replicated to the Central database. (not expected
since merge filter condition is not met)
Action:
WORK_ITEM is updated on the Central database.
Merge is executed
Result:
The Central change is not replicated to the Local database. (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local change to WORK_ITEM is not replicated (expected, but different
result then the first local change)
Local change to WI_DETAIL is replicated to Central database (not
expected since merge filter condition is not met)
Action:
WI_DETAIL is updated on the Central database.
Merge is executed
Result:
The Central change is not replicated to the Local database. (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local changes ar not replicated (expected)
Why do the changes to the Local database tables continue to replicate
until the corresponding Central database table is modified?
Sorry for the length of this post, but it seemed necessary. Thanks
for your help.
Kees VanTilburg
VanTilburg Enterprises
Hi Kees,
There is something strange happening here.
Firstly, if a row meets your subset filter requirements it will be
replicated to the subscriber from the publisher. Then, subscriber DML on
that row will be replicated back to the publisher.
If, however, your subset filter excludes the row then the row will not
replicate to the subscriber in the first place. Now, in your case, the
row does at first match the filter's requirements so it is replicated to
the subscriber. But when you change the row data so that the row does
not match the filter anymore (we call that "moving out of partition")
the row at the subscriber should be deleted since it no longer belongs
in the subscriber's partition. Because your row (and all its dependent
rows) does not get removed from the subscriber, it leads me to believe
that something could be wrong with the subset filterclause.
Looking at your subset filterclause, the only thing that struck me as a
bit strange was the unnecessary double select. Could you try use the
following instead:
change:
WHERE [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN] WHERE
(ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
to:
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1)
There shouldn't be a reason to do the first IN selection since the
second WHERE clause is all you're interested in.
Also, you might try (for testing sake) remove the first requirement and
simply state WHERE DNLD_MERG_CD = 1 as your subset filterclause. See if
this works and then add fGetCurrentUserID() back again.
Hope this helps,
Reinout Hillmann
SQL Server Product Unit
This posting is provided "AS IS" with no warranties, and confers no rights.
kjvt wrote:
> We are doing merge replication between a central server and multiple
> anonymous clients. We use a filter on one table and joins to related
> tables to determine what records to merge. There are two parts to the
> filter, one is user, which merges only records assigned to the user
> that is replicating. The second is a merge code, which is set to 0 or
> 1 and basically serves as a completion code: when the user is done
> with the record, it is set to complete and is no longer included in
> the merge.
> The problem has to do with changes to the merge code. As long as it
> is set to 1, replication occurs smoothly. After it is set to 0 and
> merged so that client and server are 0, changes made to the client
> records continue to be merged with the server until a change is made
> to the table on the server. So, if there are two tables A & B, when
> table A is changed on the server, local changes to A will no longer be
> merged but local changes to B will continue to merge until a change is
> made to B on the server. Since A & B are related tables, this is a
> serious synchronization issue! It is as though a server change has to
> be made to each table to force re-evaluation of the filter criteria
> for that table, strange.
> Here are the details of our setup:
> There are 3 tables for which merge replication is defined on SQL
> Server 2000 on NT:
> 1. WI_ASGN
> wi_asgn_guid
> wi_guid (fk to work_item constraint)
> asgn_to_user_id
> dnld_merg_cd
> 2. WORK_ITEM
> wi_guid
> office_id
> 3. WI_DETAIL
> dtl_guid
> wi_guid (fk to work_item constraint)
> start_date
> A row filter is defined on the WI_ASGN table: WHERE
> [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM
> [dbo].[WI_ASGN] WHERE (ASGN_TO_USER_ID =
> dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
> fGetCurrentUserID is a user defined function which returns a char(8)
> user_id.
> Join filters are used to filter WORK_ITEM:
> SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
> [dbo].[WORK_ITEM] ON [WI_ASGN].[WI_GUID] =
> [WORK_ITEM].[WI_GUID]
> and WI_DETAIL:
> SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
> [dbo].[WI_DETAIL] ON [WI_ASGN].[WI_GUID] =
> [WI_DETAIL].[WI_GUID]
> We begin with DNLD_MERG_CD = 1 and merge replication running smoothly.
> After the user has completed working on the assignment, the data no
> longer should no longer replicate even if the user makes chagnes. We
> reset the DNLD_MERG_CD to 0 so that the replication filter condition
> would not be met.
> After doing this, the problem occurs. The following steps were
> executed to test the replication:
> Action:
> DNLD_MERG_CD is set to 0.
> Merge is executed.
> Result:
> Merge code is 0 on both databases (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local changes are replicated to the Central database. (not expected
> since merge filter condition is not met)
> Action:
> WORK_ITEM is updated on the Central database.
> Merge is executed
> Result:
> The Central change is not replicated to the Local database. (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local change to WORK_ITEM is not replicated (expected, but different
> result then the first local change)
> Local change to WI_DETAIL is replicated to Central database (not
> expected since merge filter condition is not met)
> Action:
> WI_DETAIL is updated on the Central database.
> Merge is executed
> Result:
> The Central change is not replicated to the Local database. (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local changes ar not replicated (expected)
> Why do the changes to the Local database tables continue to replicate
> until the corresponding Central database table is modified?
> Sorry for the length of this post, but it seemed necessary. Thanks
> for your help.
> Kees VanTilburg
> VanTilburg Enterprises
>
|||I assume that your subscribers are runnig sql server ce.
Take a look at
http://support.microsoft.com/default...b;EN-US;315758
http://support.microsoft.com/default...b;EN-US;287651
http://support.microsoft.com/default...b;EN-US;827914
Marius
|||Thank you for your reply. No, the subscribers are running MSDE.
Kees
On Thu, 13 May 2004 11:25:32 +0300, "Marius Bucur"
<marius.bucur@.optima.ro.nospan> wrote:
>I assume that your subscribers are runnig sql server ce.
>Take a look at
>http://support.microsoft.com/default...b;EN-US;315758
>http://support.microsoft.com/default...b;EN-US;287651
>http://support.microsoft.com/default...b;EN-US;827914
>Marius
>
|||Reinout,
Thank you for your reply. Please see my comments below.
Kees
On Wed, 12 May 2004 18:02:06 -0700, "Reinout Hillmann [MS]"
<reinouth@.online.microsoft.com> wrote:
>Hi Kees,
>There is something strange happening here.
>Firstly, if a row meets your subset filter requirements it will be
>replicated to the subscriber from the publisher. Then, subscriber DML on
>that row will be replicated back to the publisher.
>If, however, your subset filter excludes the row then the row will not
>replicate to the subscriber in the first place. Now, in your case, the
>row does at first match the filter's requirements so it is replicated to
>the subscriber. But when you change the row data so that the row does
>not match the filter anymore (we call that "moving out of partition")
>the row at the subscriber should be deleted since it no longer belongs
>in the subscriber's partition. Because your row (and all its dependent
>rows) does not get removed from the subscriber, it leads me to believe
>that something could be wrong with the subset filterclause.
>Looking at your subset filterclause, the only thing that struck me as a
>bit strange was the unnecessary double select. Could you try use the
>following instead:
>change:
>WHERE [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN] WHERE
>(ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
>to:
>WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1)
>There shouldn't be a reason to do the first IN selection since the
>second WHERE clause is all you're interested in.
There's another layer of complexity that necessitates the subquery.
However, I think it would be better to filter on the Work_Item table
as follows:
WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1))
Work item has a one-many relationship with wi_asgn (there may be many
employees assigned to a single work item). If I am assigned to a work
item, I need to replicate all the assignment records for the work item
(including other employees' assignment records). But I don't want any
assignments for work items that I'm not assigned to. So for example:
wi_guidasgn_to_user_iddnld_merg_cd
1me1
1john1
1jane1
2john1
3jane1
If I merge, then I need to replicate the first three rows. If i
filter on Work_item as specified above, then join wi_asgn to work_item
on wi_guid, that should return the proper rows. This is different
from what I was doing prior (the filter was on wi_asgn, which was then
joined to work_item), so I'll test this and report back.
>Also, you might try (for testing sake) remove the first requirement and
>simply state WHERE DNLD_MERG_CD = 1 as your subset filterclause. See if
>this works and then add fGetCurrentUserID() back again.
I'll also try this simpler test and report back.
>
>Hope this helps,
>Reinout Hillmann
>SQL Server Product Unit
|||Hi Kees,
I am just checking on your progress regarding you said you will show us
your report back. I wonder how the testing is going. If you encounter any
difficulty, please do not hesitate to let me know. Please post here and let
me know the status of your issue. Without your further information, it's
very hard for me to continue with the troubleshooting.
Looking forward to hearing from you soon.
Sincerely yours,
Michael Cheng
Microsoft Online Support
************************************************** *********
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks.
|||Michael,
Based on further testing, it appears to be the subquery in the filter
clause that causes the problem. Please see below for updates on my
test results that led to this conclusion.
How can I restructure the filter to eliminate the problem while still
meeting my requirement?
Thank you.
Kees
On Thu, 13 May 2004 17:09:59 -0500, kjvt <kjvt@.newsgroups.nospam>
wrote:
>Reinout,
>Thank you for your reply. Please see my comments below.
>Kees
>
>On Wed, 12 May 2004 18:02:06 -0700, "Reinout Hillmann [MS]"
><reinouth@.online.microsoft.com> wrote:
>
>There's another layer of complexity that necessitates the subquery.
>However, I think it would be better to filter on the Work_Item table
>as follows:
>WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
>WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
>1))
>Work item has a one-many relationship with wi_asgn (there may be many
>employees assigned to a single work item). If I am assigned to a work
>item, I need to replicate all the assignment records for the work item
>(including other employees' assignment records). But I don't want any
>assignments for work items that I'm not assigned to. So for example:
>wi_guidasgn_to_user_iddnld_merg_cd
>1me1
>1john1
>1jane1
>2john1
>3jane1
>If I merge, then I need to replicate the first three rows. If i
>filter on Work_item as specified above, then join wi_asgn to work_item
>on wi_guid, that should return the proper rows. This is different
>from what I was doing prior (the filter was on wi_asgn, which was then
>joined to work_item), so I'll test this and report back.
>
I retested after moving the filter criteria to the work_item table
WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1))
and received the same results (see my note describing the original
problem).
>I'll also try this simpler test and report back.
A simple filter clause (without the subquery)
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1)
works correctly. When the dnld_merge_cd is set to 0 and a merge is
executed, the row is deleted from the local (subscriber) database.
(Thus my conclusion that the subquery is causing the problem.)
However, this approach does not return all the records that I need.
[vbcol=seagreen]
|||Hi Kees,
Thanks for your update.
From your descriptions, I understood that
1.
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =1)
the WHERE clause works well, why didn't you use this clause only?
2.
WHERE [Work_Item].[WI_GUID]
IN
(SELECT WI_GUID
FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =1))
By using WHERE clauses above, could you make the right result back in Query
Analyzer? Could you make all other clause and condition right back from
Query Analyzer? I am not sure what dbo.fGetCurrentUserID() send back, but
based on my testing, the above could work well.
Could you make it without dbo.fGetCurrentUserID()?
Would you please send me some sample data that could reproduce the problem?
Could you ensure dbo.fGetCurrentUserID() send the right result and
condition for WHERE clause?
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know.
Sincerely yours,
Michael Cheng
Microsoft Online Support
************************************************** *********
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks.
|||Hi Kees,
I checked your replication logic, couldn't figure out why the replication
behaves like that.
So I setup a merge replication to test, using one table:
1. Create the merge table:
create table T3 (c1 int, c2 int, c3 char(8), c4 int)
insert T3 values (1, 1, 'one', 0)
2. Checked the filter statement:
Select * from T3 where c1 in (select c1 from T3 where c3 = 'one' and c4 =1)
=> 0 row returned
Select * from T3 where c3 = 'one' and c4 =1 => 0 row returned.
3. Setup a merge replication for this table (T3) with row filter:
SELECT <published_columns> FROM [dbo].[T3] WHERE c1 in (select c1 from T3
where c3 = 'one' and c4 = 1)
4. Run Snapshot and merge agents. Checked the subscriber table, no row was
copied, This is as expected, since no row satisfies the filter condition..
5. updated publisher:
update T3 set c4=1
6. Run merge agent, one row went to the sub, as expected. Now both pub and
sub has one row with c4 = 1
7. Updated subscriber:
update T3 set c4=0
8. Run merge agent. The row at the sub was removed and the row at pub was
updated. This is by design. At any time, as soon as a row becomes
dissatisfied to the filter condition, it will be removed from the
subscriber table.
After Step 6, if I run step 7, before run merge agent, make another update
statement:
update T3 set c1=0, c2=3 where c1=1
Then run merge agent, I see the row in subscriber was removed and the row
in publisher was updated.
In your case, your first action (below) should remove the row from the
subscriber, then you won't have a chance to do the other updates:
Action:
DNLD_MERG_CD is set to 0.
Merge is executed.
Result:
Merge code is 0 on both databases (expected)
Please test again. If confirmed, please let me know all the versions of
your publisher, subscriber and distributor (I am using 818 for all), and if
possible, send your table schemas and replication script to me for further
check.
Regards,
Lan Lewis-Bevan
MS SQL support
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Lan,
Thank you for looking into this problem. There's an extra wrinkle in
my scenario that could affect the result. My filter condition is on
another table. The filter condition excludes rows based on values in
the second table, yet because of the filter join, those excluded rows
are appropriately included in the replication. You may need to add
that second table to see the same results.
I posted my table defns and replication scripts to this newsgroup and
received a reply from Baisong Wei that they would try to duplicate the
error (see 5/18, appears as a separate thread in Agent Newsreader). I
have not heard back from them. I'd love to get this solved sooner,
but don't want to see you duplicating effort.
We have version 8.00.760 on our server and locally. I believe this is
sp3. Where do I obtain v8.18? It would be worth a retest on that
version.
Kees
@.@.version on publisher:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack
4)
@.@.version on subscriber:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Personal Edition on Windows NT 5.1 (Build 2600: Service Pack
1)
On Tue, 25 May 2004 01:36:27 GMT, lanlb@.online.microsoft.com (Lan
Lewis-Bevan [MS]) wrote:
>Hi Kees,
>I checked your replication logic, couldn't figure out why the replication
>behaves like that.
>So I setup a merge replication to test, using one table:
>1. Create the merge table:
>create table T3 (c1 int, c2 int, c3 char(8), c4 int)
>insert T3 values (1, 1, 'one', 0)
>2. Checked the filter statement:
>Select * from T3 where c1 in (select c1 from T3 where c3 = 'one' and c4 =1)
> => 0 row returned
>Select * from T3 where c3 = 'one' and c4 =1 => 0 row returned.
>3. Setup a merge replication for this table (T3) with row filter:
>SELECT <published_columns> FROM [dbo].[T3] WHERE c1 in (select c1 from T3
>where c3 = 'one' and c4 = 1)
>4. Run Snapshot and merge agents. Checked the subscriber table, no row was
>copied, This is as expected, since no row satisfies the filter condition..
>5. updated publisher:
>update T3 set c4=1
>6. Run merge agent, one row went to the sub, as expected. Now both pub and
>sub has one row with c4 = 1
>7. Updated subscriber:
>update T3 set c4=0
>8. Run merge agent. The row at the sub was removed and the row at pub was
>updated. This is by design. At any time, as soon as a row becomes
>dissatisfied to the filter condition, it will be removed from the
>subscriber table.
>After Step 6, if I run step 7, before run merge agent, make another update
>statement:
>update T3 set c1=0, c2=3 where c1=1
>Then run merge agent, I see the row in subscriber was removed and the row
>in publisher was updated.
>
>In your case, your first action (below) should remove the row from the
>subscriber, then you won't have a chance to do the other updates:
>Action:
>DNLD_MERG_CD is set to 0.
>Merge is executed.
>Result:
>Merge code is 0 on both databases (expected)
>
>Please test again. If confirmed, please let me know all the versions of
>your publisher, subscriber and distributor (I am using 818 for all), and if
>possible, send your table schemas and replication script to me for further
>check.
>Regards,
>
>Lan Lewis-Bevan
>MS SQL support
>This posting is provided "AS IS" with no warranties, and confers no rights.
anonymous clients. We use a filter on one table and joins to related
tables to determine what records to merge. There are two parts to the
filter, one is user, which merges only records assigned to the user
that is replicating. The second is a merge code, which is set to 0 or
1 and basically serves as a completion code: when the user is done
with the record, it is set to complete and is no longer included in
the merge.
The problem has to do with changes to the merge code. As long as it
is set to 1, replication occurs smoothly. After it is set to 0 and
merged so that client and server are 0, changes made to the client
records continue to be merged with the server until a change is made
to the table on the server. So, if there are two tables A & B, when
table A is changed on the server, local changes to A will no longer be
merged but local changes to B will continue to merge until a change is
made to B on the server. Since A & B are related tables, this is a
serious synchronization issue! It is as though a server change has to
be made to each table to force re-evaluation of the filter criteria
for that table, strange.
Here are the details of our setup:
There are 3 tables for which merge replication is defined on SQL
Server 2000 on NT:
1. WI_ASGN
wi_asgn_guid
wi_guid (fk to work_item constraint)
asgn_to_user_id
dnld_merg_cd
2. WORK_ITEM
wi_guid
office_id
3. WI_DETAIL
dtl_guid
wi_guid (fk to work_item constraint)
start_date
A row filter is defined on the WI_ASGN table: WHERE
[WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM
[dbo].[WI_ASGN] WHERE (ASGN_TO_USER_ID =
dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
fGetCurrentUserID is a user defined function which returns a char(8)
user_id.
Join filters are used to filter WORK_ITEM:
SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
[dbo].[WORK_ITEM] ON [WI_ASGN].[WI_GUID] =
[WORK_ITEM].[WI_GUID]
and WI_DETAIL:
SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
[dbo].[WI_DETAIL] ON [WI_ASGN].[WI_GUID] =
[WI_DETAIL].[WI_GUID]
We begin with DNLD_MERG_CD = 1 and merge replication running smoothly.
After the user has completed working on the assignment, the data no
longer should no longer replicate even if the user makes chagnes. We
reset the DNLD_MERG_CD to 0 so that the replication filter condition
would not be met.
After doing this, the problem occurs. The following steps were
executed to test the replication:
Action:
DNLD_MERG_CD is set to 0.
Merge is executed.
Result:
Merge code is 0 on both databases (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local changes are replicated to the Central database. (not expected
since merge filter condition is not met)
Action:
WORK_ITEM is updated on the Central database.
Merge is executed
Result:
The Central change is not replicated to the Local database. (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local change to WORK_ITEM is not replicated (expected, but different
result then the first local change)
Local change to WI_DETAIL is replicated to Central database (not
expected since merge filter condition is not met)
Action:
WI_DETAIL is updated on the Central database.
Merge is executed
Result:
The Central change is not replicated to the Local database. (expected)
Action:
WORK_ITEM and WI_DETAIL are updated on the Local database.
Merge is executed
Result:
Local changes ar not replicated (expected)
Why do the changes to the Local database tables continue to replicate
until the corresponding Central database table is modified?
Sorry for the length of this post, but it seemed necessary. Thanks
for your help.
Kees VanTilburg
VanTilburg Enterprises
Hi Kees,
There is something strange happening here.
Firstly, if a row meets your subset filter requirements it will be
replicated to the subscriber from the publisher. Then, subscriber DML on
that row will be replicated back to the publisher.
If, however, your subset filter excludes the row then the row will not
replicate to the subscriber in the first place. Now, in your case, the
row does at first match the filter's requirements so it is replicated to
the subscriber. But when you change the row data so that the row does
not match the filter anymore (we call that "moving out of partition")
the row at the subscriber should be deleted since it no longer belongs
in the subscriber's partition. Because your row (and all its dependent
rows) does not get removed from the subscriber, it leads me to believe
that something could be wrong with the subset filterclause.
Looking at your subset filterclause, the only thing that struck me as a
bit strange was the unnecessary double select. Could you try use the
following instead:
change:
WHERE [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN] WHERE
(ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
to:
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1)
There shouldn't be a reason to do the first IN selection since the
second WHERE clause is all you're interested in.
Also, you might try (for testing sake) remove the first requirement and
simply state WHERE DNLD_MERG_CD = 1 as your subset filterclause. See if
this works and then add fGetCurrentUserID() back again.
Hope this helps,
Reinout Hillmann
SQL Server Product Unit
This posting is provided "AS IS" with no warranties, and confers no rights.
kjvt wrote:
> We are doing merge replication between a central server and multiple
> anonymous clients. We use a filter on one table and joins to related
> tables to determine what records to merge. There are two parts to the
> filter, one is user, which merges only records assigned to the user
> that is replicating. The second is a merge code, which is set to 0 or
> 1 and basically serves as a completion code: when the user is done
> with the record, it is set to complete and is no longer included in
> the merge.
> The problem has to do with changes to the merge code. As long as it
> is set to 1, replication occurs smoothly. After it is set to 0 and
> merged so that client and server are 0, changes made to the client
> records continue to be merged with the server until a change is made
> to the table on the server. So, if there are two tables A & B, when
> table A is changed on the server, local changes to A will no longer be
> merged but local changes to B will continue to merge until a change is
> made to B on the server. Since A & B are related tables, this is a
> serious synchronization issue! It is as though a server change has to
> be made to each table to force re-evaluation of the filter criteria
> for that table, strange.
> Here are the details of our setup:
> There are 3 tables for which merge replication is defined on SQL
> Server 2000 on NT:
> 1. WI_ASGN
> wi_asgn_guid
> wi_guid (fk to work_item constraint)
> asgn_to_user_id
> dnld_merg_cd
> 2. WORK_ITEM
> wi_guid
> office_id
> 3. WI_DETAIL
> dtl_guid
> wi_guid (fk to work_item constraint)
> start_date
> A row filter is defined on the WI_ASGN table: WHERE
> [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM
> [dbo].[WI_ASGN] WHERE (ASGN_TO_USER_ID =
> dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
> fGetCurrentUserID is a user defined function which returns a char(8)
> user_id.
> Join filters are used to filter WORK_ITEM:
> SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
> [dbo].[WORK_ITEM] ON [WI_ASGN].[WI_GUID] =
> [WORK_ITEM].[WI_GUID]
> and WI_DETAIL:
> SELECT <published_columns> FROM [dbo].[WI_ASGN] INNER JOIN
> [dbo].[WI_DETAIL] ON [WI_ASGN].[WI_GUID] =
> [WI_DETAIL].[WI_GUID]
> We begin with DNLD_MERG_CD = 1 and merge replication running smoothly.
> After the user has completed working on the assignment, the data no
> longer should no longer replicate even if the user makes chagnes. We
> reset the DNLD_MERG_CD to 0 so that the replication filter condition
> would not be met.
> After doing this, the problem occurs. The following steps were
> executed to test the replication:
> Action:
> DNLD_MERG_CD is set to 0.
> Merge is executed.
> Result:
> Merge code is 0 on both databases (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local changes are replicated to the Central database. (not expected
> since merge filter condition is not met)
> Action:
> WORK_ITEM is updated on the Central database.
> Merge is executed
> Result:
> The Central change is not replicated to the Local database. (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local change to WORK_ITEM is not replicated (expected, but different
> result then the first local change)
> Local change to WI_DETAIL is replicated to Central database (not
> expected since merge filter condition is not met)
> Action:
> WI_DETAIL is updated on the Central database.
> Merge is executed
> Result:
> The Central change is not replicated to the Local database. (expected)
> Action:
> WORK_ITEM and WI_DETAIL are updated on the Local database.
> Merge is executed
> Result:
> Local changes ar not replicated (expected)
> Why do the changes to the Local database tables continue to replicate
> until the corresponding Central database table is modified?
> Sorry for the length of this post, but it seemed necessary. Thanks
> for your help.
> Kees VanTilburg
> VanTilburg Enterprises
>
|||I assume that your subscribers are runnig sql server ce.
Take a look at
http://support.microsoft.com/default...b;EN-US;315758
http://support.microsoft.com/default...b;EN-US;287651
http://support.microsoft.com/default...b;EN-US;827914
Marius
|||Thank you for your reply. No, the subscribers are running MSDE.
Kees
On Thu, 13 May 2004 11:25:32 +0300, "Marius Bucur"
<marius.bucur@.optima.ro.nospan> wrote:
>I assume that your subscribers are runnig sql server ce.
>Take a look at
>http://support.microsoft.com/default...b;EN-US;315758
>http://support.microsoft.com/default...b;EN-US;287651
>http://support.microsoft.com/default...b;EN-US;827914
>Marius
>
|||Reinout,
Thank you for your reply. Please see my comments below.
Kees
On Wed, 12 May 2004 18:02:06 -0700, "Reinout Hillmann [MS]"
<reinouth@.online.microsoft.com> wrote:
>Hi Kees,
>There is something strange happening here.
>Firstly, if a row meets your subset filter requirements it will be
>replicated to the subscriber from the publisher. Then, subscriber DML on
>that row will be replicated back to the publisher.
>If, however, your subset filter excludes the row then the row will not
>replicate to the subscriber in the first place. Now, in your case, the
>row does at first match the filter's requirements so it is replicated to
>the subscriber. But when you change the row data so that the row does
>not match the filter anymore (we call that "moving out of partition")
>the row at the subscriber should be deleted since it no longer belongs
>in the subscriber's partition. Because your row (and all its dependent
>rows) does not get removed from the subscriber, it leads me to believe
>that something could be wrong with the subset filterclause.
>Looking at your subset filterclause, the only thing that struck me as a
>bit strange was the unnecessary double select. Could you try use the
>following instead:
>change:
>WHERE [WI_ASGN].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN] WHERE
>(ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1))
>to:
>WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD = 1)
>There shouldn't be a reason to do the first IN selection since the
>second WHERE clause is all you're interested in.
There's another layer of complexity that necessitates the subquery.
However, I think it would be better to filter on the Work_Item table
as follows:
WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1))
Work item has a one-many relationship with wi_asgn (there may be many
employees assigned to a single work item). If I am assigned to a work
item, I need to replicate all the assignment records for the work item
(including other employees' assignment records). But I don't want any
assignments for work items that I'm not assigned to. So for example:
wi_guidasgn_to_user_iddnld_merg_cd
1me1
1john1
1jane1
2john1
3jane1
If I merge, then I need to replicate the first three rows. If i
filter on Work_item as specified above, then join wi_asgn to work_item
on wi_guid, that should return the proper rows. This is different
from what I was doing prior (the filter was on wi_asgn, which was then
joined to work_item), so I'll test this and report back.
>Also, you might try (for testing sake) remove the first requirement and
>simply state WHERE DNLD_MERG_CD = 1 as your subset filterclause. See if
>this works and then add fGetCurrentUserID() back again.
I'll also try this simpler test and report back.
>
>Hope this helps,
>Reinout Hillmann
>SQL Server Product Unit
|||Hi Kees,
I am just checking on your progress regarding you said you will show us
your report back. I wonder how the testing is going. If you encounter any
difficulty, please do not hesitate to let me know. Please post here and let
me know the status of your issue. Without your further information, it's
very hard for me to continue with the troubleshooting.
Looking forward to hearing from you soon.
Sincerely yours,
Michael Cheng
Microsoft Online Support
************************************************** *********
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks.
|||Michael,
Based on further testing, it appears to be the subquery in the filter
clause that causes the problem. Please see below for updates on my
test results that led to this conclusion.
How can I restructure the filter to eliminate the problem while still
meeting my requirement?
Thank you.
Kees
On Thu, 13 May 2004 17:09:59 -0500, kjvt <kjvt@.newsgroups.nospam>
wrote:
>Reinout,
>Thank you for your reply. Please see my comments below.
>Kees
>
>On Wed, 12 May 2004 18:02:06 -0700, "Reinout Hillmann [MS]"
><reinouth@.online.microsoft.com> wrote:
>
>There's another layer of complexity that necessitates the subquery.
>However, I think it would be better to filter on the Work_Item table
>as follows:
>WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
>WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
>1))
>Work item has a one-many relationship with wi_asgn (there may be many
>employees assigned to a single work item). If I am assigned to a work
>item, I need to replicate all the assignment records for the work item
>(including other employees' assignment records). But I don't want any
>assignments for work items that I'm not assigned to. So for example:
>wi_guidasgn_to_user_iddnld_merg_cd
>1me1
>1john1
>1jane1
>2john1
>3jane1
>If I merge, then I need to replicate the first three rows. If i
>filter on Work_item as specified above, then join wi_asgn to work_item
>on wi_guid, that should return the proper rows. This is different
>from what I was doing prior (the filter was on wi_asgn, which was then
>joined to work_item), so I'll test this and report back.
>
I retested after moving the filter criteria to the work_item table
WHERE [Work_Item].[WI_GUID] IN (SELECT WI_GUID FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1))
and received the same results (see my note describing the original
problem).
>I'll also try this simpler test and report back.
A simple filter clause (without the subquery)
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =
1)
works correctly. When the dnld_merge_cd is set to 0 and a merge is
executed, the row is deleted from the local (subscriber) database.
(Thus my conclusion that the subquery is causing the problem.)
However, this approach does not return all the records that I need.
[vbcol=seagreen]
|||Hi Kees,
Thanks for your update.
From your descriptions, I understood that
1.
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =1)
the WHERE clause works well, why didn't you use this clause only?
2.
WHERE [Work_Item].[WI_GUID]
IN
(SELECT WI_GUID
FROM [dbo].[WI_ASGN]
WHERE (ASGN_TO_USER_ID = dbo.fGetCurrentUserID()) and (DNLD_MERG_CD =1))
By using WHERE clauses above, could you make the right result back in Query
Analyzer? Could you make all other clause and condition right back from
Query Analyzer? I am not sure what dbo.fGetCurrentUserID() send back, but
based on my testing, the above could work well.
Could you make it without dbo.fGetCurrentUserID()?
Would you please send me some sample data that could reproduce the problem?
Could you ensure dbo.fGetCurrentUserID() send the right result and
condition for WHERE clause?
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know.
Sincerely yours,
Michael Cheng
Microsoft Online Support
************************************************** *********
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks.
|||Hi Kees,
I checked your replication logic, couldn't figure out why the replication
behaves like that.
So I setup a merge replication to test, using one table:
1. Create the merge table:
create table T3 (c1 int, c2 int, c3 char(8), c4 int)
insert T3 values (1, 1, 'one', 0)
2. Checked the filter statement:
Select * from T3 where c1 in (select c1 from T3 where c3 = 'one' and c4 =1)
=> 0 row returned
Select * from T3 where c3 = 'one' and c4 =1 => 0 row returned.
3. Setup a merge replication for this table (T3) with row filter:
SELECT <published_columns> FROM [dbo].[T3] WHERE c1 in (select c1 from T3
where c3 = 'one' and c4 = 1)
4. Run Snapshot and merge agents. Checked the subscriber table, no row was
copied, This is as expected, since no row satisfies the filter condition..
5. updated publisher:
update T3 set c4=1
6. Run merge agent, one row went to the sub, as expected. Now both pub and
sub has one row with c4 = 1
7. Updated subscriber:
update T3 set c4=0
8. Run merge agent. The row at the sub was removed and the row at pub was
updated. This is by design. At any time, as soon as a row becomes
dissatisfied to the filter condition, it will be removed from the
subscriber table.
After Step 6, if I run step 7, before run merge agent, make another update
statement:
update T3 set c1=0, c2=3 where c1=1
Then run merge agent, I see the row in subscriber was removed and the row
in publisher was updated.
In your case, your first action (below) should remove the row from the
subscriber, then you won't have a chance to do the other updates:
Action:
DNLD_MERG_CD is set to 0.
Merge is executed.
Result:
Merge code is 0 on both databases (expected)
Please test again. If confirmed, please let me know all the versions of
your publisher, subscriber and distributor (I am using 818 for all), and if
possible, send your table schemas and replication script to me for further
check.
Regards,
Lan Lewis-Bevan
MS SQL support
This posting is provided "AS IS" with no warranties, and confers no rights.
|||Lan,
Thank you for looking into this problem. There's an extra wrinkle in
my scenario that could affect the result. My filter condition is on
another table. The filter condition excludes rows based on values in
the second table, yet because of the filter join, those excluded rows
are appropriately included in the replication. You may need to add
that second table to see the same results.
I posted my table defns and replication scripts to this newsgroup and
received a reply from Baisong Wei that they would try to duplicate the
error (see 5/18, appears as a separate thread in Agent Newsreader). I
have not heard back from them. I'd love to get this solved sooner,
but don't want to see you duplicating effort.
We have version 8.00.760 on our server and locally. I believe this is
sp3. Where do I obtain v8.18? It would be worth a retest on that
version.
Kees
@.@.version on publisher:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack
4)
@.@.version on subscriber:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Personal Edition on Windows NT 5.1 (Build 2600: Service Pack
1)
On Tue, 25 May 2004 01:36:27 GMT, lanlb@.online.microsoft.com (Lan
Lewis-Bevan [MS]) wrote:
>Hi Kees,
>I checked your replication logic, couldn't figure out why the replication
>behaves like that.
>So I setup a merge replication to test, using one table:
>1. Create the merge table:
>create table T3 (c1 int, c2 int, c3 char(8), c4 int)
>insert T3 values (1, 1, 'one', 0)
>2. Checked the filter statement:
>Select * from T3 where c1 in (select c1 from T3 where c3 = 'one' and c4 =1)
> => 0 row returned
>Select * from T3 where c3 = 'one' and c4 =1 => 0 row returned.
>3. Setup a merge replication for this table (T3) with row filter:
>SELECT <published_columns> FROM [dbo].[T3] WHERE c1 in (select c1 from T3
>where c3 = 'one' and c4 = 1)
>4. Run Snapshot and merge agents. Checked the subscriber table, no row was
>copied, This is as expected, since no row satisfies the filter condition..
>5. updated publisher:
>update T3 set c4=1
>6. Run merge agent, one row went to the sub, as expected. Now both pub and
>sub has one row with c4 = 1
>7. Updated subscriber:
>update T3 set c4=0
>8. Run merge agent. The row at the sub was removed and the row at pub was
>updated. This is by design. At any time, as soon as a row becomes
>dissatisfied to the filter condition, it will be removed from the
>subscriber table.
>After Step 6, if I run step 7, before run merge agent, make another update
>statement:
>update T3 set c1=0, c2=3 where c1=1
>Then run merge agent, I see the row in subscriber was removed and the row
>in publisher was updated.
>
>In your case, your first action (below) should remove the row from the
>subscriber, then you won't have a chance to do the other updates:
>Action:
>DNLD_MERG_CD is set to 0.
>Merge is executed.
>Result:
>Merge code is 0 on both databases (expected)
>
>Please test again. If confirmed, please let me know all the versions of
>your publisher, subscriber and distributor (I am using 818 for all), and if
>possible, send your table schemas and replication script to me for further
>check.
>Regards,
>
>Lan Lewis-Bevan
>MS SQL support
>This posting is provided "AS IS" with no warranties, and confers no rights.
Merge Dynamic filter problem
Hi!
I'm a merge newbie and have a couple of questions. I'm about to setup a merge replication with Sql Server 2005 and Sql Server CE as a subscriber. Situation is like this, we have 10 service technicians using pda.
I want to each pda user have their own data. What I understand I need to use dynamic filter and SUSER_NAME()? Do I need to create a "translation" table to map my system's UserId against SUSER_NAME? How have you solved this problem?
/Magnus
Hello magnus,
One easy approach is to have a column in the table for filtering purpose.
Please take a look on sp_addmergearticle (Transact-SQL) , from http://msdn2.microsoft.com/en-us/library/ms174329.aspx.
[ @.subset_filterclause = ] 'subset_filterclause'
Is a WHERE clause specifying the horizontal filtering of a table article without the word WHERE included. subset_filterclause is of nvarchar(1000), with a default of an empty string.
Important:
For performance reasons, we recommended that you not apply functions to column names in parameterized row filter clauses, such as LEFT([MyColumn]) = SUSER_SNAME(). If you use HOST_NAME in a filter clause and override the HOST_NAME value, you might have to convert data types by using CONVERT. For more information about best practices for this case, see the section "Overriding the HOST_NAME() Value" in Parameterized Row Filters.
Parameterized Row Filters - http://msdn2.microsoft.com/en-us/library/ms152478.aspx.
and
[ @.partition_options = ] partition_options
Defines the way in which data in the article is partitioned, which enables performance optimizations when all rows belong in only one partition or in only one subscription. partition_options is tinyint, and can be one of the following values.
Value Description
0 (default)
The filtering for the article either is static or does not yield a unique subset of data for each partition, that is, an "overlapping" partition.
1
The partitions are overlapping, and data manipulation language (DML) updates made at the Subscriber cannot change the partition to which a row belongs.
2
The filtering for the article yields non-overlapping partitions, but multiple Subscribers can receive the same partition.
3
The filtering for the article yields non-overlapping partitions that are unique for each subscription.
Merge Documentation
I've been reading the documentation on merge replication in BOL and I feel
like it's too fragmented. Can anyone recommend links/books that explain it
clearly? (And no I don't mind someone plugging their own material.)
I have written a book which is being edited. I am not sure when it will be
out, but soon.
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
"CLM" <CLM@.discussions.microsoft.com> wrote in message
news:84EB200B-CFC1-420F-9813-4E9671B9012D@.microsoft.com...
> I've been reading the documentation on merge replication in BOL and I feel
> like it's too fragmented. Can anyone recommend links/books that explain
> it
> clearly? (And no I don't mind someone plugging their own material.)
sql
like it's too fragmented. Can anyone recommend links/books that explain it
clearly? (And no I don't mind someone plugging their own material.)
I have written a book which is being edited. I am not sure when it will be
out, but soon.
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
"CLM" <CLM@.discussions.microsoft.com> wrote in message
news:84EB200B-CFC1-420F-9813-4E9671B9012D@.microsoft.com...
> I've been reading the documentation on merge replication in BOL and I feel
> like it's too fragmented. Can anyone recommend links/books that explain
> it
> clearly? (And no I don't mind someone plugging their own material.)
sql
Merge data in SQL Server databases
I have two databases with identical tables structures. I need to merge the data in both databases without implementing merge replication. Can someone tell me what script to run that will compare the data in those tables? First I know the script has to search for data that doesn't exist in one table, the copy that over from the table that has extra rows. Thanks
AmmieNot sure how to help you unless you want to write a stored proc to do it.
Merge Conflicts and Referential Integrity
I am trying to set up merge replication between a
publisher and 1 subscriber. I have selected the "include
declared referential intetegrity" option. I have
added "Not for Replication" to all of my triggers.
Occasionally, I end up with replication conflicts (either
at the subscriber or the publisher) saying that a row
could not be inserted because it violates a referential
constraint.
I don't understand why this is happening. According to
the online help, the declared referential integrity option
should ensure that articles are processed in order based
on the relationships (ie. inserting parent rows before
related child rows). The replication works most of the
time but I can usually recreate the problem by doing
multiple inserts at both the subscriber and publisher in a
short period of time. I have the replication schedule set
to 1 minute for my testing.
This causes a major issue for me because I can not resolve
the data even though the referential constraint would no
longer apply (ie. the row that it was complaining about is
there now). I am using an identity column and Replication
automatically adds constraints at the publisher and the
subscriber on this field. Therefore, it will not allow me
to resolve the conflict (ie. by adding the row now) since
its id is outside of the identity range.
After the snap shot was applied, I ensured that all of the
referential relationships, indexes, etc were copied over
and are still active. I have the latest service pack (ie.
SP3).
Any help would be greatly apreciated. I have included
part of my replication script to show how the articles are
set up.
exec sp_addmergearticle @.publication = N'BESMgmt',
@.article = N'UserComponentMap', @.source_owner = N'dbo',
@.source_object = N'UserComponentMap', @.type = N'table',
@.description = null, @.column_tracking = N'true',
@.pre_creation_cmd = N'drop', @.creation_script = null,
@.schema_option = 0x000000000000CFF1, @.article_resolver =
null, @.subset_filterclause = null, @.vertical_partition =
N'false', @.destination_owner = N'dbo',
@.auto_identity_range = N'true', @.pub_identity_range = 100,
@.identity_range = 100, @.threshold = 80,
@.verify_resolver_signature = 0,
@.allow_interactive_resolver = N'false',
@.fast_multicol_updateproc = N'true', @.check_permissions = 0
GO
exec sp_addmergearticle @.publication = N'BESMgmt',
@.article = N'UserComponentAffinity', @.source_owner =
N'dbo', @.source_object = N'UserComponentAffinity', @.type =
N'table', @.description = null, @.column_tracking = N'true',
@.pre_creation_cmd = N'drop', @.creation_script = null,
@.schema_option = 0x000000000000CFF1, @.article_resolver =
null, @.subset_filterclause = null, @.vertical_partition =
N'false', @.destination_owner = N'dbo',
@.auto_identity_range = N'true', @.pub_identity_range = 100,
@.identity_range = 100, @.threshold = 80,
@.verify_resolver_signature = 0,
@.allow_interactive_resolver = N'false',
@.fast_multicol_updateproc = N'true', @.check_permissions = 0
GO
This problem is related to how changes are processed, sometimes child
records are processed before their parents are. The way to get around this
is to set the number of generations processed in a batch, preferrably to
2000.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim" <jmisasi@.rim.com> wrote in message
news:036a01c4abdc$648948d0$a301280a@.phx.gbl...
> I am trying to set up merge replication between a
> publisher and 1 subscriber. I have selected the "include
> declared referential intetegrity" option. I have
> added "Not for Replication" to all of my triggers.
> Occasionally, I end up with replication conflicts (either
> at the subscriber or the publisher) saying that a row
> could not be inserted because it violates a referential
> constraint.
> I don't understand why this is happening. According to
> the online help, the declared referential integrity option
> should ensure that articles are processed in order based
> on the relationships (ie. inserting parent rows before
> related child rows). The replication works most of the
> time but I can usually recreate the problem by doing
> multiple inserts at both the subscriber and publisher in a
> short period of time. I have the replication schedule set
> to 1 minute for my testing.
> This causes a major issue for me because I can not resolve
> the data even though the referential constraint would no
> longer apply (ie. the row that it was complaining about is
> there now). I am using an identity column and Replication
> automatically adds constraints at the publisher and the
> subscriber on this field. Therefore, it will not allow me
> to resolve the conflict (ie. by adding the row now) since
> its id is outside of the identity range.
> After the snap shot was applied, I ensured that all of the
> referential relationships, indexes, etc were copied over
> and are still active. I have the latest service pack (ie.
> SP3).
> Any help would be greatly apreciated. I have included
> part of my replication script to show how the articles are
> set up.
>
> exec sp_addmergearticle @.publication = N'BESMgmt',
> @.article = N'UserComponentMap', @.source_owner = N'dbo',
> @.source_object = N'UserComponentMap', @.type = N'table',
> @.description = null, @.column_tracking = N'true',
> @.pre_creation_cmd = N'drop', @.creation_script = null,
> @.schema_option = 0x000000000000CFF1, @.article_resolver =
> null, @.subset_filterclause = null, @.vertical_partition =
> N'false', @.destination_owner = N'dbo',
> @.auto_identity_range = N'true', @.pub_identity_range = 100,
> @.identity_range = 100, @.threshold = 80,
> @.verify_resolver_signature = 0,
> @.allow_interactive_resolver = N'false',
> @.fast_multicol_updateproc = N'true', @.check_permissions = 0
> GO
> exec sp_addmergearticle @.publication = N'BESMgmt',
> @.article = N'UserComponentAffinity', @.source_owner =
> N'dbo', @.source_object = N'UserComponentAffinity', @.type =
> N'table', @.description = null, @.column_tracking = N'true',
> @.pre_creation_cmd = N'drop', @.creation_script = null,
> @.schema_option = 0x000000000000CFF1, @.article_resolver =
> null, @.subset_filterclause = null, @.vertical_partition =
> N'false', @.destination_owner = N'dbo',
> @.auto_identity_range = N'true', @.pub_identity_range = 100,
> @.identity_range = 100, @.threshold = 80,
> @.verify_resolver_signature = 0,
> @.allow_interactive_resolver = N'false',
> @.fast_multicol_updateproc = N'true', @.check_permissions = 0
> GO
|||Jim,
BTW this is not an issue in SQL 2005, where PKs are processed before PKs
without any extra work on behalf of the programmer.
Rgds,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||I am new to replication and SQL Server for that matter.
So, how do I increase the number of generations processed
in a batch.
I am guessing I need to set this somewhere in my agent
profile. I am using the Default Agent Profile which has
the following parameters and values:
BcpBatchSize 10000
ChangesPerHistory 100
DestThreads 4
DownloadGenerationsPerBatch 100
DownloadReadChangesPerBatch 100
DownloadWriteChangesPerBatch 100
FastRowCount 1
HistoryVerboseLevel 1
KeepAliveMessageInterval 300
Login Timeout 15
MaxDownloadChanges 0
MaxUploadChanges 0
MetaDataRetentionCleanup 1
NumDeadlockRetries 5
PollingInterval 60
QueryTimeout 300
SrcThreads 3
StartQueueTimeout 0
UploadGenerationsPerBatch 100
UploadReadGenerationsPerBatch 100
UploadWriteGenerationsPerBatch 100
Validate 0
ValidateInterval 60
Do I set the Upload and Download Generations to 2000? Do
I set the Read and Write values as well? It looks like I
will have to create my own profile which is fine, but am I
on the right track?
Thank you,
Jim
>--Original Message--
>This problem is related to how changes are processed,
sometimes child
>records are processed before their parents are. The way
to get around this
>is to set the number of generations processed in a batch,
preferrably to[vbcol=seagreen]
>2000.
>
>--
>Hilary Cotter
>Looking for a SQL Server replication book?
>http://www.nwsu.com/0974973602.html
>
>"Jim" <jmisasi@.rim.com> wrote in message
>news:036a01c4abdc$648948d0$a301280a@.phx.gbl...
the "include[vbcol=seagreen]
(either[vbcol=seagreen]
option[vbcol=seagreen]
in a[vbcol=seagreen]
set[vbcol=seagreen]
resolve[vbcol=seagreen]
is[vbcol=seagreen]
Replication[vbcol=seagreen]
me[vbcol=seagreen]
since[vbcol=seagreen]
the[vbcol=seagreen]
(ie.[vbcol=seagreen]
are[vbcol=seagreen]
100,[vbcol=seagreen]
= 0[vbcol=seagreen]
@.type =[vbcol=seagreen]
N'true',[vbcol=seagreen]
100,[vbcol=seagreen]
= 0
>
>.
>
|||Jim,
Increase the -UploadGenerationsPerBatch and -
DownloadGenerationsPerBatch Merge Agent parameters to
their maximum value of 2000, which virtually eliminates
the possibility of processing a child article's
generation in a batch separate from the parent article's
generation.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Believe it or not, I am still getting conflicts (although
not as many). Is there anything else I can do?
Jim
>--Original Message--
>Jim,
>Increase the -UploadGenerationsPerBatch and -
>DownloadGenerationsPerBatch Merge Agent parameters to
>their maximum value of 2000, which virtually eliminates
>the possibility of processing a child article's
>generation in a batch separate from the parent article's
>generation.
>HTH,
>Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>.
>
|||I suppose you could have 2 separate publications - one for the parent and
one for the child, and run them as parent then child yourself. However as
far as I understand this shouldn't be necessary unless you have an enormous
number of records before synchronization. How many records do you have?
Could you synchronize more frequently perhaps to avoid a backlog?
Rgds,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Jim,
the order of processing is not so straightforward (unlike
SQL 5005). Have a look at this article to better
understand the process:
http://support.microsoft.com/default.aspx?scid=kb;
[LN];307356.
You might try setting the FKs to NOT FOR REPLICATION so
this bypasses the constraint checks.
HTH,
Paul Ibison
>.
>
publisher and 1 subscriber. I have selected the "include
declared referential intetegrity" option. I have
added "Not for Replication" to all of my triggers.
Occasionally, I end up with replication conflicts (either
at the subscriber or the publisher) saying that a row
could not be inserted because it violates a referential
constraint.
I don't understand why this is happening. According to
the online help, the declared referential integrity option
should ensure that articles are processed in order based
on the relationships (ie. inserting parent rows before
related child rows). The replication works most of the
time but I can usually recreate the problem by doing
multiple inserts at both the subscriber and publisher in a
short period of time. I have the replication schedule set
to 1 minute for my testing.
This causes a major issue for me because I can not resolve
the data even though the referential constraint would no
longer apply (ie. the row that it was complaining about is
there now). I am using an identity column and Replication
automatically adds constraints at the publisher and the
subscriber on this field. Therefore, it will not allow me
to resolve the conflict (ie. by adding the row now) since
its id is outside of the identity range.
After the snap shot was applied, I ensured that all of the
referential relationships, indexes, etc were copied over
and are still active. I have the latest service pack (ie.
SP3).
Any help would be greatly apreciated. I have included
part of my replication script to show how the articles are
set up.
exec sp_addmergearticle @.publication = N'BESMgmt',
@.article = N'UserComponentMap', @.source_owner = N'dbo',
@.source_object = N'UserComponentMap', @.type = N'table',
@.description = null, @.column_tracking = N'true',
@.pre_creation_cmd = N'drop', @.creation_script = null,
@.schema_option = 0x000000000000CFF1, @.article_resolver =
null, @.subset_filterclause = null, @.vertical_partition =
N'false', @.destination_owner = N'dbo',
@.auto_identity_range = N'true', @.pub_identity_range = 100,
@.identity_range = 100, @.threshold = 80,
@.verify_resolver_signature = 0,
@.allow_interactive_resolver = N'false',
@.fast_multicol_updateproc = N'true', @.check_permissions = 0
GO
exec sp_addmergearticle @.publication = N'BESMgmt',
@.article = N'UserComponentAffinity', @.source_owner =
N'dbo', @.source_object = N'UserComponentAffinity', @.type =
N'table', @.description = null, @.column_tracking = N'true',
@.pre_creation_cmd = N'drop', @.creation_script = null,
@.schema_option = 0x000000000000CFF1, @.article_resolver =
null, @.subset_filterclause = null, @.vertical_partition =
N'false', @.destination_owner = N'dbo',
@.auto_identity_range = N'true', @.pub_identity_range = 100,
@.identity_range = 100, @.threshold = 80,
@.verify_resolver_signature = 0,
@.allow_interactive_resolver = N'false',
@.fast_multicol_updateproc = N'true', @.check_permissions = 0
GO
This problem is related to how changes are processed, sometimes child
records are processed before their parents are. The way to get around this
is to set the number of generations processed in a batch, preferrably to
2000.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim" <jmisasi@.rim.com> wrote in message
news:036a01c4abdc$648948d0$a301280a@.phx.gbl...
> I am trying to set up merge replication between a
> publisher and 1 subscriber. I have selected the "include
> declared referential intetegrity" option. I have
> added "Not for Replication" to all of my triggers.
> Occasionally, I end up with replication conflicts (either
> at the subscriber or the publisher) saying that a row
> could not be inserted because it violates a referential
> constraint.
> I don't understand why this is happening. According to
> the online help, the declared referential integrity option
> should ensure that articles are processed in order based
> on the relationships (ie. inserting parent rows before
> related child rows). The replication works most of the
> time but I can usually recreate the problem by doing
> multiple inserts at both the subscriber and publisher in a
> short period of time. I have the replication schedule set
> to 1 minute for my testing.
> This causes a major issue for me because I can not resolve
> the data even though the referential constraint would no
> longer apply (ie. the row that it was complaining about is
> there now). I am using an identity column and Replication
> automatically adds constraints at the publisher and the
> subscriber on this field. Therefore, it will not allow me
> to resolve the conflict (ie. by adding the row now) since
> its id is outside of the identity range.
> After the snap shot was applied, I ensured that all of the
> referential relationships, indexes, etc were copied over
> and are still active. I have the latest service pack (ie.
> SP3).
> Any help would be greatly apreciated. I have included
> part of my replication script to show how the articles are
> set up.
>
> exec sp_addmergearticle @.publication = N'BESMgmt',
> @.article = N'UserComponentMap', @.source_owner = N'dbo',
> @.source_object = N'UserComponentMap', @.type = N'table',
> @.description = null, @.column_tracking = N'true',
> @.pre_creation_cmd = N'drop', @.creation_script = null,
> @.schema_option = 0x000000000000CFF1, @.article_resolver =
> null, @.subset_filterclause = null, @.vertical_partition =
> N'false', @.destination_owner = N'dbo',
> @.auto_identity_range = N'true', @.pub_identity_range = 100,
> @.identity_range = 100, @.threshold = 80,
> @.verify_resolver_signature = 0,
> @.allow_interactive_resolver = N'false',
> @.fast_multicol_updateproc = N'true', @.check_permissions = 0
> GO
> exec sp_addmergearticle @.publication = N'BESMgmt',
> @.article = N'UserComponentAffinity', @.source_owner =
> N'dbo', @.source_object = N'UserComponentAffinity', @.type =
> N'table', @.description = null, @.column_tracking = N'true',
> @.pre_creation_cmd = N'drop', @.creation_script = null,
> @.schema_option = 0x000000000000CFF1, @.article_resolver =
> null, @.subset_filterclause = null, @.vertical_partition =
> N'false', @.destination_owner = N'dbo',
> @.auto_identity_range = N'true', @.pub_identity_range = 100,
> @.identity_range = 100, @.threshold = 80,
> @.verify_resolver_signature = 0,
> @.allow_interactive_resolver = N'false',
> @.fast_multicol_updateproc = N'true', @.check_permissions = 0
> GO
|||Jim,
BTW this is not an issue in SQL 2005, where PKs are processed before PKs
without any extra work on behalf of the programmer.
Rgds,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||I am new to replication and SQL Server for that matter.
So, how do I increase the number of generations processed
in a batch.
I am guessing I need to set this somewhere in my agent
profile. I am using the Default Agent Profile which has
the following parameters and values:
BcpBatchSize 10000
ChangesPerHistory 100
DestThreads 4
DownloadGenerationsPerBatch 100
DownloadReadChangesPerBatch 100
DownloadWriteChangesPerBatch 100
FastRowCount 1
HistoryVerboseLevel 1
KeepAliveMessageInterval 300
Login Timeout 15
MaxDownloadChanges 0
MaxUploadChanges 0
MetaDataRetentionCleanup 1
NumDeadlockRetries 5
PollingInterval 60
QueryTimeout 300
SrcThreads 3
StartQueueTimeout 0
UploadGenerationsPerBatch 100
UploadReadGenerationsPerBatch 100
UploadWriteGenerationsPerBatch 100
Validate 0
ValidateInterval 60
Do I set the Upload and Download Generations to 2000? Do
I set the Read and Write values as well? It looks like I
will have to create my own profile which is fine, but am I
on the right track?
Thank you,
Jim
>--Original Message--
>This problem is related to how changes are processed,
sometimes child
>records are processed before their parents are. The way
to get around this
>is to set the number of generations processed in a batch,
preferrably to[vbcol=seagreen]
>2000.
>
>--
>Hilary Cotter
>Looking for a SQL Server replication book?
>http://www.nwsu.com/0974973602.html
>
>"Jim" <jmisasi@.rim.com> wrote in message
>news:036a01c4abdc$648948d0$a301280a@.phx.gbl...
the "include[vbcol=seagreen]
(either[vbcol=seagreen]
option[vbcol=seagreen]
in a[vbcol=seagreen]
set[vbcol=seagreen]
resolve[vbcol=seagreen]
is[vbcol=seagreen]
Replication[vbcol=seagreen]
me[vbcol=seagreen]
since[vbcol=seagreen]
the[vbcol=seagreen]
(ie.[vbcol=seagreen]
are[vbcol=seagreen]
100,[vbcol=seagreen]
= 0[vbcol=seagreen]
@.type =[vbcol=seagreen]
N'true',[vbcol=seagreen]
100,[vbcol=seagreen]
= 0
>
>.
>
|||Jim,
Increase the -UploadGenerationsPerBatch and -
DownloadGenerationsPerBatch Merge Agent parameters to
their maximum value of 2000, which virtually eliminates
the possibility of processing a child article's
generation in a batch separate from the parent article's
generation.
HTH,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Believe it or not, I am still getting conflicts (although
not as many). Is there anything else I can do?
Jim
>--Original Message--
>Jim,
>Increase the -UploadGenerationsPerBatch and -
>DownloadGenerationsPerBatch Merge Agent parameters to
>their maximum value of 2000, which virtually eliminates
>the possibility of processing a child article's
>generation in a batch separate from the parent article's
>generation.
>HTH,
>Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>.
>
|||I suppose you could have 2 separate publications - one for the parent and
one for the child, and run them as parent then child yourself. However as
far as I understand this shouldn't be necessary unless you have an enormous
number of records before synchronization. How many records do you have?
Could you synchronize more frequently perhaps to avoid a backlog?
Rgds,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Jim,
the order of processing is not so straightforward (unlike
SQL 5005). Have a look at this article to better
understand the process:
http://support.microsoft.com/default.aspx?scid=kb;
[LN];307356.
You might try setting the FKs to NOT FOR REPLICATION so
this bypasses the constraint checks.
HTH,
Paul Ibison
>.
>
merge client failing
Hi
We have sql2005 merge replication happening - it is using replisapi.dll over the net.
One of the clients has been working fine, until yesterday afternoon - we are running sql2005 sp1 at subscriber and distributer
The message is as follows....
Please help !
Error messages:
The process could not read the request message due to OS error 10054. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147014842)
Get help: http://help/MSSQL_REPL-2147014842
The format of a message during Web synchronization was invalid. Ensure that replication components are properly configured at the Web server. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147199374)
Get help: http://help/MSSQL_REPL-2147199374
The subscription to publication 'yarraman main' could not be verified. Ensure that all Merge Agent command line parameters are specified correctly and that the subscription is correctly configured. If the Publisher no longer has information about this subscription, drop and recreate the subscription. (Source: MSSQL_REPL, Error number: MSSQL_REPL-2147201019)
Get help: http://help/MSSQL_REPL-2147201019
OS error 10054 is "An existing connection was forcibly closed by the remote host.", which could mean security or network issue. Could this be the case?
merge cannot be performed
I have an error in our replication server. The error reads, "The merge
process could not perform retention-based meta data cleanup in Database
"ourdatabasename".
The detail portion of the errors indicates that "The index entry for row ID
WAS NOT FOUND IN INDEX ID 2, of table 421576540 in database
"ourdatabasename".
does anybody know what this is and how we can fix it.
tx
run a DBCC reindex. You may have to drop the subscription to do this.
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
"tlee" <tlee@.lang.com> wrote in message
news:OVOpurdHFHA.3376@.TK2MSFTNGP14.phx.gbl...
> I have an error in our replication server. The error reads, "The merge
> process could not perform retention-based meta data cleanup in Database
> "ourdatabasename".
> The detail portion of the errors indicates that "The index entry for row
ID
> WAS NOT FOUND IN INDEX ID 2, of table 421576540 in database
> "ourdatabasename".
> does anybody know what this is and how we can fix it.
> tx
>
sql
process could not perform retention-based meta data cleanup in Database
"ourdatabasename".
The detail portion of the errors indicates that "The index entry for row ID
WAS NOT FOUND IN INDEX ID 2, of table 421576540 in database
"ourdatabasename".
does anybody know what this is and how we can fix it.
tx
run a DBCC reindex. You may have to drop the subscription to do this.
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
"tlee" <tlee@.lang.com> wrote in message
news:OVOpurdHFHA.3376@.TK2MSFTNGP14.phx.gbl...
> I have an error in our replication server. The error reads, "The merge
> process could not perform retention-based meta data cleanup in Database
> "ourdatabasename".
> The detail portion of the errors indicates that "The index entry for row
ID
> WAS NOT FOUND IN INDEX ID 2, of table 421576540 in database
> "ourdatabasename".
> does anybody know what this is and how we can fix it.
> tx
>
sql
Merge Application Conflict Log
Is it possible to write conflict sql in some persistent table.
I know that they a writen in merge replication tables and can be viewed via
conflict viewer
but they a lost after the snapshot run.
I need to keep them forever.
Probably i can write custom resolver who will do thta - but is there any
'out of the box' solution?
Grigoris - as far as I know there isn't any out-of-the-box solution but
perhaps the easiest solution would be to regularly poll the conflict table
and to write the values into an audit table.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Use perfmon to watch the conflicts per second counter of SQL
Server:Replication Merge and run a job which reads the conflict tables when
conflicts occur.
You can also use sp_helpmergearticleconflicts and run it on the publisher
and subscriber. It will return a list of articles with conflicts and you can
then manually or programmatically retrieve them.
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
"Grigoris Tsolakidis" <gcholakidis@.spam_remove.hotmail.com> wrote in message
news:%237acphUZHHA.588@.TK2MSFTNGP06.phx.gbl...
> Is it possible to write conflict sql in some persistent table.
> I know that they a writen in merge replication tables and can be viewed
> via conflict viewer
> but they a lost after the snapshot run.
> I need to keep them forever.
> Probably i can write custom resolver who will do thta - but is there any
> 'out of the box' solution?
>
I know that they a writen in merge replication tables and can be viewed via
conflict viewer
but they a lost after the snapshot run.
I need to keep them forever.
Probably i can write custom resolver who will do thta - but is there any
'out of the box' solution?
Grigoris - as far as I know there isn't any out-of-the-box solution but
perhaps the easiest solution would be to regularly poll the conflict table
and to write the values into an audit table.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||Use perfmon to watch the conflicts per second counter of SQL
Server:Replication Merge and run a job which reads the conflict tables when
conflicts occur.
You can also use sp_helpmergearticleconflicts and run it on the publisher
and subscriber. It will return a list of articles with conflicts and you can
then manually or programmatically retrieve them.
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
"Grigoris Tsolakidis" <gcholakidis@.spam_remove.hotmail.com> wrote in message
news:%237acphUZHHA.588@.TK2MSFTNGP06.phx.gbl...
> Is it possible to write conflict sql in some persistent table.
> I know that they a writen in merge replication tables and can be viewed
> via conflict viewer
> but they a lost after the snapshot run.
> I need to keep them forever.
> Probably i can write custom resolver who will do thta - but is there any
> 'out of the box' solution?
>
Subscribe to:
Posts (Atom)