Be Thorough When Making Schema Changes

This morning we made some changes to the database.  We realized that as part of a re-factor we needed to move 2 columns from table A to table B.  We made the changes and immediately a lot of unit tests began failing.  As we worked on it we found out we forgot a couple of things:

1. The logging trigger on the table needed to be changed.  I take responsibility for this.  Another developer made the change, talked to me, and I didn’t think it through.  This is one reason I use triggers minimally, and why some people won’t use them at all.
2. We are using Linq to SQL for data access on this project.  I haven’t been shy about stating my dislike for Linq to SQL, but allowed it on this project partly so I could understand it well enough to complain about it intelligently.  Well, when you make changes to a the database schema, those changes need to be made to the DBML as well because Linq to SQL is generating SQL statements from the DBML which means the SQL being generated will be wrong if you don’t update the DBML.

Moral of the story

Make sure you consider everything and take your time when making schema changes.