Multiple TaskUIDs for one task in MSP_TimesheetLine_UserViewCF RRS feed

  • Question

  • Good morning,

    Each month, we export our actuals from EPM 2010 to the company ERP-system. Only actuals on tasks containing a valid financial code are accepted into the system. We created a custom task field for this (a text field, no look-up table). This month, we noticed that some actuals on a few projects were rejected because the custom field was empty. However, when we looked into the schedules, the fields weren't empty, the financial codes were all properly entered.

    So I did some querying to find out what was wrong:

    1. I made an Excel-query on MSP_TimesheetLine_UserViewCF, retrieving ProjectName, TaskName and TaskUID (among others);
    2. I made a separate query on MSP_EpmTask_UserView to retrieve the custom field for each task;
    3. In Excel, I added the custom field to each task using a vertical look-up with TaskUID as the look-up key.

    I found that in MSP_TimesheetLine_UserViewCF, some tasks have more than one TaskUID. The vertical look-up typically finds one TaskUID in MSP_EpmTask_UserView and returns the proper custom field, but the other TaskUID does not seem to exist in MSP_EpmTask_UserView, even though there are actuals on this task and the task still exists in the schedule.

    We have tried a few things to solve this:

    • Open and save the custom field in Server Settings (didn't work);
    • Republish the affected schedules (didn't work);
    • Withdraw the affected timesheets and resubmit. This works - maybe this is a clue? - but is not practical due to the sheer number of timesheets affected; also, some actuals don't survive the withdrawing process and need to be entered again - and who remembers what they did 4 weeks ago?

    I have a suspicion that "something" happened which causes protected actuals to remain in MSP_TimesheetLine_UserViewCF without a corresponding TaskUID in MSP_EpmTask_UserView (maybe a local save and subsequent overwrite on the server or something like that).

    So here are my questions:

    1. What do you think the cause is?
    2. How do I fix this (apart from resubmitting all affected timesheets)?
    3. How do I prevent this? My guess would be to add the custom field to MSP_TimesheetLine_UserViewCF but I don't know how to do that.

    Thank you for your help!

    • Edited by Richard T Wednesday, March 13, 2013 9:48 AM Legibility inproved
    Wednesday, March 13, 2013 8:11 AM

All replies

  • Hi,

    Project Server uses internally two different TaskUIDs: TASK_UID and TASK_PUBLISHED_UID (see Published Db: MSP_TASKS_SAVED). In most cases you can rely on the AssignmentUid if the mapping of the TaskUids lets you down. If the issue only occurs in the Reporting Db you can also force a rebuild by backing up the custom fields and restoring it (RDBRefresh).

    I would strongly recommend filing a support case with Microsoft to further investigate this: Please note that Mircrosoft will not charge your for cases regarding bugs


    Renke Project Management with MS Project - Oldenburg, Berlin, Munich/Germany

    • Proposed as answer by Renke Holert Sunday, March 17, 2013 7:03 PM
    Sunday, March 17, 2013 7:02 PM
  • Thank you for this information, Renke. I have asked our DB-people to look into the back-up and restore option for now. Later this month we shall apply the latest CU, hopefully this issue will disappear then.
    Monday, March 18, 2013 7:54 AM
  • Hi Richard,

    what was the result?


    Renke Project Management with MS Project - Oldenburg, Berlin, Munich/Germany

    Sunday, April 7, 2013 4:28 PM