October 30, 2009 at 2:16 pm
I am new to replication and am in need of some quick help.
We have an SQL2000 database that gets backed up and restored to a new read-only version on the same server on a weekly basis for reporting by external customers via a Web interface. We have one table that is actually updated in the read-only database that we would like to have replicated back to the Production database (ClientLogins) so that any changes there will be saved and come back over on the next restore of the read-only database.
We thought that replication would be a good fit. In short, this will allow us to avoid granting permissions to production OR re-designing the processes involving ClientLogins.
We played around with setting up replication and it worked great...until the read-only database was restored with a fresh copy. The replication was "broken" at that point. We tried a bunch of things to try to re-set the process but all were problematic or did not work.
What I would like to know is if this is a dead end. Should I keep digging into how to turn the various jobs back on and re-point the various internal workings of distribution and etc., or just go with plan B which is a custom sync with a scheduled job?
November 26, 2009 at 9:17 am
Hi,
If the restored db is on the same server can't you just replicate the one table from the original db..
Might need a bit of code change as you have mentioned updates..
Regards
Graeme
November 27, 2009 at 4:23 pm
Thanks for the reply.
What we ended up doing was along the same lines as your suggestion. We could not use replication even on the one table (the problem I was posting) so we changed to do our own DTS job that takes the table from the "read-only" database prior to it being refreshed from production.
It turned out to be a good lesson learned about replication-- when not to use it.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply