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 |
|
staplebottom
Starting Member
29 Posts |
 Posted - 2007-08-17 : 16:32:27
|
| Hi, Im fairly new to this so apologies if Ive put this in the wrong place.I have just rented out server for a new asp.net site. Ive been developing the site on my local machine and the database in Sql Enterprise. Ive recently put a copy of the site on the live server and got everything configured. However everytime I make a change to my local database, or add values into my look up tables I have to go do the same on the live server and its proving a bit of a pain in the ass, so Im guessing there has got to be a much smarter way of doing this. I dont want (if possible) to open up the live sql server to allow remote connections, but if thats what neccesary so be it.So my question is basically what are my options for keeping my live server up to date with my development server. As I add new features on my local server, should i be saving sql scripts of all the changes I make?All opinions much appreciated.C |
|
|
rmiao
Master Smack Fu Yak Hacker
7266 Posts |
Posted - 2007-08-17 : 23:52:33
|
| You shouldn't sync dev db to prod db automatically, since that will mess up prod db if anything goes wrong in dev db. You are better to do some version control of your db on dev server. |
 |
|
|
staplebottom
Starting Member
29 Posts |
Posted - 2007-08-27 : 15:45:45
|
quote:
Originally posted by rmiao
You shouldn't sync dev db to prod db automatically, since that will mess up prod db if anything goes wrong in dev db. You are better to do some version control of your db on dev server.
how is this best managed. Are there software solutions that watch changes I make to the database? |
|
|
|
dinakar
Master Smack Fu Yak Hacker
2507 Posts |
Posted - 2007-08-27 : 15:51:33
|
| Generally, prior to TFS, you would do it manually. You can use VSS to check in your stored procs/views/functions etc. Check out a proc, make your changes and check it in. VSS maintains a history of check-in's/out's. So you can always see what was the previous version, compare it against current version etc. I *think* there are some new features in TFS to deploy directly to the Prod db. Dinakar Nethi************************Life is short. Enjoy it.************************http://weblogs.sqlteam.com/dinakar/ |
|
|
|
eyechart
Master Smack Fu Yak Hacker
3575 Posts |
Posted - 2007-08-27 : 16:11:04
|
| typically, you would also want a TEST or QA environment that you could use to test your upgrade scripts on. This database would be the one that you could freely refresh with a PROD copy. You would then run your upgrade scripts and test your app functionality against this copy. This way you are assured that your PROD system upgrade will go as smoothly as possible.As for version control, VSS is an ok solution, but as you stated it is pretty manual effort. There is now a build of Visual Studio that is just for database developers. go Here for more info http://msdn2.microsoft.com/en-us/teamsystem/aa718807.aspx . We are just beginning an evaluation of this product too, so I really have no idea if this is a decent solution or not. At first glance it seems to be pretty well integrated (unlike VSS), so that is a big plus.-ec |
|
|
|
|
|
|
|
|
Keeping live server and development server in Sync