Best replication strategy suggestion?

We are in the process of determining a sql db replication strategy. We're
looking at merge replication or log shipping but are in need of more
informed suggestions. It seems like merge replication would be ideal except
i've read that in the event one of the sql servers is unavailable the other
stops accepting data until some elaborate reconfiguration is made. It also
appears that merge replication requires modifying the app tables - not sure
if the vendor will support. Log shipping seems to allow for an easier
reconfiguration of the secondary in the event of a publisher failure but
it's still not very automatic. I've listed the SLA and specifications. Any
ideas or experiences would be most appreciated.
1.) We have two locations and must have a sql server in each location.
2.) There will be a steady stream of inserts only (no updates or deletes) to
one or both sql servers.
3.) The same data must always reside on both servers (or no more than a
minute off)
4.) The application communicates to a virtual dns name that will point to
one or both sql servers via round robin or a load balancer depending upon
the replication strategy.
5.) We would like to load balance across both sql servers and have them
frequently update each others db (maybe merge repl?) but if one of the sql
servers goes down the other must continue functioning with little or know
manual reconfiguration (maybe not merge - maybe log shipping and just one
getting the inserts?).
Thanks,
Jim
Load balancing with SQL Server is extremely hard to do unless it is totally
read only. You are probably better off just having the inserts all go to
one DB and using something like Log shipping or Clustering (if the locations
are close enough) for redundancy. SQL 2005 offers another option called
Database Mirroring that may work in your situation as well.
Andrew J. Kelly SQL MVP
"Jims" <biz@.neocasa.net> wrote in message
news:%23vRv7unfFHA.3692@.TK2MSFTNGP09.phx.gbl...
> We are in the process of determining a sql db replication strategy. We're
> looking at merge replication or log shipping but are in need of more
> informed suggestions. It seems like merge replication would be ideal
> except i've read that in the event one of the sql servers is unavailable
> the other stops accepting data until some elaborate reconfiguration is
> made. It also appears that merge replication requires modifying the app
> tables - not sure if the vendor will support. Log shipping seems to allow
> for an easier reconfiguration of the secondary in the event of a publisher
> failure but it's still not very automatic. I've listed the SLA and
> specifications. Any ideas or experiences would be most appreciated.
> 1.) We have two locations and must have a sql server in each location.
> 2.) There will be a steady stream of inserts only (no updates or deletes)
> to one or both sql servers.
> 3.) The same data must always reside on both servers (or no more than a
> minute off)
> 4.) The application communicates to a virtual dns name that will point to
> one or both sql servers via round robin or a load balancer depending upon
> the replication strategy.
> 5.) We would like to load balance across both sql servers and have them
> frequently update each others db (maybe merge repl?) but if one of the sql
> servers goes down the other must continue functioning with little or know
> manual reconfiguration (maybe not merge - maybe log shipping and just one
> getting the inserts?).
> Thanks,
> Jim
>
|||Hi Jim
Only having inserts probably simplifies things a lot (depending on the db
design).
Another option you might consider, assuming you've got your key generation
strategy worked out well, might be to split your tables into partitioned
views & set up two push transactional publications (one each way) to handle
the replication. The benefit from this implemantion would be that either
node could go down without breaking the system. If you ran them both in
continuous mode, you'd probably be able to meet your < 1 minute latency
requirement without much difficulty as well..
Cheers,
Greg Linwood
SQL Server MVP
"Jims" <biz@.neocasa.net> wrote in message
news:%23vRv7unfFHA.3692@.TK2MSFTNGP09.phx.gbl...
> We are in the process of determining a sql db replication strategy. We're
> looking at merge replication or log shipping but are in need of more
> informed suggestions. It seems like merge replication would be ideal
> except i've read that in the event one of the sql servers is unavailable
> the other stops accepting data until some elaborate reconfiguration is
> made. It also appears that merge replication requires modifying the app
> tables - not sure if the vendor will support. Log shipping seems to allow
> for an easier reconfiguration of the secondary in the event of a publisher
> failure but it's still not very automatic. I've listed the SLA and
> specifications. Any ideas or experiences would be most appreciated.
> 1.) We have two locations and must have a sql server in each location.
> 2.) There will be a steady stream of inserts only (no updates or deletes)
> to one or both sql servers.
> 3.) The same data must always reside on both servers (or no more than a
> minute off)
> 4.) The application communicates to a virtual dns name that will point to
> one or both sql servers via round robin or a load balancer depending upon
> the replication strategy.
> 5.) We would like to load balance across both sql servers and have them
> frequently update each others db (maybe merge repl?) but if one of the sql
> servers goes down the other must continue functioning with little or know
> manual reconfiguration (maybe not merge - maybe log shipping and just one
> getting the inserts?).
> Thanks,
> Jim
>

