In a previous blog http://blogs.sqlservercentral.com/ken_kaufman/archive/2008/05/14/performance-effects-on-column-type-changes.aspx  I talked about how SQL handled switching data types and lengths of the same data type, in particular increasing a varchar length, as well as the cost of moving a varchar to an int.  One of the points left out is moving from a varchar to a char and vice-versa.   Even though these look similar from a high level to be the same data type, there stored completely different at the record level.  Storage of data in a row involves two primary locations for data.  The first in where your fixed data types resides, this is all data that is fixed in size resides, including the char data type.  The second is your variable length section.  This second section contains some critical meta-data about your variable data, there's a global 2 byte section that tracks all the variable columns in your record, and there is an additional 2 bytes for each fields that has the offset of each variable field.  What this all means for converting char into varchar and the reverse is that it requires moving data within the record, even if your going from a char(5) to a varchar(10).  Depending on the type of conversion and underlying data could also mean significant page splits