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 |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-10-31 : 08:53:27
|
| Pradish writes "Situation: 1. Our development team develops our enterprise application on our LAN 'test' database. Hence, all database objects are created on this database and the development code runs of this database.2. Our consultants, on the other hand, alter tables (addition of columns) and don't bring these changes back to the office.Problem: Our problem is that if any developer adds a column to a table, the consultant needs to make this change on site. The problem is that these tables are not the same(certain columns may exist or not exist). So the consultant cannot merely copy the data from the table to a tempory table, add the addition column, and move data from the tempory table to the correct table, because if the tables are not the same, data from a specific column is lost.Question?1. Do you know of any methods to overcome this dilemma of ours?2. What is the industry norm to overcome situations like this?3. How does one transfer data from one table to another table (that has an additional column) without losing the data from the other table?" |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-10-31 : 09:02:42
|
| 1. Do you know of any methods to overcome this dilemma of ours? Source Control2. What is the industry norm to overcome situations like this? Source Control3. How does one transfer data from one table to another table (that has an additional column) without losing the data from the other table?" Source Control...OK, not really, but it will helpYour problem is not that a developer or consultant alters a table but doesn't apply it, it's that the developer is ALTERING THE TABLE AT ALL. The industry norm is that tests are done on a non-production server, reviewed by the developers, supervisors, AND the database administrator, and then deployed to the production box. No developer or non-DBA person should be modifying a database without some kind of review process. Making these kinds of changes should NEVER be done in a "Hey Fred, I'm gonna change this thingie over here", "Sure Bill, whatever" scenario. If the DBA feels they can't be bothered with this kind of review process, they might as well stop backing up the databases while they're at it, 'cause someone's gonna FUBAR the server at some point and data will be lost.Source control will put the brakes on these changes. The creation scripts for the database, tables, and procedures will be consolidated into a source control application like Visual Source Safe or CVS. The revision history will be maintained, and changes can be undone if necessary. Also, you'll have a full record of WHO made WHAT change and WHEN they did it. Count yourself extremely fortunate if you haven't yet had to undo some stupid mistake and couldn't figure out who did it. I can tell you that if you continue the way you are now, you WILL have this problem in the future. This applies to test servers as well as production servers.Edited by - robvolk on 10/31/2002 09:03:18 |
 |
|
|
|
|
|
|
|
Unique problem of adding a column to a table