Best replication strategy suggestion?

We are in the process of determining a sql db replication strategy. We're
looking at merge replication or log shipping but are in need of more
informed suggestions. It seems like merge replication would be ideal except
i've read that in the event one of the sql servers is unavailable the other
stops accepting data until some elaborate reconfiguration is made. It also
appears that merge replication requires modifying the app tables - not sure
if the vendor will support. Log shipping seems to allow for an easier
reconfiguration of the secondary in the event of a publisher failure but
it's still not very automatic. I've listed the SLA and specifications. Any
ideas or experiences would be most appreciated.
1.) We have two locations and must have a sql server in each location.
2.) There will be a steady stream of inserts only (no updates or deletes) to
one or both sql servers.
3.) The same data must always reside on both servers (or no more than a
minute off)
4.) The application communicates to a virtual dns name that will point to
one or both sql servers via round robin or a load balancer depending upon
the replication strategy.
5.) We would like to load balance across both sql servers and have them
frequently update each others db (maybe merge repl?) but if one of the sql
servers goes down the other must continue functioning with little or know
manual reconfiguration (maybe not merge - maybe log shipping and just one
getting the inserts?).
Thanks,
JimLoad balancing with SQL Server is extremely hard to do unless it is totally
read only. You are probably better off just having the inserts all go to
one DB and using something like Log shipping or Clustering (if the locations
are close enough) for redundancy. SQL 2005 offers another option called
Database Mirroring that may work in your situation as well.
Andrew J. Kelly SQL MVP
"Jims" <biz@.neocasa.net> wrote in message
news:%23vRv7unfFHA.3692@.TK2MSFTNGP09.phx.gbl...
> We are in the process of determining a sql db replication strategy. We're
> looking at merge replication or log shipping but are in need of more
> informed suggestions. It seems like merge replication would be ideal
> except i've read that in the event one of the sql servers is unavailable
> the other stops accepting data until some elaborate reconfiguration is
> made. It also appears that merge replication requires modifying the app
> tables - not sure if the vendor will support. Log shipping seems to allow
> for an easier reconfiguration of the secondary in the event of a publisher
> failure but it's still not very automatic. I've listed the SLA and
> specifications. Any ideas or experiences would be most appreciated.
> 1.) We have two locations and must have a sql server in each location.
> 2.) There will be a steady stream of inserts only (no updates or deletes)
> to one or both sql servers.
> 3.) The same data must always reside on both servers (or no more than a
> minute off)
> 4.) The application communicates to a virtual dns name that will point to
> one or both sql servers via round robin or a load balancer depending upon
> the replication strategy.
> 5.) We would like to load balance across both sql servers and have them
> frequently update each others db (maybe merge repl?) but if one of the sql
> servers goes down the other must continue functioning with little or know
> manual reconfiguration (maybe not merge - maybe log shipping and just one
> getting the inserts?).
> Thanks,
> Jim
>|||Hi Jim
Only having inserts probably simplifies things a lot (depending on the db
design).
Another option you might consider, assuming you've got your key generation
strategy worked out well, might be to split your tables into partitioned
views & set up two push transactional publications (one each way) to handle
the replication. The benefit from this implemantion would be that either
node could go down without breaking the system. If you ran them both in
continuous mode, you'd probably be able to meet your < 1 minute latency
requirement without much difficulty as well..
Cheers,
Greg Linwood
SQL Server MVP
"Jims" <biz@.neocasa.net> wrote in message
news:%23vRv7unfFHA.3692@.TK2MSFTNGP09.phx.gbl...
> We are in the process of determining a sql db replication strategy. We're
> looking at merge replication or log shipping but are in need of more
> informed suggestions. It seems like merge replication would be ideal
> except i've read that in the event one of the sql servers is unavailable
> the other stops accepting data until some elaborate reconfiguration is
> made. It also appears that merge replication requires modifying the app
> tables - not sure if the vendor will support. Log shipping seems to allow
> for an easier reconfiguration of the secondary in the event of a publisher
> failure but it's still not very automatic. I've listed the SLA and
> specifications. Any ideas or experiences would be most appreciated.
> 1.) We have two locations and must have a sql server in each location.
> 2.) There will be a steady stream of inserts only (no updates or deletes)
> to one or both sql servers.
> 3.) The same data must always reside on both servers (or no more than a
> minute off)
> 4.) The application communicates to a virtual dns name that will point to
> one or both sql servers via round robin or a load balancer depending upon
> the replication strategy.
> 5.) We would like to load balance across both sql servers and have them
> frequently update each others db (maybe merge repl?) but if one of the sql
> servers goes down the other must continue functioning with little or know
> manual reconfiguration (maybe not merge - maybe log shipping and just one
> getting the inserts?).
> Thanks,
> Jim
>

