With the recently released Project 2007 and Project Server 2007 Service Pack 2 (SP2) along with the Project 2007 and Project Server 2007 April Cumulative update hopefully we have seen the last of the false “check-in pending” issues. It is obviously still possible that the project may really be not checked in – but the false message should be a thing of the past. And I am absolutely positive that we you will tell me if I am wrong! And there could still be a scenario we haven’t heard about that we need to fix – so do let us know.
As with all cache related problems you may still see an issue if your cache is already “bad”, so best to make sure all your projects are really checked in on the server, and delete your cache (from the OS, not just the menu item in Pro) to ensure all is good when you load these new updates.
***Update*** April CU contains the fix - http://blogs.msdn.com/brismith/archive/2009/05/01/project-server-2007-check-in-pending-laid-to-rest.aspx
*** Update *** Fixed in April CU - http://blogs.msdn.com/brismith/archive/2009/05/01/project-server-2007-check-in-pending-laid-to-rest.aspx
Perhaps I have a different problem, and perhaps a new path for you to invetigate.
When uploading a new job file (2500 tasks w/ 20 custom fields across 25 resources) to the project server, the queue reaches 96% in a few minutes then stalls there for 25 minutes before finishing. During this time, and even after the queue reports success, Project Pro still shows "waiting". Even after succesful transfers, during regular opens and closes of the file, the queue processor finishes, and the Project Pro completion banner does not change.
These events have been consistently problematic and have not changed after the latest updates.
If I cut the file down to 500 tasks or so, all works normally. As the file task count increases past about 1200 or so, so do the problems.
On another note, I really need control over "locking" the data presented on the "my tasks" page, or PWA is useless to us. The 2003 publishing method worked fine.
I'll see if we can repro this behavior with projects of that size - and I'll check what the significance of 96% is in the code. Generally the percentages relate to particular steps (93% is summary resource assignments for example) so the timing may not be linear to the percentages depending on the structure of the project.
Thanks too for the feedback on the publishing methods.
Brian and Berry,
I have the same issue. I have one file with 2,000 tasks and 12 resources and another with 600 tasks and 18 resources, both with 30 enterprise custom fields.
When I publish, both takes about two minutes to reach 96% than looks like they freeze, both on desktop and on server, but there is not any error message in the cue of the server. After about 20 minutes each one, they ended with success.
Is it possible to change the project to reduce this publishing time?
The % given when publishing will very rarely be linear, particulary when the project has a great number of task level custom fields. Reducing the task level fields will certainly reduce the publish time.
Not sure if this has been brought up, but i could use some help.
When a user checks in a file, it just freezes up on them. (MS Project that is) to the point of crashing and getting the famous "send error" dialogue.
Other times, after waiting for about 20 minutes, we go in through the Manage Queue and just cancel the job.
This seems to happen daily on a various files.
We do have SP2 installed. Any ideas?
If you did send the error then we may have an idea - the Watson Bucket number in your event log should help us track it down. I think the events you need to look for are 1000 and 1001.
I couldn't find a bucket number in the eventViewer. I might be doing something wrong, but I do have a couple of error messages from PWA:
Your ACProjectSave job failed. Its current state is Failed. It was 91% complete. It entered the queue at 03/29/2010 10:39:53.
To get more information about the job failure, please go to Project Web Access. Select Personal Settings from the left menu. Then select My Queued Jobs.
The errors returned from the queue are as follows:
Error ID: 1042
Error ID: 26000
Detailed error below - send it to the administrator for more detailed troubleshooting.
<?xml version="1.0" encoding="utf-16"?>
<error id="1042" name="ProjectHasNoWriteLock" uid="1524fcb4-12c2-44c1-b7a0-58c23cf50536" />
<error id="1042" name="ProjectHasNoWriteLock" uid="d2644c71-5e0b-4bb7-b9c7-d5b81076d367" />
<error id="26000" name="GeneralQueueJobFailed" uid="db1e2d6b-4995-446b-bf03-2e3973312f8c" JobUID="d299b327-d718-4b03-9acc-08d317b293e9" ComputerName="NBS-MSPPA" GroupType="ACProjectSave" MessageType="Byte" MessageId="134" Stage="" />
Hope this helps...
That would appear to indicate the project can't be checked out (no write lock). You will probably need to open a support incident to get one of our engineers to assist with this issue.
Hi Brian Smith
I am a big fan of your blog.
I work in a Danish company called Projectum and primarily work with Project Server 2003/2007 and 2010.
At the moment we have a large Danish customer called COOP
COOP use Project Server 2007, and we experience the same thing as described in the link
Typical projects have around 500 activities, 30 resources, and many outlinecodes on task and project level.
What I typically experience is:
- Queue stops at 93% when publishing
- When checked in projects, the queue stops at 37%
- Status update, the queue stop at 40%
I just wanted to hear whether there has been progress in this field, possible on a hotfix/CU or SP3 there
will rectify these things.
See you in Bareclona if you get there :-)
During last one week, many of the jobs have started failing. The job usually process successfully but sometimes fails randomly with state ‘Failed But Not Blocking Correlation’.
Whenever the job fails, it exactly fails at following percentage:
OLAP Cube Build --> 50%
Project Checkin --> 12%
Project Publish --> 96%
Project Publish Notifications --> 0%
WSS Workspace Create --> 0%
Can you please inform me that what can be the reason of failing these jobs?
Unfortunately, it is still very much alive in Project 2010.
Hi GRH, certainly interested to hear the circumstances when you still experience this - I'm sure there are still a couple of scenarios that can lead to this behavior.