2

I migrated a SPS 2003 site collection to MOSS 2007 using database migration. There are already some document libraries in the SPWebs of the site collection. Some of the libraries are just the standard columns - Created, Modified, Checked out by and Title. The libraries don't have content type management enabled since they were migrated from 2003.

Here is the strange part - when I enable content type management on any document library (of this migrated site), all the existing columns in the library are getting associated with the Document content type, when I would have expected only the Title column (which is a Document content type column) to maintain its association.

In the same website, if I create a new document library and enable content type management, only the Title column is associated with the Document content type. No other column is automatically added, as with the libraries that were part of the migrated content.

How can I prevent the behavior exhibited by the migrated content?

5
  • 1
    In an attempt to try every possibility, I deleted the implicit Document content type (that's right, even if content type management was never enabled on a document library, there is a Document and Folder content type), enabled content type management and [had to] explicitly add the Document content type from the site content types. This seemed to resolve the problem, but I feel this is a hack more than a resolution. Thinking of opening a ticket with Microsoft.
    – Web User
    Nov 17, 2012 at 17:29
  • I think I have a much more elegant solution to the problem provided if you have support to run PowerShell? Nov 22, 2012 at 23:25
  • @FalakMahmood I have support to run PowerShell.
    – Web User
    Nov 23, 2012 at 20:44
  • Which version you can run on? 1.0 0r 2.0? Nov 24, 2012 at 13:39
  • PowerShell 2.0 (on Windows Server 2003 R2 with SP2)
    – Web User
    Nov 25, 2012 at 16:09

2 Answers 2

1

This behavior is actually by design and happens even in SharePoint 2010. I just created a new library, added two custom columns, and then turned on Content Type Management, and the two columns are automatically associated with Document.

The reason this is by design is simple - when you use content types in a list or library, the fields are only presented in the display/edit forms that are associated to that content type. If you have custom fields on a library when you change to Content Type Management, the Document type must include those fields, or they would not excluded from all of your existing documents and essentially any data in those fields would be wiped out or inaccessible.

I think you might be mixing up the Document site content type with the Document list content type. The associations you're seeing are happening to the library's instance of the Document content type, not the root itself. You can make other libraries and they won't get those fields added in. It sounds to me like you're concerned that when you enable Content Type Management in this library that it is modifying your core Document type for every list in the site, but I don't believe that to be the case based on your description.

I suppose the question that comes to mind is - why is this behavior a problem and what is the end solution that you have in mind?

2
  • I may not have understood this problem as well as I should have, from your response. Before migration, there were about 15 columns in the library. Since 2003 lacked content types, I used an external tool to populate the appropriate columns, depending on whether the item was a document or email. In 2007, this translates to having two content types - Document and Email. So after migration, I wanted to enable content types and add the Email content type (Document is auto added). Problem is, I wanted to selectively link some columns to Document and some to Email.
    – Web User
    Nov 19, 2012 at 23:11
  • I tried to replicate this problem with a new library created in MOSS 2007. Actually I don't see this behavior. Maybe user created columns get added to the Document content type, but not fields like Created By, Modified By and Checked Out To. In my case, even those fields are getting added to the Document content type. I can provide the list template based on the migrated library, and you will be able to replicate this problem.
    – Web User
    Nov 19, 2012 at 23:17
1

Programatically, you would solve it by creating a new item on the destination list, and here your determine what content type, the item should be, based on what the origin item type is.

In your scenario, where data is migrated from a legacy platform, you could use a classic migration tool to get all the data on your newer platform, placed in temporary libraries and lists, and afterwards transform the data to what you want.

One other hint... in case of migrating alot of data - a time consuming scenario, you should not rely on features to handle that job. There is an implicit timer in a feature that lasts for about two hours, and stops after that.

The solution to this problem is to move the code to a console application, where there are no timeout restrictions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.