OData error processing this request

I came across this while working with a customer and quickly found that the error triggers a known issue in my Bulk Edit app as well which was causing some unexpected errors using the app for some people, however this is a broader issue as it causes basic OData feeds to fail completely with the following message: Error message accessing /_api/ProjectData/Projects

<?xml version="1.0" encoding="UTF-8"?>
<m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
 <m:code/>
 <m:message xml:lang="en-US">An error occurred while processing this request.</m:message>
</m:error>

The problem can happen both on-prem or online but if you have access to the ULS logs you will see the following log entries (showing only the interesting bits):

Project Server Database agxfb Exception [bucketHash:7C60C52B] SqlException occurred in DAL ([email protected]): Class 16, state 1, line 1, number 8156, procedure , error code -2146232060, exception: System.Data.SqlClient.SqlException (0x80131904): The column ‘Campaignstatus’ was specified multiple times for ‘OdataSelect’. Project Server OData abljj High [Forced due to logging gap, Original Level: Verbose] PWA:http://nb/PWA, ServiceApp:Project Server Service Application, User:i:0#.w|blah\ml, PSI: Exception encountered when trying to instantiante the OdataResultItemCollection

As error logs go that is a pretty helpful one!

Cause  – Duplicate Custom Fields

The issue is caused by the Enterprise Custom Field configuration of the Project Server, specifically to looks like there are some duplicate named fields (Campaignstatus in my error above), now of course that is of course not possible! However when you look at the OData feed you can see that a few things happen:

  • Spaces are removed from field names; so e.g. Campaign Status becomes  CampaignStatus, etc.
  • Duplicate named fields (after space removal) are numbered, so for example you may see CampaignStatus1.

However there is a bug, OData is case-sensitive while SQL is not. So in my example above it seems that there are two fields the same name but with different cases, specifically I have the following two fields configured: Campaign Status and Campaignstatus. In my case if the second field was named CampaignStatus then this issue would not occur as it would have a number appended in the feed! (While this might sound a little esoteric actually I’ve already seen this a couple of times in German PWA instances where words are typically conjugated, etc)

Solution

Simple, either;

  • Rename the aforementioned field to something completely different (e.g.; Campaignstatus2), or
  • Recreate the field with different Case, e.g. in my example if I recreated the field Campaignstatus as CampaignStatus.

Note; renaming a field to a different case does not work(!), you need to recreate the field in order to regenerate the correct ‘cased’ Odata name.

Hopefully this bug will be fixed in a future service pack, but for now in Bulk Edit at least I have implemented a workaround anyway.

Share and Enjoy !

0Shares
0

Bulk Edit v1.0.4 Update

A new version of Bulk Edit is available from the App store, check your site settings for the upgrade link now to install it.

New Features

  • Project Owner Field editing support

Bug Fixes

  • Loading never finishes in some cases
  • Loading of projects is incomplete errors occur in the F12 script console

Installation

Open site contents in PWA to find the update link:

sitecontentslink

 

Finally if you use and love Bulk Edit, please rate it in the App Store!

Share and Enjoy !

0Shares
0

Bulk Edit update v1.0.3

A new version of Bulk Edit has been published just in time for the holidays, check your site settings for the upgrade link now to install it.

New Features

  • Mulit-select custom field Lookup Table values supported
  • SharePoint Task list mode Project custom field support
  • Support for updating the built-in Description field

Plus some bug fixes.

Happy holidays!

Share and Enjoy !

0Shares
0

Bulk Edit Update v1.0.2

A new version of Bulk Edit should be available to update any time now via the SharePoint store (check your Site Contents list for the update if you’ve already installed).

What’s new in v1.0.2?

  • Performance improvements loading field configuration.
  • Bug Fixes, specifically on first load and handling workflow controlled fields.
  • Permissions requirement change, no longer needs Site Collection admin rights to install. (How did that get in there?)

Re-installation will be Required Soon

Over the next week a completely new Bulk Edit package will roll out to the SharePoint Store, this will replace the old packaging requiring those with any previous version installed will (one day) have to re-install in order to get any future updates after v1.0.2. The reason for this is account related and unfortunately cannot be avoided so apologies in advance.

Update 05/11/13:

The updated Bulk Edit has been submitted to the app store and existing users may now see two versions of Bulk Edit in the store, although the old version of Bulk Edit will keep working as is for the future, in order to get future updates please check that you are using a version higher than v1.0.2.2.

Note: No change other than the publisher profile will happen for Bulk Edit, it will remain free and feature complete now and forever. This change is only required to consolidate Nearbaseline’s App store profiles so I apologize for this inconvenience.

Share and Enjoy !

0Shares
0

Bulk Edit Update v1.0.1

Just approved on the SharePoint App store is an update to Bulk Edit, if you’ve already installed then in the next 24 hours it should notify you of the update from Site Contents in PWA.

Go to the Bulk Edit page for Download and Support links.

What’s New in v1.0.1

  • Cut and Paste Support(!)
  • Improved non-English language support
  • Bug fixes

Please leave any feedback here or support questions in the Support Forum.

Also if you use / like this app then please review and rate it  it on the Microsoft App store!

Share and Enjoy !

0Shares
0