Update to Bulk Edit Available (v1.2.0.23)

Bug fixes

  • When starting Bulk Edit it would be stuck with a message: “Loading…” indefinitely.
  • When changing a date custom field value the resulting value is sometimes the day before the selected date.
  • Clicking the Reload Data button could cause date picker fields to become un-editable.
  • With thousands of projects in the list scrolling could become corrupted resulting in display issues.


Open site contents in PWA to find the update link:

If you don’t see the update link, then open Details on the app tile to find it.

New features for Bulk Edit v1.2

A new version of Bulk Edit has been released and can be downloaded immediately from the app store! In this version I have implemented many of the most requested features and changed some of the old, so read ahead and try it out.

New Features

  • Save changes by row. Now by default all changes are saved one row at a time not and not one cell at a time.
  • Defer saving of all changes. Optionally you can apply changes only a button click, this allows for you to change many projects at once before applying any changes.
  • Improved localization. Dates and numbers now are shown in your locale format configured in PWA.
  • Force check-in button. A shortcut button has been added to open the force check-in page in PWA.
  • Per-user view changes saved. By default the last used field configuration will be displayed when you open Bulk Edit.
  • No more double-click to edit fields. Now clicking on any cell or tabbing to that cell will allow immediate editing.

Bug fixes

  • Sorting order of the custom field filter view is now alphabetical.
  • On initial load the app sometimes failed to load data and would be stuck “Loading…” indefinitely.


Open site contents in PWA to find the update link:

If you don’t see the update link, then open Details on the app tile to find it.

Update to Bulk Edit Available (v1.0.4.9)

A new version of BulkEdit is available now on the App Store, check site contents in PWA for the upgrade link to install it.

Bug Fixes

  • Fixes to non-English language users who see “Loading data” that never ends.
  • Fixes to some cases where custom field updates error with “Sorry the update failed, ensure that the project is not checked out”

Note: Some cases still exist where Bulk Edit does not detect which projects are checked out, and so will fail to update those fields. This appears to affect non-English Project Online users only, but if you see this please report it in the Support forum.

Additionally I am working on a workaround to address an issue which appears to cause approximately 1 in 5 Project Online field updates (ie Office365 JSOM API calls) to fail due to too many requests which the Microsoft servers cannot handle. The only workaround available at the moment is to retry. Fortunately this problem does not affect on-prem 2013 or 2016 Project Server customers.

If you are affected by this like most of my European Project Online customers are, then do what I do and speak to your Microsoft account manager (or customer’s account manager) about the poor performance of Project Online next chance you get! (feel free to quote me: Martin Laukkanen)


  • Updates to fully support Microsoft changes in Project Online API to support Project Server 2016.
  • New Welcome Screen for first time users.



Open site contents in PWA to find the update link:





Update to Bulk Edit Available (v1.0.4.4)

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

Bug Fixes

  • Updates to multiple fields in a single project failing without error.
  • Update to correct filter issue when values contain special characters.


Open site contents in PWA to find the update link next to the App Tile.

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

Updated 21st April: Re-released and updated to build

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:message xml:lang="en-US">An error occurred while processing this request.</m:message>

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 (ProjectWebApp@NB): 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)


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.