Best replication strategy suggestion?

We are in the process of determining a sql db replication strategy. We're
looking at merge replication or log shipping but are in need of more
informed suggestions. It seems like merge replication would be ideal except
i've read that in the event one of the sql servers is unavailable the other
stops accepting data until some elaborate reconfiguration is made. It also
appears that merge replication requires modifying the app tables - not sure
if the vendor will support. Log shipping seems to allow for an easier
reconfiguration of the secondary in the event of a publisher failure but
it's still not very automatic. I've listed the SLA and specifications. Any
ideas or experiences would be most appreciated.
1.) We have two locations and must have a sql server in each location.
2.) There will be a steady stream of inserts only (no updates or deletes) to
one or both sql servers.
3.) The same data must always reside on both servers (or no more than a
minute off)
4.) The application communicates to a virtual dns name that will point to
one or both sql servers via round robin or a load balancer depending upon
the replication strategy.
5.) We would like to load balance across both sql servers and have them
frequently update each others db (maybe merge repl?) but if one of the sql
servers goes down the other must continue functioning with little or know
manual reconfiguration (maybe not merge - maybe log shipping and just one
getting the inserts?).
Thanks,
JimLoad balancing with SQL Server is extremely hard to do unless it is totally
read only. You are probably better off just having the inserts all go to
one DB and using something like Log shipping or Clustering (if the locations
are close enough) for redundancy. SQL 2005 offers another option called
Database Mirroring that may work in your situation as well.
Andrew J. Kelly SQL MVP
"Jims" <biz@.neocasa.net> wrote in message
news:%23vRv7unfFHA.3692@.TK2MSFTNGP09.phx.gbl...
> We are in the process of determining a sql db replication strategy. We're
> looking at merge replication or log shipping but are in need of more
> informed suggestions. It seems like merge replication would be ideal
> except i've read that in the event one of the sql servers is unavailable
> the other stops accepting data until some elaborate reconfiguration is
> made. It also appears that merge replication requires modifying the app
> tables - not sure if the vendor will support. Log shipping seems to allow
> for an easier reconfiguration of the secondary in the event of a publisher
> failure but it's still not very automatic. I've listed the SLA and
> specifications. Any ideas or experiences would be most appreciated.
> 1.) We have two locations and must have a sql server in each location.
> 2.) There will be a steady stream of inserts only (no updates or deletes)
> to one or both sql servers.
> 3.) The same data must always reside on both servers (or no more than a
> minute off)
> 4.) The application communicates to a virtual dns name that will point to
> one or both sql servers via round robin or a load balancer depending upon
> the replication strategy.
> 5.) We would like to load balance across both sql servers and have them
> frequently update each others db (maybe merge repl?) but if one of the sql
> servers goes down the other must continue functioning with little or know
> manual reconfiguration (maybe not merge - maybe log shipping and just one
> getting the inserts?).
> Thanks,
> Jim
>|||Hi Jim
Only having inserts probably simplifies things a lot (depending on the db
design).
Another option you might consider, assuming you've got your key generation
strategy worked out well, might be to split your tables into partitioned
views & set up two push transactional publications (one each way) to handle
the replication. The benefit from this implemantion would be that either
node could go down without breaking the system. If you ran them both in
continuous mode, you'd probably be able to meet your < 1 minute latency
requirement without much difficulty as well..
Cheers,
Greg Linwood
SQL Server MVP
"Jims" <biz@.neocasa.net> wrote in message
news:%23vRv7unfFHA.3692@.TK2MSFTNGP09.phx.gbl...
> We are in the process of determining a sql db replication strategy. We're
> looking at merge replication or log shipping but are in need of more
> informed suggestions. It seems like merge replication would be ideal
> except i've read that in the event one of the sql servers is unavailable
> the other stops accepting data until some elaborate reconfiguration is
> made. It also appears that merge replication requires modifying the app
> tables - not sure if the vendor will support. Log shipping seems to allow
> for an easier reconfiguration of the secondary in the event of a publisher
> failure but it's still not very automatic. I've listed the SLA and
> specifications. Any ideas or experiences would be most appreciated.
> 1.) We have two locations and must have a sql server in each location.
> 2.) There will be a steady stream of inserts only (no updates or deletes)
> to one or both sql servers.
> 3.) The same data must always reside on both servers (or no more than a
> minute off)
> 4.) The application communicates to a virtual dns name that will point to
> one or both sql servers via round robin or a load balancer depending upon
> the replication strategy.
> 5.) We would like to load balance across both sql servers and have them
> frequently update each others db (maybe merge repl?) but if one of the sql
> servers goes down the other must continue functioning with little or know
> manual reconfiguration (maybe not merge - maybe log shipping and just one
> getting the inserts?).
> Thanks,
> Jim
>

