Thanks a lot Andy.

Your article was gr8. I am new to replication. I look forward to your follow up articles to try this out.

Rgds,

Sam

Andy,

  Nice presentation with the screen shots. The caveats and advice you offer at each step is what really makes your article most valuable. I also administer just a few (  ) Oracle, Advanced Replication environments that are considerably more difficult to setup and manage. I most appreciate your guidance with the replication mechanism here.

-- Jonathan

Thanks for the great information. I am also new to replication and might need to get ramped up in a hurry so this was quite helpful.

I was curious on your opinion if my scenario would be an ideal candidate for replication. There is some old legacy data that needs to be cleaned up by some staff that are probably going to be at different locations that aren't connected. I was starting to look at the possibility of installing personal edition of SQL 2000 on their machines and then maybe doing replicating to keep the data as synchronized as possible. This seems like a good case for replication, but I am new to it so I thought I would get your take. thanks

Keith

If its a long term situation, probably worth considering. If its a short term project, I'd be more inclined to just dump into an Access db, let them clean away, then just do an update back joining on the primary key. Whether that works depends on how much the data is going to be altered before they finish cleaning and update back.

I'd have to check again what the restrictions on Personal Edition are, just to be sure. You could do transactional with immediate update or merge is this situation, transactional less invasive on your primary system.

Hi, You have got really nice article here on replication. We have a replication topology where the subscriber is pulling data from 2 publishers and these are different tables.

We want an application to query data from the subscriber and also update a few tables in the subscriber . These tables are created within the subscriber and not replicated from any of the Pubs. These updates should not propogate back to the publisher.

Do you forsee any problems with this kind of replication + Update on the subscriber? This seems to work without problems when we tried it out, but we really dont want surprises in production

Thanks,

Aditee

For the most part it will work ok. One potential gotcha if you add a record and use a primary key that ends up getting added on the publisher later - will get a dupe key error and have to do some fix up. Changing records via updates will also make it hard (or impossible) to do validation - where you check to make sure you have the same data on the publisher that you do on the subscriber. Plus, what happens if your publisher/publication fails - doing a snapshot gets more complicated so that you don't lose changes made to subscriber.

Honestly I'd look at trying to either do the updates to the subscriber directly or via some type of process, let them replicate back to the subscriber.

Well Andy, you've enticed me into the murky world of the replicants. Actually i was heading this way anyway, but you've given me a lift and saved me time! I'm interested in the MSDE replication issue you raise - is there no way we can use MSDE within a replication environment - to push content from separate MSDE databases (different machines) to a central SQL Server database; or for a central SQL Server database to pull content over