Task ID assignment for external dependencies

[Shawn Pollack]

I'm trying to understand how Project 2003 processes the "ghost" tasks created
when there is an external dependency.

When things work as I expect, the ghost task for the external predecessor
appears immediately above the the linked task. That is, its task ID one less
than the task ID of the task it is linked from. Similarly the ghost task for
the successor is immediately after (task ID + 1) the linking task.

Unfortunately, this is not alway the case. Sometime Project chooses a task
ID for the ghost task that is no where near the linking task.

I've been trying to find a pattern in how Project assigns the task ID of the
"ghost" task, but I've not been able to figure it out yet. I've looked at
the UniqueID, and so far I've not been able to discrern a pattern but it does
appear to work better when the Task IDs are in the same sequence as the
UniqueID.

The context is that I have several mpp files that are linked together
through one intermediary "linking" file. All of the tasks in the linking
file are milestones (zero duration) and have one predecssor and one successor
in some other file. For the most part, the ghost tasks appear next to the
tasks that are linked to, but not always. I've found using the linking file
make the management of external dependencies much easier and reliable. But
the linking file would be much that much easier to manage if there weren't so
many cases where extraneous ghost links are in the wrong place.

Might this be a bug that can/should fixed? I'm hoping that if I could
understand better how Project assigns the task ID to the ghost tasks, I might
be able to work around my issue.

Shawn

 

[John]

I'm trying to understand how Project 2003 processes the "ghost" tasks created
when there is an external dependency.

When things work as I expect, the ghost task for the external predecessor
appears immediately above the the linked task. That is, its task ID one less
than the task ID of the task it is linked from. Similarly the ghost task for
the successor is immediately after (task ID + 1) the linking task.

Unfortunately, this is not alway the case. Sometime Project chooses a task
ID for the ghost task that is no where near the linking task.

I've been trying to find a pattern in how Project assigns the task ID of the
"ghost" task, but I've not been able to figure it out yet. I've looked at
the UniqueID, and so far I've not been able to discrern a pattern but it does
appear to work better when the Task IDs are in the same sequence as the
UniqueID.

The context is that I have several mpp files that are linked together
through one intermediary "linking" file. All of the tasks in the linking
file are milestones (zero duration) and have one predecssor and one successor
in some other file. For the most part, the ghost tasks appear next to the
tasks that are linked to, but not always. I've found using the linking file
make the management of external dependencies much easier and reliable. But
the linking file would be much that much easier to manage if there weren't so
many cases where extraneous ghost links are in the wrong place.

Might this be a bug that can/should fixed? I'm hoping that if I could
understand better how Project assigns the task ID to the ghost tasks, I might
be able to work around my issue.

Shawn

Shawn,
Why the new post? We've discussed this issue before. Did you try
breaking and re-establishing the out of sequence links as I suggested?

However, your intermediary "linking" file is a bad idea. On the surface
it looks good, but my experience with other users who use this same
technique is that the structure tends to develop file corruption and/or
create circular relationships. In my opinion, the most stable inter-file
links are those that are direct file-to-file and "forward-pass" only.

If you want a master file so you can see all subprojects at once, that's
fine, just don't run the link through the master unless it actually
links to a performance task (i.e. not a milestone) that is part of the
master. You will have a cleaner, more stable structure and it may just
resolve your "issue".

John
Project MVP

 

[Shawn]

Thank John -

I have been using the linking file technique with good effect since Project
98. In that version, I was expereincing frequent, severe corruption with
direct file-to-file links. The intermidary file resolved most of those
problems, and I've stuck with the technique since. My master file current
has 8 separate mpps (down from 24 earlier). One of the file links to all 7
others. Most of them link to at least 4 other. This speghetti of links
between files seems to cause problems. So I appreciate your advice that this
is a bad idea, but so far, my expereince (over 8 years) has been that it
helps. Back in 1999 I did try to run the links through the master with poor
results. (I have to admit I haven't tried this since then.)

I was in the process of trying to decide which links I needed to
re-esatblish when I decided to write this new post which I was hoping would
be seen a a narrower question focus than the last. I'm uncelar about which
links to break and which UniqueIDs are the important ones - the "ghost" tasks
or the linked tasks. I was experimenting trying to figure that our when I
decided to post this question.

Your last suggestion was to try this if there is a linked number ghost links
out of sequence. I'm afraid I'm going to have to reestablish all of the
links so they have a consistent UniqueID sequence, not just the broken ones.
This is more than I want to bite off without understanding how the ghost IDs
are selected, which is the real problem.

So before I start the larger job of re-establishing all of those links, I'm
hoping someone can shed light on how the IDs for the ghost tasks are
determined. It appears quite random at times - but I'm hoping there is an
explaination I haven't figured out.

 

[John]

Thank John -

I have been using the linking file technique with good effect since Project
98. In that version, I was expereincing frequent, severe corruption with
direct file-to-file links. The intermidary file resolved most of those
problems, and I've stuck with the technique since. My master file current
has 8 separate mpps (down from 24 earlier). One of the file links to all 7
others. Most of them link to at least 4 other. This speghetti of links
between files seems to cause problems. So I appreciate your advice that this
is a bad idea, but so far, my expereince (over 8 years) has been that it
helps. Back in 1999 I did try to run the links through the master with poor
results. (I have to admit I haven't tried this since then.)

I was in the process of trying to decide which links I needed to
re-esatblish when I decided to write this new post which I was hoping would
be seen a a narrower question focus than the last. I'm uncelar about which
links to break and which UniqueIDs are the important ones - the "ghost" tasks
or the linked tasks. I was experimenting trying to figure that our when I
decided to post this question.

Your last suggestion was to try this if there is a linked number ghost links
out of sequence. I'm afraid I'm going to have to reestablish all of the
links so they have a consistent UniqueID sequence, not just the broken ones.
This is more than I want to bite off without understanding how the ghost IDs
are selected, which is the real problem.

So before I start the larger job of re-establishing all of those links, I'm
hoping someone can shed light on how the IDs for the ghost tasks are
determined. It appears quite random at times - but I'm hoping there is an
explaination I haven't figured out.

Shawn,
I'm sure there is some criteria that defines the ghost task sequencing
but without researching it, I don't have a ready answer and
unfortunately I don't have time for that research right now. Maybe
someone else does and knows the answer and will jump in with a reply.
However it stands to reason that the linking sequence is dependent on
how the links are established (i.e. direct file-to-file, through the
master, etc.).

My file to file linking experience goes back further than yours and it
involved massive links between multiple Project 4.x files using paste
links, which was the only available method at that time. I quickly
learned that maintaining file integrity required a lot of discipline and
once I figured that out, I had very little file corruption issues. Links
were all file-to-file and I built a consolidated mater once a month.

This probably doesn't help a whole lot but other than actually seeing
your files to do some analysis, (which I do not have time for), my
previous suggestion of re-setting the links after performing cleanup on
your existing files is the best I can offer at this time.

John
Project MVP