none
How can I deactive Calculations for Subprojects in a Master Project (won't deactivate using calculation = pjManual RRS feed

  • Question

  • I have a macro that runs on an event to verify and set information on a task level. Prior to setting the information, it sets calculation = pjManual for the application and previously this would allow the macro to complete in seconds.

    Following one of the initial service pack updates to MS Project, I found that calculations would remain active for subprojects and there doesn't appear to be any way of deactivating them and now the macro takes substantially longer and in some cases won't finish for hours (in cases where it was previously possible in less than a minute). It appears that a "fix" was initiated that has no work around to disable calculations for subprojects. This has effectively prohibited our organization from moving forward using our master project files.

    Monday, November 21, 2016 3:45 PM

All replies

  • Luis,

    Which version of Project are you using? What is the update level?

    There are two ways to control calculation. One is via the Application.Calculation Property, which is the one you are using. The other is the Application.OptionsCalculation Method. You might want to try the latter to see if it works for you.

    Since both the property and method are at application level, either should work but apparently that's not quite the case. You say calculation remains active for subprojects. It may seem like a lame question but how do you know that? If you stop execution after an update to a subproject task and open that suproject, did the update cause a calculation? If you go to File > Options > schedule group from that subproject, is the calculation option "On" or "Off"?

    If indeed this is an issue caused by an update, I can report it to Microsoft but in order to do that I need to have answers to all the above questions and I may need some additional information.

    John

    Monday, November 21, 2016 4:24 PM
  • John,

    Thanks for the prompt response. We are using MS Project 2013. The issue was observed over several cumulative updates, but I currently have 15.0.4875.1000

    It doesn't strike me as a lame question at all as it took some digging to understand the issue: the application setting doesn't change, so I had to walk through the macro step-by-step until I saw what was calling the delay. When the macro populates a task field (in our case a custom project server task field), all of the scheduling calculations associated with it would occur and the simple population of one field would take several seconds where in early project versions, the process was relatively instant. It is my belief that this issue is the result of a previous attempt to fix an issue where subproject information wasn't calculating but haven't been able to confirm this assumption.

    I will try the OptionsCalculation method, but believe as you do that it likely won't make a difference.

    Best Regards,

    Luis

    Monday, November 21, 2016 5:37 PM
  • Luis,

    Does this happen when connected to Server or does it also occur at client level? I don't use Project Server so if it's related to that environment I won't be able to offer much help.

    If you believe it was caused by an update, it would help to isolate with which update you first noticed the problem. The following blog might help:

    https://blogs.technet.microsoft.com/projectsupport/p/msp13

    John

    Monday, November 21, 2016 11:35 PM
  • John,

    Tried the OptionsCalculation method with no success. Then did some additional testing:

    Exported the file as a local mpp file and tried to run the macro while logged into the server and the performance was still slow/unable to complete.

    Added the macros to my global.mpt and attempted the macro while working locally (not logged into the server or working offline) and found that the performance was markedly faster and back to less than a minute for the given file.

    This lead me to the conclusion that it was somehow related to working while logged into the project server environment. At this point I tested the performance of storing in an enterprise field vs storing information in a local field using a standalone file (not a master), the result even without an IMS was that the performance in storing information into an enterprise field took 33% longer than that of a local field. NOTE: I didn't perform this test on a master file as the performance is so poor that I didn't want to lose that much time.

    I tried pinpointing the point at which the IMS calculations began to slow down and was unsuccessful as it was a long time ago and didn't have a good way of referencing it. In reviewing the list of CU updates that you sent, I believe that it may have been 15.0.4737.1001, but can't be sure.

    Any additional suggestions or do you know of another good point-of-contact that might be more familiar with project server?

    Thursday, February 9, 2017 2:29 PM
  • Luis,

    Wow, it's been a while.

    As I mentioned in an earlier response I do not do Project Server so I can't help you in that environment. I also do not have Project 2013, I only have Project 2010 Pro. However, I ran the following macro on a test file I have (1000+ tasks) with the results as shown in the screen shot. There is no significant difference between accessing local or enterprise fields at client level.

    As far as other suggestions, no I don't have any and this is the best forum for posting your issue. Hopefully someone else will jump in who has Project Server expertise. Sorry I can't be of more help.

    John

    Thursday, February 9, 2017 4:36 PM
  • As a workaround, can you remove all sub-projects from the master and then run the code on projects individually before re-creating the master at the end? What do you need the master for? Often in Project Server there are cross project reports you can create without needing a master file at all?

    If you can describe more about what you want to achieve we might be able to come up with a better workaround.

    The EnterpriseTextn fields etc are old fields for Project Server 2003 compatibility so are not a true test for project server fields in 2010+


    Rod Gill
    Author of the one and only Project VBA Book and VBA developer.
    www.project-systems.co.nz

    Wednesday, February 15, 2017 10:42 PM
    Moderator