One of my clients called me last week and seemed to be a little troubled. To protect his identity I'll call him Gary.
We've been working together to roll out an internal site for a large company. We'd setup a number of Team Sites and wanted information from several of these sites to roll up into Product sites using the Content Query Web Part (CQWP). We had created Site Columns at the site collection level to describe the documents we were uploading and set them as Choice fields. We setup the CQWPs using the filtering capabilities to only show us documents that met specific criteria (the CQWP can only filter on site columns created at the site collection level). It worked like a charm. and everything rolled up as it should until one day a new requirement was introduced to make it so the same documents from a single Team Site could show for multiple product sites. Gary changed the site column on the list to a choice field with checkboxes.
This is about when phone rang. Gary told me that the CQWP didn't seem to work with the checkboxes. (NOTE: There had been about a month since we initially set these columns up and when the call came in). I checked it out and he was correct, the CQWP wasn't working.
Then it occured to me what was happening. The site column was originally created at the site collection level to support the filtering of the CQWP. We then created a document library and added our site column as metadata by clicking "Add from existing site column" -- this basically just makes a copy of the site column to the list. When Gary went in and changed the choice field to use checkboxes it essentially changed the data type. The CQWP was trying to apply a filter based on a single value choice field but the actual data in the field in the list was choice w/ checkboxes which caused an error.
The bottom line is, if you make a site column at the site collection level don't change it! You run a big risk of having fields of the same name with different types of data.
JR