Project with subproject saved on Sharepoint - external links are being added when opening two linked subuprojects RRS feed

  • Question

  • Hi together,

    First, some facts:

    1. There is an overall project with 5 subprojects, thos subprojects are inserted as Readonly in overall project
    2. Each subproject and main project file are stored as separate files within a directory structure in Sharepoint 2010
    3. Each file is in different Sharepoint directory (related to subproject)
    4. There are subproject tasks dependencies set as external link with full https://sharepoint/path/subproject.mpp\<task no> path
    5. All links are correct shown as grayed tasks within each of the subproject.
    6. I'm (as PMO) using MS Project 2013 Prof, rest of the Leaders Team is Using MS Project 2010 Standard

    Now my problem.

    When setting an external links i have to open subproject 1 and subproject 2 files and perform linking between those two via full path of the predecessor. For the first time when both files are saved, there is just single "grayed" task in the project which has dependecies to the other project.

    As the team leaders are working day to day with its plans, the version number of the mpp file in Sharepoint increase.

    When I'm opening the files again I can see additional "grayed" tasks for external link which i have put before. This end with multiple same external links for same task within the dependent project.

    Removing not needed connections helps just for next saving, but coming again when I'm opening the Projects and making additional change.

    As I have not found anywhere an answer for this behaviour, I would like to as this forum for reason and possible workaround to this problem.

    Best Regards


    Wednesday, September 14, 2016 6:52 AM

All replies

  • Firstly I'm surprised what you have works at all. Not at all surprised you are having problems. You should only ever link master files and inter-project links using files stored on local disk drives (local means same building) and NEVER rename, move or over-write any of the files without unlinking and saving first.

    When different versions share same files, it is essential that all copies of Project are fully updated at all times. Otherwise you will encounter unexpected behavior.

    Rod Gill
    Author of the one and only Project VBA Book and VBA developer.

    Wednesday, September 14, 2016 9:28 PM
  • Hi Rod,

    thanks for your answer.

    You wrote "using files stored on local disk drives (local means same building)", have you meant same network drive or physical hard drive of one computer?

    If this shall be same hard drive, how is it possible to synchronize work between multiple persons, if each working on different PC?

    In our case the files has been created as Empty Projects and stored in Sharepoint. Afterwards updates has been done on the files, which has NEVER change its path or name. It always stays as:

    https://<sharepoint site>/path/mainproject.mpp

    https://<sharepoint site>/path1/subproject1.mpp

    https://<sharepoint site>/path2/subproject2.mpp

    https://<sharepoint site>/path3/subproject3.mpp

    If this is not a use case supported by MS Project 2010 and 2013, where/how can I get official statement or documentation saying so?

    Best Regards


    Thursday, September 15, 2016 7:06 AM
  • Artur,

    Well as Rod surmised and I will confirm, you definitely have corruption. Part of your process is okay and part is not. The reason you have extra ghost tasks (greyed) when you open the files the second time is that links are multiplying because files are being renamed, moved, overwritten or saved off to another location. You indicate in your initial post that the "version number of the mpp files in SharePoint increase". By that I assume you mean the name of the file is "version stamped" each time someone edits it. That violates the first item above (i.e. do not rename). When you rename a file in a linked structure and then save it, links are normally transferred to the new file but links also still exist to the old file.

    You have a double linked structure. The first level is your dynamic master with inserted subprojects. The second level is inter-project links (i.e. task in one project linked to task in another project). With regard to the potential for corruption you have double jeopardy.

    The best chance for success with linked structures is for all files to reside in a single directory on a local drive. You increase the probability of corruption if files are in a single directory (e.g. SharePoint) but that directory in on a Server. The main problem is that server connections can and do have glitches and if one of those occurs during file edit or save, BOOM! the structure gets corrupted.

    The best way to eliminate the first part of the issue is to not use a dynamic master. A dynamic master can be very useful for creating inter-project links but once the links are set up, unlink the files form the master and delete the master. If you need to view all files together for reporting, create a static master (i.e. un-check the "link to project" option in the lower right corner of the Insert Project window). Note however, that inter-project links will not be preserved with this type of static master. In order to preserve the inter-project link structure, a macro is required. I have a macro (not freeware) that does that.

    So, to reduce (but not eliminate) the probability of corruption, you need to insure none of the rules about renaming, etc. are violated.

    And to answer your last question, no, the whole file corruption issue is not formally addressed in official Microsoft documentation, as far as I know. It is something that those of us who have worked with Project linked structures for many years have learned and developed the file discipline or workaround processes to avoid.


    Thursday, September 15, 2016 6:49 PM
  • Same building means any hard drive physically in the same building as your PC. Any further away and likelihood of network glitches increases and so file corruption.

    SharePoint saves different versions each time you save and this doesn't work well with links.

    I've used SharePoint just for saving individual Word files and as soon as the SharePoint servers were too far away, I had to download files (Word, Excel and Project) to my local drive before editing them then upload again afterwards. Linking files doesn't work reliably even on local drives. SharePoint will just greatly increase the likelihood of file corruption. As file corruption can happen weeks before unwanted symptoms appear, it isn't just a matter of having better backups.

    You'll have to search for official documents but much of the best practices we MVPs use is from long experience and the odd piece of advice from Microsoft people we liaise with.

    The only safe practice is to have unlinked master files created weekly.

    Rod Gill
    Author of the one and only Project VBA Book and VBA developer.

    Thursday, September 15, 2016 11:28 PM
  • Hi Guys,

    thanks a lot for your valuable answers.

    I think i have to find out how to manage staff without arguing the subprojects, as one machine is no option, eventually:

    1. I'll write a VBA Script which is unlinking old versions and linking the newest one or
    2. I'll move the files to networkdrive which is laying within the same builidng (and this would be hard, as whole infrastructure is spread around the country)

    I'll give you a note, how it is wotking when few weeks gone :)

    Have a nice day


    Friday, September 16, 2016 7:26 AM
  • Artur,

    You're welcome. Good luck with your process.

    Please note that you need to insure you save files after linking or un-linking to "capture" the change at both ends of the link (i.e. source and destination).


    Friday, September 16, 2016 2:09 PM
  • This is an essential feature for us too.  The ability to link tasks and create dependencies between projects saved in two different directories should not be something Microsoft has to scramble to accommodate given free project tools are catching up and can offer similar functionality. 
    Tuesday, April 10, 2018 8:09 PM
  • ChrisRyanL,

    Sorry but you are preaching to the choir. Those of us who respond on this forum are volunteers. We do not work for, nor are we associated with, Microsoft. I suggest you submit your request to the following:


    Tuesday, April 10, 2018 10:49 PM