Spooler Error 0x80004005 - URGENT, this is NOT authentication related

[ITG_Mike]

I get this error in Project 2003 and Project Server, however it is not an authentication problem as the MS reports in the KB articles. It appears that the error is caused by a duplicate record in the web assignments table. You can create this error in either of two ways:

1)
Create a project with at least one task.
Build a team that includes a resource (it can be you - I used myself in this example)
Assign yourself to the task
Save the project to the server, but do not publish it

Now go to your tasks and "Assign myself to an existing task".
Select the project and task that you just created
enter some time and update the task

Now, when you go back into MSP and try and publish the project, you will get the spooler error since you (the resource) have two assignments on the same task - the assignment you created in Project as the Project Manager and the assignment you created in tasks as the resource on the project.

2)
I can also cause this same error by hiding a task in my timesheet and then re-adding it (as above). This situation is even more problematic as the hidden task may have actuals in the project.

So here are my questions:

1) How does one get rid of these conflecting assignments so the project can again be published without errors?
2) How do we keep these problems from re-occuring? It seems like there should be a check to ensure that duplicate records are not being added before the operation to add an assignment is accepted.

This is turning into a HUGE issue for us as we have 200 resources and 150 projects and we can't simply tell people to "not do" certain actions.

Michael
england at itgssi . com

 

[Gary L. Chefetz [MVP]]

Mike:

I'm looking into this issue for you.

I get this error in Project 2003 and Project Server, however it is not an

authentication problem as the MS reports in the KB articles. It appears
that the error is caused by a duplicate record in the web assignments table.
You can create this error in either of two ways:

1)
Create a project with at least one task.
Build a team that includes a resource (it can be you - I used myself in this example)
Assign yourself to the task
Save the project to the server, but do not publish it

Now go to your tasks and "Assign myself to an existing task".
Select the project and task that you just created
enter some time and update the task

Now, when you go back into MSP and try and publish the project, you will

get the spooler error since you (the resource) have two assignments on the
same task - the assignment you created in Project as the Project Manager and
the assignment you created in tasks as the resource on the project.

2)
I can also cause this same error by hiding a task in my timesheet and then

re-adding it (as above). This situation is even more problematic as the
hidden task may have actuals in the project.

So here are my questions:

1) How does one get rid of these conflecting assignments so the project

can again be published without errors?

2) How do we keep these problems from re-occuring? It seems like there

should be a check to ensure that duplicate records are not being added
before the operation to add an assignment is accepted.

This is turning into a HUGE issue for us as we have 200 resources and 150

projects and we can't simply tell people to "not do" certain actions.

 

[ITG_Mike]

Further clarification. First, while I am sure that I got this error (0x80004005) before using the steps I described, I just walked through this again an

1) Received a different error: 0x80040E1
2) Also needed to enter time after doing the "assign myself to an existing task" step, update the task, and then accept the submisssion (as the project manager) in order to get the (new) error

In either case, there really seems to be a problem with duplicate assignments when both the resource and the project manager assign the resource to the same task

Michael

 

[ITG_Mike]

Here is an even easier way to generate this 0x80040E14 problem.

WARNING - Do not do this on a project you want to keep. It will be messed up when you are done.

1) Go into your tasks.
2) Hide a task
3) Go into "Assign myself to an existing task"
4) Add the same task back that you hid in Step 2
5) Enter some time and then update the task

When the project manager approves the time and then updates the project, they will get an error in PWA. From that point forward, attempting to republish assignments in the project will generate the spooler error 0x80040E14.

Even if the project manager figures out what happened and subsequently rejects this task assignment which caused the duplication, the project cannot be republished without generating an error. The DB record the resource created when making this duplicate assignment remains and screws things up from that point forward.

Michael

 

[Brian K - Project MVP]

Here is an even easier way to generate this 0x80040E14 problem.

WARNING - Do not do this on a project you want to keep. It will be
messed up when you are done.

1) Go into your tasks.
2) Hide a task
3) Go into "Assign myself to an existing task"
4) Add the same task back that you hid in Step 2
5) Enter some time and then update the task

When the project manager approves the time and then updates the
project, they will get an error in PWA. From that point forward,
attempting to republish assignments in the project will generate the
spooler error 0x80040E14.

Even if the project manager figures out what happened and
subsequently rejects this task assignment which caused the
duplication, the project cannot be republished without generating an
error. The DB record the resource created when making this duplicate
assignment remains and screws things up from that point forward.

Michael

The real key here is a training issue for your users. (In the mean time
until there is code that stops them from doing this).

The way to get a task back on your timesheet is NOT to assign yourself
to it. It is to ask the PM to republish the assignment.

Sure this is not optimum but for now it is just what you have to do.

If you do not feel that you can get your resources to remember his you
can remove their ability to hide tasks in their group permissions.

 

[ITG_Mike]

Brian,

I am getting the same message from MS - "Just don't do this". The problem is that most users are not experts and even if trained can forget or make a mistake. I do not need to tell users not to jump from a building, that is clearly something that they know will cause a problem. However, the "Assign myself to an existing task" function is something they were trained to use, and they use regularly. There is no way for the user to tell when this is going to cause them a problem.

I believe there is a fundamental flaw in the operation of the "Assign myself to an existing task" dialog. There are two cases where this dialog allows a user to add an assignment that will result in a database error down the road:

1) If a project with resources assigned to tasks has been saved, but not published
2) If a resource has hidden a task

In both of these cases, the resource can select a task in the "Assign myself..." dialog when they are already assigned. This will lead to an error.

Both of these situations could be avoided if this "Assign myself" dialog was smarter.

In case #1 (where a project has been saved with assignments but not yet published), if a resource is already assigned to a project (verified on the MSP side of the database, not on the Web side), do not make the assignmnet. Pop up a dialog "Your manager has already assigned you to this task, but has not published the assignment".

In case #2 (where a resource is adding a task assignmnet they they previously hid), simply unhide the assignment. This would be nice anyway as it allows a hidden assignment to be recovered without the project manager republishing the schedule.

In the mean time if you allow users to self-assign to tasks, I suggest all project managers turn on the option to "publish new and changed" on every save for every project.

BTW does anyone know where this "Publish on save" setting is stored in the Database? I would like to force it on for all of our existing projects.

 

[Brian K - Project MVP]

Brian,

I am getting the same message from MS - "Just don't do this". The
problem is that most users are not experts and even if trained can
forget or make a mistake. I do not need to tell users not to jump
from a building, that is clearly something that they know will cause
a problem. However, the "Assign myself to an existing task" function
is something they were trained to use, and they use regularly. There
is no way for the user to tell when this is going to cause them a
problem.

I believe there is a fundamental flaw in the operation of the "Assign
myself to an existing task" dialog. There are two cases where this
dialog allows a user to add an assignment that will result in a
database error down the road:

1) If a project with resources assigned to tasks has been saved, but
not published 2) If a resource has hidden a task

In both of these cases, the resource can select a task in the "Assign
myself..." dialog when they are already assigned. This will lead to
an error.

Both of these situations could be avoided if this "Assign myself"
dialog was smarter.

In case #1 (where a project has been saved with assignments but not
yet published), if a resource is already assigned to a project
(verified on the MSP side of the database, not on the Web side), do
not make the assignmnet. Pop up a dialog "Your manager has already
assigned you to this task, but has not published the assignment".

In case #2 (where a resource is adding a task assignmnet they they
previously hid), simply unhide the assignment. This would be nice
anyway as it allows a hidden assignment to be recovered without the
project manager republishing the schedule.

In the mean time if you allow users to self-assign to tasks, I
suggest all project managers turn on the option to "publish new and
changed" on every save for every project.

BTW does anyone know where this "Publish on save" setting is stored
in the Database? I would like to force it on for all of our existing
projects.

Sure there is a problem with the process but until it gets fixed the
users will need to make an adjustment. Is that the best case scenario?
for sure no. But is it the way it has to be for NOW? Yes. For now both
the PMs and the resources will need to pay more attention.

The most common way this will happen can be stopped if you disallow
hiding tasks from the timesheet.

By the way, email me your MS case number.

 

[Gary L. Chefetz [MVP]]

Mike:

I completely agree with you; this is not a training issue. This is design
issue. Using the publish new and changed strategy on every save may have
some unwanted consequences as well. You'll need to tell your PMs to turn
this off while they're making extensive changes over a period of days so as
not to blast out false assignments and you should also instruct them to turn
Auto Save off while publish on every save is turned on; otherwise they may
find the pauses very interrupting.

Brian,

I am getting the same message from MS - "Just don't do this". The problem

is that most users are not experts and even if trained can forget or make a
mistake. I do not need to tell users not to jump from a building, that is
clearly something that they know will cause a problem. However, the "Assign
myself to an existing task" function is something they were trained to use,
and they use regularly. There is no way for the user to tell when this is
going to cause them a problem.

I believe there is a fundamental flaw in the operation of the "Assign

myself to an existing task" dialog. There are two cases where this dialog
allows a user to add an assignment that will result in a database error down
the road:

1) If a project with resources assigned to tasks has been saved, but not published
2) If a resource has hidden a task

In both of these cases, the resource can select a task in the "Assign

myself..." dialog when they are already assigned. This will lead to an
error.

Both of these situations could be avoided if this "Assign myself" dialog was smarter.

In case #1 (where a project has been saved with assignments but not yet

published), if a resource is already assigned to a project (verified on the
MSP side of the database, not on the Web side), do not make the assignmnet.
Pop up a dialog "Your manager has already assigned you to this task, but has
not published the assignment".

In case #2 (where a resource is adding a task assignmnet they they

previously hid), simply unhide the assignment. This would be nice anyway as
it allows a hidden assignment to be recovered without the project manager
republishing the schedule.

In the mean time if you allow users to self-assign to tasks, I suggest

all project managers turn on the option to "publish new and changed" on
every save for every project.

BTW does anyone know where this "Publish on save" setting is stored in the

Database? I would like to force it on for all of our existing projects.

 

[Brian K - Project MVP]

Mike:

I completely agree with you; this is not a training issue. This is
design issue. Using the publish new and changed strategy on every
save may have some unwanted consequences as well. You'll need to tell
your PMs to turn this off while they're making extensive changes over
a period of days so as not to blast out false assignments and you
should also instruct them to turn Auto Save off while publish on
every save is turned on; otherwise they may find the pauses very
interrupting.

In the larger sense it is a design issue. BUT(!), until they fix this
it is a training issue. We know there is a problem that can arise fro a
set of actions. If you take these actions something bad will happen. So
as good administrators it is our obligation to train our users to avoid
doing the actions that will cause the bad thing to happen.

This does not mean that the issue should not be addressed from a
product standpoint. But it means that until it does get addressed we
need to training users to stop doing certain things.

 

[ITG_Mike]

Gary, Brian,

I agree with both of you. It is a real bug that needs to be fixed. The bug causes HUGE problems with data corruption. You can train people to reduce the number of failures and we will do this

Brian, my concern with your statement "We know there is a problem that can arise from a set of actions" The problem with attempting to train around these actions is that the exact same actions work in some cases and cause a problem in others. The user is doing the same thing in either case. The manager is doing the same thing in either case. The problem lies in the ordering of these actions.

I don't think we can train managers to verify what their resources have done before each time they modify a schedule. That is what would need to happen to completely avoid this problem.

Michael

 

[Brian K - Project MVP]

Gary, Brian,

I agree with both of you. It is a real bug that needs to be fixed.
The bug causes HUGE problems with data corruption. You can train
people to reduce the number of failures and we will do this

Brian, my concern with your statement "We know there is a problem
that can arise from a set of actions" The problem with attempting to
train around these actions is that the exact same actions work in
some cases and cause a problem in others. The user is doing the same
thing in either case. The manager is doing the same thing in either
case. The problem lies in the ordering of these actions.

I don't think we can train managers to verify what their resources
have done before each time they modify a schedule. That is what
would need to happen to completely avoid this problem.

Michael

Well in reality if they are happening in differnet orders then they are
not the same actions. But that is a technicality.

In the mean time you need to decide who will assign resources to your
tasks: PMs or resources. Picking one will also solve the problem in the
short term until a fix is available. I know this is not optimal but it
would seem a better choice then taking the chance of the issue
happening.

 

[Gary L. Chefetz [MVP]]

Mike:

The project managers actually *can* see what the resource has done by using
Resource Center views, even before they send an update.

Gary, Brian,

I agree with both of you. It is a real bug that needs to be fixed. The

bug causes HUGE problems with data corruption. You can train people to
reduce the number of failures and we will do this

Brian, my concern with your statement "We know there is a problem that can

arise from a set of actions" The problem with attempting to train around
these actions is that the exact same actions work in some cases and cause a
problem in others. The user is doing the same thing in either case. The
manager is doing the same thing in either case. The problem lies in the
ordering of these actions.

I don't think we can train managers to verify what their resources have

done before each time they modify a schedule. That is what would need to
happen to completely avoid this problem.

 

[Guest]

HI All,

I finally found the error number i have been getting.
Spooler Error 0x80040E14.

I have read all in this conversation but i cant find a
resolution to the problem. How to i get to republish this
project plan. Would i need to delete and re-import?