Hello,
In our environment (SQL 2005) we have a database that uses Transactional Replication to sync data between two SQL 2005 servers. There is a web app that reads/writes data to the publisher server and the other server (that gets the replicated data) is used by some other internal applications.
At times, there is a need to delete some data from the publisher server...but this can ONLY happen once the data has been successfully replicated to the second server. Is there any way to determine if a row has been replicated successfully?
thanks
- will
If you are using transactional, it shouldn't matter when you fire the delete through. That's because it maintains the exact sequence of transactions that were performed against the publisher at all times such that nothing can get out of order. So, if it is valid to issue on the publisher, it will be valid to issue against the subscriber. You can tell if anything is pending being sent by looking in the Replication Monitor. In order to check a particular row, you have to hit the subscriber and check it.|||Actually, now that I think about it, the requirement is to allow deletes on the Publisher server, but not have those get replicated to the other server (the subscriber) that is part of the transactional replication. So, in this situation, if this is running under transactional replication, every action (Insert, Update, Delete) will be run at the Publisher and then at the subscriber server...which is not what the customer wants. They want the data deleted off our server (the publisher), but want to keep it on their server (the subscriber). Hmmmm.....
|||You can change the article properties to not replicate deletes, or use custom stored procedures to delete nothing.
No comments:
Post a Comment