July 22, 2008 at 2:51 pm
If you are restoring it to a different Server, then I would expect the replication to be dropped.
Is there replication setup on the Server where Sales runs the reports from? Are all of the replication jobs named the same on the production Server as well as the Server used for reporting?
You could try dropping all of the replication jobs before running the restore and then recreating them after the restore has completed. However, as stated before, if you copy a replicated database from one Server to another, there should be no problems with Replication since the jobs are invalid on the other Server.
Regards, Irish
July 23, 2008 at 3:36 am
There is no replication set up on the target server
July 25, 2008 at 3:30 am
Further investigation has shown that when I restore the database to another SQL2000, there are problems there with removing the replication objects (triggers), though this is not reported during the restore.
Running the sp_removedbreplication system stored procedure against the database on the SQL2000 server reports that it has run successfully, though the triggers are not removed. To get the restored database into a workable status I have to remove these triggers manually.
It therefore suggests that the source database is in some sort of inconsistent state. I think I'll try removing replication from this totally (no big problem as the replication's not working properly at the moment and the agent jobs have been disabled) -AFTER I've backed it up of course!
July 30, 2008 at 6:02 pm
As you are restoring between versions (i.e. 2000 to 2005) try the following command:
[font="Courier New"]sp_restoredbreplication @srv_orig='SVR2000NAME', @db_origin='dbName', @perform_upgrade=1[/font]
The @perform_upgrade parameter is marked as for internal use only in BOL, but this worked for me and you can then run sp_removedbreplication afterwards.
Viewing 4 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply