First published on TECHNET on Feb 13, 2014
I thought this Project Server 2010 issue with categories was worth a blog post just in case other people are seeing it. The symptom is that you edit a category (Server Settings, Manage Categories), then add extra projects or resources, or views – click Save - and then you find that they were not added! One tell tale sign that it hasn’t worked is that the save appears to happen very quickly rather than taking a few seconds to respond (we are talking big categories here). Re-opening the category will show that none of the additions happened. No error is thrown. The problem will only happen when you have very large numbers of projects and resources added to the category – and it isn’t an exact number – but will be around 13,000 total items.
In my investigations I used Fiddler and could see an error returned from the web service call to <PWARETURN><DATA ID="idError">-1</DATA><DATA ID="idMessage">Error</DATA></PWARETURN> when the content length was around 510 to 520K. It is possible to overcome this by editing the web.config of the PSI web services and adding a specific value for httpRuntime maxRequestLength – but as this is an untested scenario this would be considered ‘unsupported’. The best workaround would be to use another category – basically a mirror of the failing one – to add the new projects and resources as required. The usual scenario we have seen where this can happen is for ‘archiving’ plans – where you want to deny access but keep them in the system. This can obviously grow quite large and the workaround of having a second (or third) category should be workable. In other scenarios, perhaps where automation is involved in populating the categories, this may not be as useful a workaround – so apologies if this is your scenario.
You might be thinking why does this give such a high content-length if I am only adding one plan to the category? In fact a change actually re-writes the entire category with the plans, resources and views – so we are sending quite a bit of data back. I guess this was seen as easier and possibly more efficient than doing a diff of the changes you had made to the category in the web dialog.
This isn’t something that will likely get fixed anytime soon – and if we do fix it the likely solution would be to handle the error properly rather than extend the capacity of the category. The good news is that this doesn’t occur at the same levels for Project Server 2013 – I have successfully added 30,000 items to a Project Server 2013 category.
Thanks to Shirene and Subhadip for their patience as we investigated this one – and sorry we didn’t get a chance to meet up at the Project Conference – maybe next time?
I thought this Project Server 2010 issue with categories was worth a blog post just in case other people are seeing it. The symptom is that you edit a category (Server Settings, Manage Categories), then add extra projects or resources, or views – click Save - and then you find that they were not added! One tell tale sign that it hasn’t worked is that the save appears to happen very quickly rather than taking a few seconds to respond (we are talking big categories here). Re-opening the category will show that none of the additions happened. No error is thrown. The problem will only happen when you have very large numbers of projects and resources added to the category – and it isn’t an exact number – but will be around 13,000 total items.
In my investigations I used Fiddler and could see an error returned from the web service call to <PWARETURN><DATA ID="idError">-1</DATA><DATA ID="idMessage">Error</DATA></PWARETURN> when the content length was around 510 to 520K. It is possible to overcome this by editing the web.config of the PSI web services and adding a specific value for httpRuntime maxRequestLength – but as this is an untested scenario this would be considered ‘unsupported’. The best workaround would be to use another category – basically a mirror of the failing one – to add the new projects and resources as required. The usual scenario we have seen where this can happen is for ‘archiving’ plans – where you want to deny access but keep them in the system. This can obviously grow quite large and the workaround of having a second (or third) category should be workable. In other scenarios, perhaps where automation is involved in populating the categories, this may not be as useful a workaround – so apologies if this is your scenario.
You might be thinking why does this give such a high content-length if I am only adding one plan to the category? In fact a change actually re-writes the entire category with the plans, resources and views – so we are sending quite a bit of data back. I guess this was seen as easier and possibly more efficient than doing a diff of the changes you had made to the category in the web dialog.
This isn’t something that will likely get fixed anytime soon – and if we do fix it the likely solution would be to handle the error properly rather than extend the capacity of the category. The good news is that this doesn’t occur at the same levels for Project Server 2013 – I have successfully added 30,000 items to a Project Server 2013 category.
Thanks to Shirene and Subhadip for their patience as we investigated this one – and sorry we didn’t get a chance to meet up at the Project Conference – maybe next time?
Published Mar 06, 2019
Version 1.0
