Is this a bug with SharePoint Column/Field internal names in MOSS 2007

Question

There seems to be a bug with columns in SharePoint MOSS 2007.

It allows you to add a new column say 'Team'. When you add this it stores the internal name as 'Team' which makes sense. The business then decide that 'Team' should be called 'Workstream', so you rename it as requested. The internal name remains 'Team' for this column in the root site collection.

A user then adds a new site column to a sub-site called 'Team' and uses this in various content types. You now have two columns or fields with the same internal name 'Team'.

I've now been asked to export and import the whole site collection to another server. When I do this stsadm.exe tells me that it has found a duplicate column and errors out.

I can't delete either column as they in are in use in various content types.

Can anyone suggest an approach to fix this?

Answer 1

It sounds like a bug, and I don't know any way around it off the top. I don't believe there is anyway to change a column's internal name.

Here are some thoughts I have:

You may want to look into a 3rd party miration tool such as metalogix, it may ultimately be easier and more cost effective than spending the time to write custom code for a one-off migration project.

If you can break the sites out onto different site collections on the new server that should solve the problem.

Maybe you can backup and restore the content database to the new server, and then attach to it.

good luck

Answer 2

The trick is to only add columns using an xml schema instead of using the front end. Usually I would do this using a solution/feature, containing all of the field definitions and content types.

As you already have the content types added, you may need to use a tool like SharePoint manager to look at the schema xml and introduce a new one. This gives more control of the exact definition for any fields.

There can never be two fields with the same internal name. We have had issue when fields have been defined on the site using the /_layouts/settings.aspx and also at the list level. As far as I can tell, when a site restores, it tries to add any fields from the list or subsite level into the base site (alert: opinionin formed only by looking at log errors and trial and error rather than actual facts) and this is where it seems to fail. Making sure that all the fields are defined in a consistent way using the Schema xml (easiest to do with a feature defining the content types) may help iron out the issues. I.e. all fields of the same "name" have the same guid name etc in all sites.

Note: We have also had issue with cross site queries after manually adding fields. The query code has some bugs (I believe it is on the MS stack to be fixed) that mean it relies on fields being defined in a certain order on the underlying tables.