Best Recovery plan for MergeReplication

hi all,
i established merge replication between two servers with no synch option.i
dont have any idea of how to restore it original is it fails.how can i
restore both publisher and subscriber with out any data loss.what is the
recovery plan i have to use.
your help is appreciated
thanks
reddy
thanks paul,
my doubt is the replication is stopped without synchronising the data from
publisher to subscriber.the data is available at publisher and not in
subscriber.in this case which steps i have to follow.just i can take a backup
of publisher and restore it in the original and start connecting to
subscriber.is it works.please help
thanks
reddy
"Paul Ibison" wrote:

> Reddy,
> you can backup your publisher, distributor and
> subscribers. The recovery mode is not important in the
> sense that any one will work for replication, and the
> usual considerations apply - eg if you want a more
> granular backup strategy, full recovery mode and
> transaction log backups are used.
> After you restore a publisher's backup, depending on your
> situation, you might want to reinitialize or you may want
> to synchronize your publication database immediately with
> a subscription database that has the latest data, and
> attempt to recover any changes synchronized with that
> replica but not included in the most recent publication
> database backup of publication database transaction log
> backup.
> Assuming you haven't changed the replication
> configuration, you don't need to restore the distribution
> database to a consistent point in time.
> BTW BOL has a good section on this : Strategies for
> Backing Up and Restoring Merge Replication.
> HTH,
> Paul Ibison
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Reddy,
you mention that 'replication is stopped'. What error
message do you receive when you run the merge agent. This
is the crucial bit and it may not be necessary/helpful to
restore a backup.
Regards,
Paul Ibison
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Best Practices for Changing Merge Replication Server

