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 |
|
verinow
Starting Member
5 Posts |
 Posted - 2006-11-29 : 14:41:47
|
| We've been using a product to compare and make changes to the live database to match our development database. For example, new tables, fields, altered sp, etc. We also use a data comparision tool to make sure the live and development databases have the same data in the lookup tables.A few people have told me to write scripts instead of using tools like these. The tools are easier than keeping track of what we need to script, etc. Has anyone experienced problems with these types of tools?Thanks,Mark |
|
|
snSQL
Master Smack Fu Yak Hacker
1837 Posts |
Posted - 2006-11-29 : 15:57:07
|
| http://sqlteam.com/forums/topic.asp?TOPIC_ID=75473 |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2006-11-30 : 02:11:39
|
| "The tools are easier than keeping track of what we need to script, etc"Possibly so, but its a "light engineering" solution IMHO.We script the DDL changes for DEV. (Making sequentially numbered "Patch" files)Those go into our version control system.We use those scripts, in order, to get from DEV to QA then to Test/Staging and finally to Production.Yes it a palaver, but we do it often, so its just routine for us.At any stage along the way we may find a snag with the script. For example we try to create a unique index and discover that there are duplicates. So we adapt the script and move on.All the changes to the script are in our version control, so when it goes T.U. we can see what changed over time. We can also see the changes we made on later rollouts (to clients) and whether anything needs to be respectively retro-fitted to earlier rollouts (for example, discovering duplicates in an index probably means that the application is capable of storing duplicates, and it might do so at any moment on one of the earlier rollouts we have already done!)Much more control IMHO.Of course you could choose to make the "rollout script" by just changing the DEV database willy-nilly, and then using a Compare tool against a "known good" database (e.g. the QA database), and then running with that script for your "Version 2" rollout, in the way I described above.In our case we frequently have things other than DDL changes that get included in our Patch script. For example we introduce a new row in our Configuration Table, and want to give that a Default value; or adding a new column needs to be pre-populated with a calculated value; and so on.Kristen |
|
|
|
|
|
|
|
|
Using comparison tools rather than scripts?