Project Server 2010: Take care changing custom fields to allow multiple values

One of the options when setting up a custom field is to allow it to have multiple values selected from the lookup table.  There are however some downsides to this, and a recently discovered bug makes one of these downsides a higher risk than it should be.  This relates to OLAP cubes – and the fact that custom fields with the ability to select multi values cannot be added to cubes.  First a reminder of where this value is set:



Problems begin when you wish to change this later to a multiple value option custom field – and it is already in a cube configuration.  The exact nature of the problem will depend on whether your data was migrated to Project Server 2010 from an earlier version or not – and if so, if the custom field was already added to the cube. 

I’ll deal with the case of migrated/upgraded data first.

If you select the check-box for a field that was included in a cube before you upgraded to 2010 then try and save you will get the following message – regardless of whether the field is in a cube currently or not.

The custom field could not be saved due to the following reason(s):

  • "The selected custom field is currently part of one or more Project Server OLAP cubes and the change requested is not supported by the cubes. Select a valid setting or remove the custom field from the OLAP database(s)."

There is no way to make the change, as the validation checking that it isn’t in a cube is not working correctly in 2010.  If you are in this situation and really, really want to make this change then best open a support incident.  Remember – the change from single to multiple value selection is NOT REVERSIBLE!  So please be very sure you want to make the change.  In this case even deleting the cube will not help.

For brand new 2010 installations the root of the problem is the same, but with different results.  If your custom field has been added to a cube configuration and you then choose to allow multiple values then the validation will think everything is OK, and that your field is not in a cube when it actually is.  This will mean that the save of the change will succeed.  If you view the cube configuration it will look like the field has been removed – whereas in fact it has just been filtered out as it is now multi-value.  The end result is that you never got the warning – you didn’t get the chance to reconsider if you could live without this field in the cube – or if you really needed multi-value – and to top it all your cubes will no longer build.  The error will be something like

Failed to build the OLAP cubes. Error: InitCustomFieldDimensions cannot process the Project custom field ‘ProjectColours’

There are a couple of workarounds though, depending if you are reading this having hit the problem – or lucky enough to see it while still thinking about making such a change.  If the field is removed from any and all cubes that it is included in BEFORE making the change to multiple value then all will be OK (but as mentioned – only for new 2010 systems – upgraded ones will get the error above).  If you already hit the issue then the easiest option would be to delete the cube and build a new one – but this doesn’t help if you really decided you couldn’t live without this data in the cube…  Also you can’t delete the default cube – so you may need to create another cube – delete the first one and then rename the second one back to the same name as the first.

Another option in either case would be to create another custom field and let that one have multiple values – leaving the original one exactly as it was.

No current dates I can give you for a potential fix, but as mentioned earlier – log a call with support if you have run in to this – no charge as it is a bug.