I’ve been following this thread since the beginning of the year. I work for an organization that is heavily impacted by this issue.
We are seeing projects with finish dates that can be pushed as far as 2076 (I did manage to reach the limit of 2146), with tons of assignments with 0 actuals in the future.
We developed a VBA macro that we use to cleanse the plans, but an action as simple as a timesheet update will destroy the schedule. As soon as an action that triggers a call to the scheduling engine is done, the plans become a mess…
As Daryl, we did a lot of research to determine whether it was poor scheduling practices, bad infrastructure, inconsistent project pro CU deployment across the various project users, bad language pack versions, etc etc
We’ve had a support ticket opened with Microsoft since February : at the beginning their conclusion was poor project planning…even though I pointed them to this discussion entry, it took a long time before they started changing their mind.
So about a month and a half ago, we were told that the May 2016 CU *might* correct our issue, but we’ve tested it as soon as it was released and it didn’t help, the problem could be reproduced very easily.
We then have been told about three weeks ago that the June 2016 CU will *this time* really target this/our specific issue. I find it hard to believe as they have been denying that the problem comes from the product, but everything is possible…
So let’s hope that this June 2016 CU fixes the problem once and for all…we did reach the same conclusion as Daryl, unchecking the “allow task splitting” does prevent the problem from happening, though I did manage to introduce 0s in the future even though the box was unchecked, might have just been a bad manipulation.
I’ll go back to this thread and post the results of our CU deployment tests as soon as the package is available, which should be next Tuesday.