We are planning on moving some SQL Server databases that are currenlty
running Merge replication as the publisher and distributor. The existing
server will eventually be scrapped and the new server will take over as the
new Publisher/Distributor. The current server is replication to a subscriber
that is also our 24/7 website SQL Server, and cannot be interrupted, and it
is imperative that no transactions on the website server be lost. Can anyone
provide any insight or articles that outline the best approach to take while
doing this migration?
Regards,
With merge replication transactions can be and frequently are rolled back.
So from the start your topology does not make a lot of sense.
If you want to minimize data loss in your situation you would be better off
to make your web server the publisher and configure it with anonymous
subscribers. This way you can drop a subscriber or take it offline and bring
it back on line or redeploy the subscription to a new server with little
impact on the publisher (now the web server). Still you have the possibility
of data loss.
With your current topology there is no way to do this without disruption
your web server/subscriber.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Frank" <Frank@.discussions.microsoft.com> wrote in message
news:075DE1AF-FC0D-4423-8548-E8CCC744558B@.microsoft.com...
> We are planning on moving some SQL Server databases that are currenlty
> running Merge replication as the publisher and distributor. The existing
> server will eventually be scrapped and the new server will take over as
the
> new Publisher/Distributor. The current server is replication to a
subscriber
> that is also our 24/7 website SQL Server, and cannot be interrupted, and
it
> is imperative that no transactions on the website server be lost. Can
anyone
> provide any insight or articles that outline the best approach to take
while
> doing this migration?
> Regards,

Best Practices

In short, I am looking for a step by step best practice for making
database changes to a database that is using merge replication between
multiple locations.
Background information:
Using SQL 2000, I have a publisher and 3 subscribers of a very large
database. The database is in use 24/7/365. The entire database is
replicated.
In the next release of the application I need to update views, add
fields to certain tables, add entirely new tables, constraints, and
indexes.
Is there a way to implement these changes at the publisher and have it
update the subscribers or at least update the publication information
as the new tables will need to be replicated as well and I want to make
sure all associated rowguids, triggers, etc. are created internally for
replication.
Pls have a look at sp_repladdcolumn and sp_repldropcolumn in BOL. Also there
is my article on making changes to an existing column:
http://www.replicationanswers.com/AddColumn.asp
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||To replicate schema only objects (like views, functions, stored procedures,
etc) use snapshot replication.
If you use sp_addmergearticle to add new articles (tables) to your
publication a snapshot of all of your tables will be generated. If you can
use a separate publication for these new articles.
Otherwise other schema changes can be performed by using sp_repladdcolumn
and sp_repldropcolumn. These procs are limited in what they can do, so you
might find yourself having to recreate the publications in some cases.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"Steve B" <SBaxter.RBS@.gmail.com> wrote in message
news:1162949137.394153.305500@.k70g2000cwa.googlegr oups.com...
> In short, I am looking for a step by step best practice for making
> database changes to a database that is using merge replication between
> multiple locations.
> Background information:
> Using SQL 2000, I have a publisher and 3 subscribers of a very large
> database. The database is in use 24/7/365. The entire database is
> replicated.
> In the next release of the application I need to update views, add
> fields to certain tables, add entirely new tables, constraints, and
> indexes.
> Is there a way to implement these changes at the publisher and have it
> update the subscribers or at least update the publication information
> as the new tables will need to be replicated as well and I want to make
> sure all associated rowguids, triggers, etc. are created internally for
> replication.
>

Behaviour of Merge Replication

