SharePoint (and Project Server) Shenanigans

I recently had an issue at a client where the Project Center was failing to load and returning “An unknown error has occurred” on the page. We have seen this behaviour before and it’s usually some corrupt Project data that causes it, but I’ve never had the time to get to the bottom of the problem. Fortunately, today I had a bit more free time to investigate.

This particular issue is caused by custom fields that are linked single value (read: not multi-select) lookup tables erroneously getting multiple values assigned to them. How this occurs is as-yet unclear, but it appears to be symptomatic only in the published database – the draft and reporting databases are unaffected.

So, what’s the fix?

There are a couple of things that can be done, depending on your level of access and technical capability. Firstly, we need to identify the plans that are causing the issue. The fastest way of doing this is with a little piece of SQL code (change <Published_DB_name> to your actual Project Server published database name):

USE <Published_DB_name>
SELECT
(SELECT proj.PROJ_NAME FROM dbo.MSP_PROJECTS proj WHERE pcf.PROJ_UID = proj.PROJ_UID) as ProjectName
,(SELECT pcfv.[MD_PROP_NAME] FROM [dbo].[MSP_CUSTOM_FIELDS] pcfv WHERE pcfv.[MD_PROP_UID] = pcf.MD_PROP_UID) as CustomFieldName
,count(*)
FROM [dbo].[MSP_PROJ_CUSTOM_FIELD_VALUES] pcf
GROUP BY PROJ_UID, MD_PROP_UID
HAVING COUNT(*) > 1
ORBER BY ProjectName, CustomFieldName

(credit to Jan @ Piet Remen’s blog for the above query – http://pietremen.blogspot.co.uk/2012/01/project-centre-unknown-error-has.html)

This will return a list of projects, custom fields and the number of times that the custom field has been populated. If any project appears as an output of this script, you can view view the issue by taking a look at the Project Information through PWA. Affected custom fields will appear comma separated – e.g. Project Priority: Low, Low, Low, Low – where they should only appear as a single value.

The fix is quite a simple one – republish the project. This pushes the values from the draft database back to the published database and overwrites the broken custom field values. Check in PWA > Project Information, or re-run the above query to check that the plan is now fixed in the published database. I have seen a couple of instances where this did not fix the problem, and we had to delete the published version of the plan, and re-publish from the draft version.

It is still unclear how long the project will remain “fixed”, we have had a couple of plans reproduce the issue after being republished.

Microsoft have identified the issue, and released a fix, which can be found here: http://support.microsoft.com/kb/2598251

This KB is also included in the roll-up package (http://support.microsoft.com/kb/2597152) though it’s not documented.

These KB’s will prevent the issue occurring in the future, but will not fix existing problems – be sure to follow the above steps to ensure that the plans are fixed. As always – be sure you have database backups before applying updates!