Today we've got a fun story from OneFactor about some Database Change Migration Procedure ...

Developers often need to add columns to database tables in order to support new functionality, so before we deploy to test and production databases, each dev team sends some change scripts (mostly full of alter table statements and generated painlessly by Enterprise Manager). The DBA "runs" them on the test database and if testing goes well, the DBA then "runs" them on the production database. So far so good?

The WTF appears when one learns that the DBA never actually runs the scripts the dev team sends! The DBA is under orders from on high to read the script and manually add / modify the columns via Enterprise Manager! Why you ask? So that the new columns can be inserted into the table in alphabetical order rather than at the end...

Our process may be error-prone and manual even though easily automated, but hey at least our fields show up in the right order.

Of course, what makes this even more bizarre is that you cannot "move" a column in SQL. To get around this, Enterprise Manager does the following:
• Creates a temp table based on the original table
• select * from original table into temp table
• drops original table
• recreates original table with new column order
• select * from temp into new
• drops temp table

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!