Hi,
we are using merge replication between remote sites and
our central office. couple months ago we had a situation
where we had to insert some records and update other
records with these inserted records and then delete the
inserted records. Then we reinserted these records again
without replicating the deletes to our remote sites.
by doing this we had lots of conflicts.
I mannually deleted replicated and reinserted the records
again.
all other sites are fine but 2 of our sites, which were
disconnected during the delete replication did not get the
deleted records and they still shows conflicts every day
when they replicate. even though these records are not
being edited at all. For some reason they get marked for
replication and shows up in conflicts.
we don't care if those changes doesn't get replicated to
the remote sites becos they don't need those changes. how
do I stop them to show up in conflicts.
thanks
Kiran
did you resolve these conflicts using the conflict viewer? This is the
preferred way of solving this problem?
"Kiran" <anonymous@.discussions.microsoft.com> wrote in message
news:16bc201c41752$0defc130$a101280a@.phx.gbl...
> Hi,
> we are using merge replication between remote sites and
> our central office. couple months ago we had a situation
> where we had to insert some records and update other
> records with these inserted records and then delete the
> inserted records. Then we reinserted these records again
> without replicating the deletes to our remote sites.
> by doing this we had lots of conflicts.
> I mannually deleted replicated and reinserted the records
> again.
> all other sites are fine but 2 of our sites, which were
> disconnected during the delete replication did not get the
> deleted records and they still shows conflicts every day
> when they replicate. even though these records are not
> being edited at all. For some reason they get marked for
> replication and shows up in conflicts.
> we don't care if those changes doesn't get replicated to
> the remote sites becos they don't need those changes. how
> do I stop them to show up in conflicts.
> thanks
> Kiran
sql
Showing posts with label central. Show all posts
Showing posts with label central. Show all posts
Monday, March 26, 2012
Wednesday, March 21, 2012
replication between different sites
Can standard SQL2k replicate with enterprise edition within different sites?
*example - Central server(enterprise) in LA want to replicate with
branch(standard) in NY.
Imran,
these editions of sql server are completely compatible. As for different
sites, you'll need to follow the guidelines for replication across the
internet or non-trusted domains: http://support.microsoft.com/?id=321822.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql
*example - Central server(enterprise) in LA want to replicate with
branch(standard) in NY.
Imran,
these editions of sql server are completely compatible. As for different
sites, you'll need to follow the guidelines for replication across the
internet or non-trusted domains: http://support.microsoft.com/?id=321822.
HTH,
Paul Ibison
(The ONLY sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql
Replication between branches
Good Morning,
I have a dude with a new SQL implementation.
The scenario is a Central office with an SQL server and 10 branch offices
with sql server too. I need to replicate branches data Base with the central
sql.
All the branches could see the same DB.
It is possible to implement with SQL standard?
Or I need the Enterprise edition?
Thanks
Yes - Standard Edition is fine. You might also want to take a look here:
http://www.replicationanswers.com/CentralSubscriberArticle.asp
It might be that this is not the correct implementation - depends on other
factors eg can the branches change each other's data or is it completely
segregated?
Paul Ibison
|||Paul,
The Data can be changed by all the branches.
"Paul Ibison" wrote:
> Yes - Standard Edition is fine. You might also want to take a look here:
> http://www.replicationanswers.com/CentralSubscriberArticle.asp
> It might be that this is not the correct implementation - depends on other
> factors eg can the branches change each other's data or is it completely
> segregated?
> Paul Ibison
>
I have a dude with a new SQL implementation.
The scenario is a Central office with an SQL server and 10 branch offices
with sql server too. I need to replicate branches data Base with the central
sql.
All the branches could see the same DB.
It is possible to implement with SQL standard?
Or I need the Enterprise edition?
Thanks
Yes - Standard Edition is fine. You might also want to take a look here:
http://www.replicationanswers.com/CentralSubscriberArticle.asp
It might be that this is not the correct implementation - depends on other
factors eg can the branches change each other's data or is it completely
segregated?
Paul Ibison
|||Paul,
The Data can be changed by all the branches.
"Paul Ibison" wrote:
> Yes - Standard Edition is fine. You might also want to take a look here:
> http://www.replicationanswers.com/CentralSubscriberArticle.asp
> It might be that this is not the correct implementation - depends on other
> factors eg can the branches change each other's data or is it completely
> segregated?
> Paul Ibison
>
Replication between 2 or more SQL Express databases
Problem description
There is one central SQL Express database. And one (or more) SQL Express
database(s) on remote locations. This approach is mandatory due to some
application features later-on.
The local database(s) on the remote location(s) will act as a sort of backup
in case there is no network connection. Meaning that the data is stored
locally at all times. And moved to the central database once the network
connection is on.
Updates to the local database(s) should trigger a process where all data is
moved to the central database if there is a network connection. So for now,
it’s a one way stream: remote to central.
This approach gives us the option to delay the moves - if needed. For
example, the daily data is kept local and moved to the central site over
night. Which is a good thing to have if network resources are limited during
office hours.
Solution
To make this happen, I was thinking allong the lines of using triggered
stored procedures.
Where a local database update triggers a stored procedure that checks the
network connection and performs the move to the central database.
If there is more than one record in the remote database, all records are
moved to the central database. Also, an entry should be added to a log-file.
If the network connection is not there for whatever reason, an entry should
be written in a log-file stating that there was no connection to the central
database.
Options
Another way of solving this is using RMO-based publications and subscribers.
Where the database on the remote locations are publishers. And the central
database are subscribers. However, according to Microsoft:
- SQL Express can only act as a subscriber.
- Data is copied. And not moved.
According to the SQL-BOL, the first limitation doesn’t exist when using
programmatic, transactional replication.
However, the second needs to be solved as well. And in the examples of
SQL-BOL, this is not mentioned. At least not that I’m aware of.
There are some advantages using RMO. For example deploying a new version of
the application. Or deploying an updated database schema. Please let me know
if this is proven to be really usefull. If so, this would be the preferred
method – provided that the limitations mentioned earlier are solved. And if
using this method, I would prefer stored procedures or Visual Basic for
programming this.
Help wanted
Since I’m a newbie on these replication matters, I would like some help with
this.
Who is willing to help with examples and suggestions?
Sofar, I’ve been able to:
- Install SQL Express with network connections enabled
- Running the Management Studio and create the data model I would like to use
- Add data manually and via an ODBC connection (using a system wide DSN).
- Run SQL select commands against the added data.
So the infrastructure is up and running….
firing triggers over the network is not scalable, as there is significant
latency involved for each trigger firing. For a batch operation it is
painful. Your transactions will also hang for up to 20 seconds if the
connection is down.
You might want to look at SSIS (Integration Services) or perhaps even bcp
for what you are trying to do.
You might also want to upgrade from Express to Standard so you can do
transactional replication which will do exactly what you are trying to do.
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
"Will" <Will@.discussions.microsoft.com> wrote in message
news:474B4797-1811-4ADC-8576-0137A4FCBAF9@.microsoft.com...
> Problem description
> --
> There is one central SQL Express database. And one (or more) SQL Express
> database(s) on remote locations. This approach is mandatory due to some
> application features later-on.
> The local database(s) on the remote location(s) will act as a sort of
> backup
> in case there is no network connection. Meaning that the data is stored
> locally at all times. And moved to the central database once the network
> connection is on.
> Updates to the local database(s) should trigger a process where all data
> is
> moved to the central database if there is a network connection. So for
> now,
> it's a one way stream: remote to central.
> This approach gives us the option to delay the moves - if needed. For
> example, the daily data is kept local and moved to the central site over
> night. Which is a good thing to have if network resources are limited
> during
> office hours.
> Solution
> --
> To make this happen, I was thinking allong the lines of using triggered
> stored procedures.
> Where a local database update triggers a stored procedure that checks the
> network connection and performs the move to the central database.
> If there is more than one record in the remote database, all records are
> moved to the central database. Also, an entry should be added to a
> log-file.
> If the network connection is not there for whatever reason, an entry
> should
> be written in a log-file stating that there was no connection to the
> central
> database.
> Options
> Another way of solving this is using RMO-based publications and
> subscribers.
> Where the database on the remote locations are publishers. And the central
> database are subscribers. However, according to Microsoft:
> - SQL Express can only act as a subscriber.
> - Data is copied. And not moved.
> According to the SQL-BOL, the first limitation doesn't exist when using
> programmatic, transactional replication.
> However, the second needs to be solved as well. And in the examples of
> SQL-BOL, this is not mentioned. At least not that I'm aware of.
> There are some advantages using RMO. For example deploying a new version
> of
> the application. Or deploying an updated database schema. Please let me
> know
> if this is proven to be really usefull. If so, this would be the preferred
> method - provided that the limitations mentioned earlier are solved. And
> if
> using this method, I would prefer stored procedures or Visual Basic for
> programming this.
> Help wanted
> --
> Since I'm a newbie on these replication matters, I would like some help
> with
> this.
> Who is willing to help with examples and suggestions?
> Sofar, I've been able to:
> - Install SQL Express with network connections enabled
> - Running the Management Studio and create the data model I would like to
> use
> - Add data manually and via an ODBC connection (using a system wide DSN).
> - Run SQL select commands against the added data.
> So the infrastructure is up and running..
>
|||Hi Hilary,
Thanks for your support and feedback. I really do appreciate this!!!
> firing triggers over the network is not scalable, as there is significant
> latency involved for each trigger firing. For a batch operation it is
> painful. Your transactions will also hang for up to 20 seconds if the
> connection is down.
Mmm - sounds like we have a different understanding of the term trigger.
I would like to use triggers on the remote databases - not the central one.
As a result, triggers are not travelling across the network.
> You might want to look at SSIS (Integration Services) or perhaps even bcp
> for what you are trying to do.
I looked at SSIS. That would require
I'm not familiar with BCP. But it looks like a bulk COPY tool.
How would this help in MOVING the data?
> You might also want to upgrade from Express to Standard so you can do
> transactional replication which will do exactly what you are trying to do.
Do you mean replace Express with standaard on the remote side?
On the central side? Or both?
Keep in mind that SQL Express on the remote sites needs to run on
Workstations.
Ans therefor requires a light footprint.
Will
|||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
"Will" <Will@.discussions.microsoft.com> wrote in message
news:E6201678-BFD9-4290-ABAC-1D7A5F6E1962@.microsoft.com...
> Hi Hilary,
> Thanks for your support and feedback. I really do appreciate this!!!
>
> Mmm - sounds like we have a different understanding of the term trigger.
> I would like to use triggers on the remote databases - not the central
> one.
> As a result, triggers are not travelling across the network.
>
> I looked at SSIS. That would require
> I'm not familiar with BCP. But it looks like a bulk COPY tool.
> How would this help in MOVING the data?
>
it doesn't move data, it copies it row by row. I know of no technology
which actually moves that, all copy it and you have to delete it yourself on
the source.
> Do you mean replace Express with standaard on the remote side?
> On the central side? Or both?
> Keep in mind that SQL Express on the remote sites needs to run on
> Workstations.
> Ans therefor requires a light footprint.
In retrospect you will probably need a code solution. Put a timestamp on
your tables which you can use to determine which rows have changed since the
last time you "moved" data. Anything greater than the timestamp the last
time you polled must be moved.
You will probably be able to use any version of SQL Server for this.
> --
> Will
>
There is one central SQL Express database. And one (or more) SQL Express
database(s) on remote locations. This approach is mandatory due to some
application features later-on.
The local database(s) on the remote location(s) will act as a sort of backup
in case there is no network connection. Meaning that the data is stored
locally at all times. And moved to the central database once the network
connection is on.
Updates to the local database(s) should trigger a process where all data is
moved to the central database if there is a network connection. So for now,
it’s a one way stream: remote to central.
This approach gives us the option to delay the moves - if needed. For
example, the daily data is kept local and moved to the central site over
night. Which is a good thing to have if network resources are limited during
office hours.
Solution
To make this happen, I was thinking allong the lines of using triggered
stored procedures.
Where a local database update triggers a stored procedure that checks the
network connection and performs the move to the central database.
If there is more than one record in the remote database, all records are
moved to the central database. Also, an entry should be added to a log-file.
If the network connection is not there for whatever reason, an entry should
be written in a log-file stating that there was no connection to the central
database.
Options
Another way of solving this is using RMO-based publications and subscribers.
Where the database on the remote locations are publishers. And the central
database are subscribers. However, according to Microsoft:
- SQL Express can only act as a subscriber.
- Data is copied. And not moved.
According to the SQL-BOL, the first limitation doesn’t exist when using
programmatic, transactional replication.
However, the second needs to be solved as well. And in the examples of
SQL-BOL, this is not mentioned. At least not that I’m aware of.
There are some advantages using RMO. For example deploying a new version of
the application. Or deploying an updated database schema. Please let me know
if this is proven to be really usefull. If so, this would be the preferred
method – provided that the limitations mentioned earlier are solved. And if
using this method, I would prefer stored procedures or Visual Basic for
programming this.
Help wanted
Since I’m a newbie on these replication matters, I would like some help with
this.
Who is willing to help with examples and suggestions?
Sofar, I’ve been able to:
- Install SQL Express with network connections enabled
- Running the Management Studio and create the data model I would like to use
- Add data manually and via an ODBC connection (using a system wide DSN).
- Run SQL select commands against the added data.
So the infrastructure is up and running….
firing triggers over the network is not scalable, as there is significant
latency involved for each trigger firing. For a batch operation it is
painful. Your transactions will also hang for up to 20 seconds if the
connection is down.
You might want to look at SSIS (Integration Services) or perhaps even bcp
for what you are trying to do.
You might also want to upgrade from Express to Standard so you can do
transactional replication which will do exactly what you are trying to do.
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
"Will" <Will@.discussions.microsoft.com> wrote in message
news:474B4797-1811-4ADC-8576-0137A4FCBAF9@.microsoft.com...
> Problem description
> --
> There is one central SQL Express database. And one (or more) SQL Express
> database(s) on remote locations. This approach is mandatory due to some
> application features later-on.
> The local database(s) on the remote location(s) will act as a sort of
> backup
> in case there is no network connection. Meaning that the data is stored
> locally at all times. And moved to the central database once the network
> connection is on.
> Updates to the local database(s) should trigger a process where all data
> is
> moved to the central database if there is a network connection. So for
> now,
> it's a one way stream: remote to central.
> This approach gives us the option to delay the moves - if needed. For
> example, the daily data is kept local and moved to the central site over
> night. Which is a good thing to have if network resources are limited
> during
> office hours.
> Solution
> --
> To make this happen, I was thinking allong the lines of using triggered
> stored procedures.
> Where a local database update triggers a stored procedure that checks the
> network connection and performs the move to the central database.
> If there is more than one record in the remote database, all records are
> moved to the central database. Also, an entry should be added to a
> log-file.
> If the network connection is not there for whatever reason, an entry
> should
> be written in a log-file stating that there was no connection to the
> central
> database.
> Options
> Another way of solving this is using RMO-based publications and
> subscribers.
> Where the database on the remote locations are publishers. And the central
> database are subscribers. However, according to Microsoft:
> - SQL Express can only act as a subscriber.
> - Data is copied. And not moved.
> According to the SQL-BOL, the first limitation doesn't exist when using
> programmatic, transactional replication.
> However, the second needs to be solved as well. And in the examples of
> SQL-BOL, this is not mentioned. At least not that I'm aware of.
> There are some advantages using RMO. For example deploying a new version
> of
> the application. Or deploying an updated database schema. Please let me
> know
> if this is proven to be really usefull. If so, this would be the preferred
> method - provided that the limitations mentioned earlier are solved. And
> if
> using this method, I would prefer stored procedures or Visual Basic for
> programming this.
> Help wanted
> --
> Since I'm a newbie on these replication matters, I would like some help
> with
> this.
> Who is willing to help with examples and suggestions?
> Sofar, I've been able to:
> - Install SQL Express with network connections enabled
> - Running the Management Studio and create the data model I would like to
> use
> - Add data manually and via an ODBC connection (using a system wide DSN).
> - Run SQL select commands against the added data.
> So the infrastructure is up and running..
>
|||Hi Hilary,
Thanks for your support and feedback. I really do appreciate this!!!
> firing triggers over the network is not scalable, as there is significant
> latency involved for each trigger firing. For a batch operation it is
> painful. Your transactions will also hang for up to 20 seconds if the
> connection is down.
Mmm - sounds like we have a different understanding of the term trigger.
I would like to use triggers on the remote databases - not the central one.
As a result, triggers are not travelling across the network.
> You might want to look at SSIS (Integration Services) or perhaps even bcp
> for what you are trying to do.
I looked at SSIS. That would require
I'm not familiar with BCP. But it looks like a bulk COPY tool.
How would this help in MOVING the data?
> You might also want to upgrade from Express to Standard so you can do
> transactional replication which will do exactly what you are trying to do.
Do you mean replace Express with standaard on the remote side?
On the central side? Or both?
Keep in mind that SQL Express on the remote sites needs to run on
Workstations.
Ans therefor requires a light footprint.
Will
|||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
"Will" <Will@.discussions.microsoft.com> wrote in message
news:E6201678-BFD9-4290-ABAC-1D7A5F6E1962@.microsoft.com...
> Hi Hilary,
> Thanks for your support and feedback. I really do appreciate this!!!
>
> Mmm - sounds like we have a different understanding of the term trigger.
> I would like to use triggers on the remote databases - not the central
> one.
> As a result, triggers are not travelling across the network.
>
> I looked at SSIS. That would require
> I'm not familiar with BCP. But it looks like a bulk COPY tool.
> How would this help in MOVING the data?
>
it doesn't move data, it copies it row by row. I know of no technology
which actually moves that, all copy it and you have to delete it yourself on
the source.
> Do you mean replace Express with standaard on the remote side?
> On the central side? Or both?
> Keep in mind that SQL Express on the remote sites needs to run on
> Workstations.
> Ans therefor requires a light footprint.
In retrospect you will probably need a code solution. Put a timestamp on
your tables which you can use to determine which rows have changed since the
last time you "moved" data. Anything greater than the timestamp the last
time you polled must be moved.
You will probably be able to use any version of SQL Server for this.
> --
> Will
>
Friday, March 9, 2012
Replication - Views/SPs etc
Hi,
Hitting the following problem - do not know how to get
around it.
Have the main application running on a central SQL server -
I take replica with me + need the latest update of the
views and stored procedures etc.
First I tried to replicate - but replica falls over - as I
have nested views + creation at the subscriber does not
build the views in a 'smart way' so it 'misses' views and
stops.
Now tried script all the views (probably the correct way
in the begining) - but again same happens - sequence of
creation of views does not work - due to nesting of views.
Only way I can get through this at the moment - is to
compare the views in the main db and the subscriber db and
make these one by one. This does not look like the view I
should do this ..... Also cannot see when the file was
last updated (I am the only one updating)- so not always
sure (monday morning) which is the latest version ......
Any simple way out of this?
Thanks for any help?
Tim
Tim,
the problem you have with the views is one of dependencies. Using sp_depends
on a nesting view you can see which views SQL Server thinks it depends on
and this is not always correct. You can use sp_refreshview to update the
dependencies then replication will add the views in the correct order.
HTH,
Paul Ibison
|||Hi Paul,
Thanks! - this makes sense that this should be part of the
SQL Server tool-box.
Unfortunately I cannot find sp_refreshview to correct the
dependancy list - so that when scripting the views - these
are rebuilt fully - or maybe I just do not understand ....
If you could point me in the right direction!!
Thanks
Tim
>--Original Message--
>Tim,
>the problem you have with the views is one of
dependencies. Using sp_depends
>on a nesting view you can see which views SQL Server
thinks it depends on
>and this is not always correct. You can use
sp_refreshview to update the
>dependencies then replication will add the views in the
correct order.
>HTH,
>Paul Ibison
>
>.
>
|||It should be, but you do have the potential to create circular views and
replication can not sort that out. There are also issues when dealing with
complex dependency chains. The best solution to this is to literally do it
yourself via a pre-script. You are the only one who knows what the precise
creation order needs to be, I would not leave it to an auto generated
process.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||Hi Mike,
Maybe this is a better situation in the end - as it forces
a more structured approach to the management of views.
Thanks for the help!
Tim
>--Original Message--
>It should be, but you do have the potential to create
circular views and
>replication can not sort that out. There are also issues
when dealing with
>complex dependency chains. The best solution to this is
to literally do it
>yourself via a pre-script. You are the only one who
knows what the precise
>creation order needs to be, I would not leave it to an
auto generated
>process.
>--
>Mike
>Principal Mentor
>Solid Quality Learning
>"More than just Training"
>SQL Server MVP
>http://www.solidqualitylearning.com
>http://www.mssqlserver.com
>
>.
>
|||Tim,
it's not actually a replication setup option, but a normal system stored
procedure. Syntax is in the form:
exec sp_refreshview titleview
If you run this on your views in the correct order, then replication will
take care of the rest.
HTH,
Paul Ibison
Hitting the following problem - do not know how to get
around it.
Have the main application running on a central SQL server -
I take replica with me + need the latest update of the
views and stored procedures etc.
First I tried to replicate - but replica falls over - as I
have nested views + creation at the subscriber does not
build the views in a 'smart way' so it 'misses' views and
stops.
Now tried script all the views (probably the correct way
in the begining) - but again same happens - sequence of
creation of views does not work - due to nesting of views.
Only way I can get through this at the moment - is to
compare the views in the main db and the subscriber db and
make these one by one. This does not look like the view I
should do this ..... Also cannot see when the file was
last updated (I am the only one updating)- so not always
sure (monday morning) which is the latest version ......
Any simple way out of this?
Thanks for any help?
Tim
Tim,
the problem you have with the views is one of dependencies. Using sp_depends
on a nesting view you can see which views SQL Server thinks it depends on
and this is not always correct. You can use sp_refreshview to update the
dependencies then replication will add the views in the correct order.
HTH,
Paul Ibison
|||Hi Paul,
Thanks! - this makes sense that this should be part of the
SQL Server tool-box.
Unfortunately I cannot find sp_refreshview to correct the
dependancy list - so that when scripting the views - these
are rebuilt fully - or maybe I just do not understand ....
If you could point me in the right direction!!
Thanks
Tim
>--Original Message--
>Tim,
>the problem you have with the views is one of
dependencies. Using sp_depends
>on a nesting view you can see which views SQL Server
thinks it depends on
>and this is not always correct. You can use
sp_refreshview to update the
>dependencies then replication will add the views in the
correct order.
>HTH,
>Paul Ibison
>
>.
>
|||It should be, but you do have the potential to create circular views and
replication can not sort that out. There are also issues when dealing with
complex dependency chains. The best solution to this is to literally do it
yourself via a pre-script. You are the only one who knows what the precise
creation order needs to be, I would not leave it to an auto generated
process.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
|||Hi Mike,
Maybe this is a better situation in the end - as it forces
a more structured approach to the management of views.
Thanks for the help!
Tim
>--Original Message--
>It should be, but you do have the potential to create
circular views and
>replication can not sort that out. There are also issues
when dealing with
>complex dependency chains. The best solution to this is
to literally do it
>yourself via a pre-script. You are the only one who
knows what the precise
>creation order needs to be, I would not leave it to an
auto generated
>process.
>--
>Mike
>Principal Mentor
>Solid Quality Learning
>"More than just Training"
>SQL Server MVP
>http://www.solidqualitylearning.com
>http://www.mssqlserver.com
>
>.
>
|||Tim,
it's not actually a replication setup option, but a normal system stored
procedure. Syntax is in the form:
exec sp_refreshview titleview
If you run this on your views in the correct order, then replication will
take care of the rest.
HTH,
Paul Ibison
Replication - Preventing data deletion
I have just started using data replication as a method of transferring data
from a temporary database to a central one. This works fine however I wanted
to be able to clear down the temporary database from time to time but not
surprisingly this deletes the corresponding records from the main database.
Is it possible to prevent the deletion of records from the publisher removing
the corresponding records in the subscriber? How about changing the Delete
command with a procedure that does nothing in the Table Article Properties?
Thanks,
Bill
You can either change the Delete to do nothing in the Table Article
properties or, if you are using the replication stored procedures, you can
alter the delete procedure at the subscriber to do nothing.
Rand
This posting is provided "as is" with no warranties and confers no rights.
from a temporary database to a central one. This works fine however I wanted
to be able to clear down the temporary database from time to time but not
surprisingly this deletes the corresponding records from the main database.
Is it possible to prevent the deletion of records from the publisher removing
the corresponding records in the subscriber? How about changing the Delete
command with a procedure that does nothing in the Table Article Properties?
Thanks,
Bill
You can either change the Delete to do nothing in the Table Article
properties or, if you are using the replication stored procedures, you can
alter the delete procedure at the subscriber to do nothing.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Replication - Preventing data deletion
I have just started using data replication as a method of transferring data
from a temporary database to a central one. This works fine however I wante
d
to be able to clear down the temporary database from time to time but not
surprisingly this deletes the corresponding records from the main database.
Is it possible to prevent the deletion of records from the publisher removin
g
the corresponding records in the subscriber? How about changing the Delete
command with a procedure that does nothing in the Table Article Properties?
Thanks,
BillYou can either change the Delete to do nothing in the Table Article
properties or, if you are using the replication stored procedures, you can
alter the delete procedure at the subscriber to do nothing.
Rand
This posting is provided "as is" with no warranties and confers no rights.
from a temporary database to a central one. This works fine however I wante
d
to be able to clear down the temporary database from time to time but not
surprisingly this deletes the corresponding records from the main database.
Is it possible to prevent the deletion of records from the publisher removin
g
the corresponding records in the subscriber? How about changing the Delete
command with a procedure that does nothing in the Table Article Properties?
Thanks,
BillYou can either change the Delete to do nothing in the Table Article
properties or, if you are using the replication stored procedures, you can
alter the delete procedure at the subscriber to do nothing.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Replication - Preventing data deletion
I have just started using data replication as a method of transferring data
from a temporary database to a central one. This works fine however I wanted
to be able to clear down the temporary database from time to time but not
surprisingly this deletes the corresponding records from the main database.
Is it possible to prevent the deletion of records from the publisher removing
the corresponding records in the subscriber? How about changing the Delete
command with a procedure that does nothing in the Table Article Properties?
Thanks,
BillYou can either change the Delete to do nothing in the Table Article
properties or, if you are using the replication stored procedures, you can
alter the delete procedure at the subscriber to do nothing.
Rand
This posting is provided "as is" with no warranties and confers no rights.
from a temporary database to a central one. This works fine however I wanted
to be able to clear down the temporary database from time to time but not
surprisingly this deletes the corresponding records from the main database.
Is it possible to prevent the deletion of records from the publisher removing
the corresponding records in the subscriber? How about changing the Delete
command with a procedure that does nothing in the Table Article Properties?
Thanks,
BillYou can either change the Delete to do nothing in the Table Article
properties or, if you are using the replication stored procedures, you can
alter the delete procedure at the subscriber to do nothing.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Subscribe to:
Posts (Atom)