Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Gatsu70
Starting Member
1 Post |
 Posted - 2004-07-21 : 11:01:19
|
| Hi all!I'm new to SQL Server and i've a very big (from my point of view :P) problem; i've 2 develop server (S1 and S2) and one public server (SP). I've one db that is running on S1 and S2 (yes, it's duplicated) and some of the tables are updated in S1, some others on S2. My problem is that every night S2 make a backup of all its db, send it to S1 via ftp, S1 have to take up the backup and restore it, then make a last backup of all the db and send it to SP; when S1 restores the db, anyway, it overwrites the tables modified in it, but i need to take them. How can i update then only some tables from S1 in S2 and make a unique backup to send at SP?Tnx for all and sorry for my bad english :P |
|
|
mr_mist
Grunnio
1870 Posts |
Posted - 2004-07-21 : 11:31:56
|
| You can't do that with backup/restore. Your best bet is to try and get all the tables into one place and backup them there. You could always create a new instance of sql server to do this in. Why is the implementation spread across two servers?-------Moo. :) |
 |
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2004-07-21 : 15:38:43
|
| You might be able to use some of the automated stuff from Red Gate. Myself and others reccomend their SQL Compare tool, btu they also have some API stuff that your could use to automate this process as well.http://www.red-gate.com/SQL_Compare.htmMichael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
Hyukevain
Yak Posting Veteran
66 Posts |
Posted - 2004-07-22 : 23:07:05
|
| Use Replication instead of backup and restore. |
|
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2004-07-23 : 02:02:52
|
| you are definitely creating a problem with having two development databases. There is no easy solution to this, but backup/restore will not work for you (as you know). Actually the easy solution is to get rid of one of these instances - problem solved.Anyway, here are some other ideas:1. replication, use merge replication or transactional replication between S1 and S2.2. use sql compare and/or sql data compare from redgate to create update scripts for both S1 and S2 systems. 3. You could try and keep track of the new objects created, and manually script and create them when needed. To handle the data differences, you could use SQL data compare, or you could script all the table inserts using script on vyas' website. 4. Keeping track of new database objects is difficult, but this could be made far easier using a source control package. Look at tools that integrate with Visual Sourcesafe.All that would be doable, but you still have to actively work at keeping things properly in sync. So, I would recommend getting rid of the S2 database entirely. Or make it a QA version that does not see any active developmnt. The QA system would be routinely refreshed from production in order to to test the scripts that you would like to apply to the SP database.-ec |
|
|
|
|
|
|
|
|
Big Problem