I want to deepen the function of Merge Replication:
1) what's the main difference between a push subscription and a pull
subscription ?
2) if I have a subscriber node that for many time (4-5 months) is
disconnected from publisher, what will it do when it'll be re-connected
to the network ?
3) is there a method to force the re-synchronization of DB subscriber
in this case ?
4) instead if I have a failure of Publisher server, and I work only
with subscribers, what sould I do after the restart of Publisher to
load the changes made in subscribers DB ?
Hi Marco - answers inline:

> 1) what's the main difference between a push subscription and a pull
> subscription ?
Which box does the work. If I have the choice, I prefer to have the agents
centralised and use one set of alerts and notifications.
> 2) if I have a subscriber node that for many time (4-5 months) is
> disconnected from publisher, what will it do when it'll be re-connected
> to the network ?
It will error and require reinitialization.
> 3) is there a method to force the re-synchronization of DB subscriber
> in this case ?
The term we use is Reinitialization. sp_reinitmergesubscription and
sp_reinitmergepullsubscription can be used. Run the snapshot agent then the
merge agent.
> 4) instead if I have a failure of Publisher server, and I work only
> with subscribers, what sould I do after the restart of Publisher to
> load the changes made in subscribers DB ?
>
Restore an older version of the publisher's database and synchronize. This
is not foolproof (eg schema changes and download only articles will require
some thought) but it generally works.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||answers inline
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
"Marco" <peska78@.tin.it> wrote in message
news:1164723024.262636.185820@.h54g2000cwb.googlegr oups.com...
>I want to deepen the function of Merge Replication:
> 1) what's the main difference between a push subscription and a pull
> subscription ?
With a push the publisher initiates the sync, with a pull the subscriber
initiates it. Push is good for a small number of subscribers when you want
to centrally manage them. Pull is good for a large number of subscribers but
you don't have a central point of management.
> 2) if I have a subscriber node that for many time (4-5 months) is
> disconnected from publisher, what will it do when it'll be re-connected
> to the network ?
It will probably have expired so you will need to send a new snapshot down.
you can upload the subscriber changes before the snapshot is applied.
> 3) is there a method to force the re-synchronization of DB subscriber
> in this case ?
Its called a re-initialization. Expand your publication and right click on
your subscription and select reinitialize to reinitilize the problem
subscriber.
> 4) instead if I have a failure of Publisher server, and I work only
> with subscribers, what sould I do after the restart of Publisher to
> load the changes made in subscribers DB ?
>
Nothing. When the subscriber comes back on line it will synchronize changes
which have occurred with the subscribers. If the retention period has passed
most of your subscribers will probably have expired which means you will
have to reinitialize, run the snapshot agent and then run the merge agents.
|||Paul, Hilary
thanks for your answers.
|||Hi Josip
There is no hard rule defining small, or the cut off point going from push
to pull. I normally use pull for over 10 subscribers.
As you have some tables which are only one direction I would use
transactional replication. As you have some which are bi-directional I would
use merge for those.
For the merge publications use central publisher in your head office. For
the uni-directional publications it depends on the data flow, if they are
going to the central publisher make the branch offices the publishers, ie 14
publishers in the branch office going to the central publisher in the head
office. If they are going from the central publisher in the head office to
the subscribers branch office use the central publisher in the head office.
HTH
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
"Josep" <jmartinez@.autec.es> wrote in message
news:e4BsFn5FHHA.1912@.TK2MSFTNGP03.phx.gbl...
> Hi Hilary,
> I new in replications and I've just realised that I need Merge replication
> (after reading the first chapter of your book). So I started looking for
> information about Merge. But still I've things unclear. For example, I
> don't know if I should use push or pull subscriber. When you say:
>
> what's a small number of subscribers? Because I've 15 machines to be
> replicated, where one is a dedicated server, the Central Server. Some
> tables must be replicated to everywhere (using the Central Server?) and
> some other tables just replicated to the Central Server (so a filter
> should be applied?). It's like a star topology.
> And this goes to another question. What's better, to have the publication
> in the Central Server and push/pull subscription to the other computers or
> generate a publication on each server and make the Central Server a
> subscriber of all?
> I think that the first option is the best, at least for the tables that
> must be replicated to everywhere, but I'm not sure for the tables that
> must be filtered.
>
> Thank you,
> Josep Martnez
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> escribi en el mensaje
> news:eNEH1zvEHHA.4132@.TK2MSFTNGP04.phx.gbl...
>

