January 20, 2009 at 4:49 pm
We have a development server which is being restored every night with the backup taken from production. The job which is doing this is not in our server.
Sometimes, however, we don't want our database to be replaced by a production copy because we are losing our newly developed code. One of the solution could be is to create daily snapshots.
But I am looking for an advice to how to prevent it in simplier way, like to lock database somehow or something like that.
Thanks.
January 20, 2009 at 5:03 pm
Why not have two databases, a dev one and a support one. The support is created each night based on a backup of the live database. The dev one is restored from the live backup as required.
You then can use the support one for troubleshooting customer issues, and the dev one for the development of new functions.
Hope that helps
David
January 20, 2009 at 5:19 pm
We actually used to have it, David. But there are at least two problems we faced with such kind of allocation.
1. Databases in dev and in prod have the same name, therefore restore overrides not the dbname_prod, but our actual database, and that job is not in our hands.
2. We can name our dev as dbname_dev instead, but there were cases when code went to production with "use dbname_dev".
January 20, 2009 at 5:43 pm
To get around point 2, you could have the policy of running the scripts against the database which is the exact copy of live before deploying it on to live. That would ensure that the scripts are correct, and don't have the wrong use statements etc.
We have the added problem with our databases in that some of the views refer to other databases. for example select * from applive.dbo.tablename That makes it very difficult to rename the database, which means that you then add up with a test database with a name like applive.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply