none
losing flag settings RRS feed

  • Question

  • I am using Project Server V2010 SP1. 

    I updated a schedule on the Server via my laptop.  In addition to making some date changes, I made some changes to a user defined flag that drives a filtered view.  I saved and closed the file on my laptop and as far as I am concerned I saved it up to the Server.  I then opened the same file from my desktop machine.  The file is now hosed since somehow the Server dropped most, but not all of the flag settings that drive that view.  I then went back to my laptop and opened the file from the cache version and everything appears fine.  Figuring that this was an issue of the cache on the desktop machine, I cleared the cache on that machine.  This made no difference.  I then went back to the laptop and published the file.  Still no help.  I don't dare wipe the cache on the laptop for fear of losing everything I've built.

    We had a problem similar to this back in the spring and we applied a hotfix.  I thought the problem was resolved, but it appears to be back.  Stinking gremlins!

    Suggestions, anyone?

    Tuesday, October 16, 2012 4:33 PM

All replies

  • update: I saved the file to my H:/ drive while on the laptop, then went back to the desktop machine and successfully opened file without any corruption.  The only bad thing is that the file on the Server has hundreds of SharePoint links that will get lost if I use this other file as my new source.
    Tuesday, October 16, 2012 4:40 PM
  • Okay, I got a work-around, but am troubled that I don't understand why this happend, or how we develop a permanent fix.

    I saved the "correct" copy of the schedule that I saw on my laptop to a file which I saved to my H:/ drive.  I then opened the file on the Server from my desktop machine (where I saw the corruption).  I then opened the "correct" file from my H: drive, also from the desktop.  I then copied all table data from the "correct" file and pasted into the same columns on the Server version.  Saved and Published.  Verified that the file looked the same on my laptop.

    Clearly, there is an issue with synchronization of flag data with the Server from the cache.  You would have thought Microsoft would have solved this by now...

    Tuesday, October 16, 2012 6:06 PM
  • Hi Chris,

    sorry that you still run into this troubles. It really should be solved by some CUs in the past - after SP1. Can you check Client version on your desktop and your laptop? Are they the same and do they fit in some way to server's patch level? What is your patch level?

    Regards
    Barbara


    Tuesday, October 16, 2012 6:20 PM
    Moderator
  • Both the laptop and desktop are on 14.0.6123.5001.  I'm not sure how to check patch level.
    Tuesday, October 16, 2012 7:54 PM
  • Hi Chris,

    client seems to have CU 06/12 applied. In corresponding CU on server, a fix for cache issue was included (http://support.microsoft.com/kb/2598351), which seems to describe your issue? Ask your Project Server administrator, if it is already applied and if so, when it was done. Maybe your issue occured before applying this CU?

    Regards
    Barbara

    Wednesday, October 17, 2012 6:32 AM
    Moderator
  • Barbara -

    My apologies for the tardy reply.  I was in the final throws of a proposal when this cache disaster had hit.  I took a few weeks of vacation and am just now starting to get back into my ryhthm.

    My IT people told me that my laptop needed the following hotfixes:

    http://support.microsoft.com/kb/2596495

    http://support.microsoft.com/kb/2584056

    These fixes were applied.  I have cleared my cache and re-opened a table driven schedule, saved, cleared the cache, and re-opened without any loss of data so far.

    So far, so good.

    Chris

    Wednesday, December 5, 2012 12:25 PM
  • I got bit again this weekend.  I lost all text data from about 6 custom text fields (not all custom text fields).  I have also been in the practice of deleting the version from my cache each morning because there is a size creep that will eventually hammer performance and ultimately blow thru the cache size limit.  After waiting for over an hour for a restore to take effect I discovered that the restored version was missing the data, as well.  Fortunately, I had made a save to my C: drive before I went home for the night and that file is uncorrupted. 

    What is curious is the choice of columns that it decided to not synch from the cache to the Server... all the custom fields that were wiped were ones that were visible on the screen at the time.  The lone exception was a custom CWBS field (custom outline field) that we created that has a very complex lookup table.

    At this point, we are on the push for completing a proposal... I am going to stop using Server all together and just work off my C: drive with frequent saves to my H:.  I can't trust Server at this moment in time.

    Monday, April 1, 2013 2:17 PM
  • We have an instantiation that is seeing three different, but similar problems:

    1.) Task names will disappear from a schedule.  One of our users is seeing this in a schedule that isn't even on the Server. She has noticed that it is only happening for tasks that are subtasks --- never Summary.

    2.) Another user noticed that if he changed %Complete to another value it would wipe the task name

    3.) Another user is having a problem keeping local flag fields set to the desired state.

    We are currently investigating if CU 06/12 has been installed for this instantiation and set of users.

    Monday, August 19, 2013 2:35 PM
  • We have a user that is on v2010 with SP2 that is now seeing the problem.  This is really reflecting poorly on the quality of this product.  I have people that say we should switch to another project application, like Primavera, because of all the performance problems.
    Thursday, February 6, 2014 12:01 PM
  • now we have another user complaining about this problem.  He lost everything in Text20.  He is definately on v2010 SP2 and has been on that SP for a while

    Thursday, February 6, 2014 1:02 PM
  • We just determined that the reason that the user lost everything in Text20 was because the field got redefined as a blank lookup table.  This is the second time this week we have seen a user with a generic field being redefined as a blank lookup table.  We are not sure why this is happening.

    Thursday, February 6, 2014 2:12 PM