Before merging,validate subscribers with this expression

Hello,
Could someone explain me what it meens.
I have made 2 merge publications with dynamic filters: suser_sname()
The first one does not validate subcriber before the synchronisation
The second one validate with 'suser_sname()'
I do not see differences between the 2 replication, and i do not exactly
understand what it means.
Thank you.
Courtoisement
Pierre-Marie PETIT
pm@.nst.fr
03 20 06 63 94
can you script out your publication and subscription and post it here?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"pm" <pm@.nst.fr> wrote in message
news:uPfNCExnEHA.3428@.TK2MSFTNGP11.phx.gbl...
> Hello,
> Could someone explain me what it meens.
> I have made 2 merge publications with dynamic filters: suser_sname()
> The first one does not validate subcriber before the synchronisation
> The second one validate with 'suser_sname()'
> I do not see differences between the 2 replication, and i do not exactly
> understand what it means.
> Thank you.
> --
> Courtoisement
> Pierre-Marie PETIT
> pm@.nst.fr
> 03 20 06 63 94
>
|||Here is the only differences between the 2 publications
(you can see that it is only here: @.validate_subscriber_info =
N'suser_sname()' Thie parameters is not in the second Tsql code)
So i do not understand what is this parameter for @.validate_subscriber_info
exec sp_addmergepublication @.publication =
N'pub_SYNERGY_Dyn_UserFilter_validation', @.description = N'Pub avec Filtre
sur le user et validation des donnes', @.retention = 14, @.sync_mode =
N'native', @.allow_push = N'true', @.allow_pull = N'true', @.allow_anonymous =
N'false', @.enabled_for_internet = N'false', @.centralized_conflicts =
N'true', @.dynamic_filters = N'true', @.snapshot_in_defaultfolder = N'true',
@.compress_snapshot = N'false', @.ftp_port = 21, @.ftp_login = N'anonymous',
@.conflict_retention = 14, @.keep_partition_changes = N'true',
@.allow_subscription_copy = N'false', @.allow_synctoalternate = N'false',
@.validate_subscriber_info = N'suser_sname()', @.add_to_active_directory =
N'false', @.max_concurrent_merge = 0, @.max_concurrent_dynamic_snapshots = 0
exec sp_addmergepublication @.publication = N'pub_SYNERGY_Dyn_UserFilter',
@.description = N'Pub avec Filtre sur le user (qui ne doit pas faire partie
du compte admin de sql)', @.retention = 14, @.sync_mode = N'native',
@.allow_push = N'true', @.allow_pull = N'true', @.allow_anonymous = N'false',
@.enabled_for_internet = N'false', @.centralized_conflicts = N'true',
@.dynamic_filters = N'true', @.snapshot_in_defaultfolder = N'true',
@.compress_snapshot = N'false', @.ftp_port = 21, @.ftp_login = N'anonymous',
@.conflict_retention = 14, @.keep_partition_changes = N'true',
@.allow_subscription_copy = N'false', @.allow_synctoalternate = N'false',
@.add_to_active_directory = N'false', @.max_concurrent_merge = 0,
@.max_concurrent_dynamic_snapshots = 0
"Hilary Cotter" <hilary.cotter@.gmail.com> a crit dans le message de
news:%23cPKwUxnEHA.3396@.tk2msftngp13.phx.gbl...
> can you script out your publication and subscription and post it here?
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "pm" <pm@.nst.fr> wrote in message
> news:uPfNCExnEHA.3428@.TK2MSFTNGP11.phx.gbl...
>