Re: Task ID assignment for external dependencies

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



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


"John" wrote:

In article <76EDD23F-6053-4340-B887-30A303014AC2@xxxxxxxxxxxxx>,
Shawn Pollack <ShawnPollack@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

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

.



Relevant Pages

  • Re: Linking Problem in MS PRoject
    ... You've hit the limits of an old technology that does the linking. ... Set Flag1 to Yes for all tasks you want to have in the new plan. ... new master. ... For VBA posts, ...
    (microsoft.public.project)
  • Re: Task ID assignment for external dependencies
    ... I have been using the linking file technique with good effect since Project ... Back in 1999 I did try to run the links through the master with poor ... links so they have a consistent UniqueID sequence, ... When things work as I expect, the ghost task for the external predecessor ...
    (microsoft.public.project)
  • RE: Requesting suggestions for manufacturing app...
    ... to be the ability to have "subflows" as well. ... lots belong to the master lot. ... linking table, tbl_AllLots, which can then be used for chronologically ... showing which lots belong to the MasterLot. ...
    (microsoft.public.access.gettingstarted)
  • Re: multi-level linking
    ... Master plan, and wouldn't be surprised if there were several hundred links ... when linking. ... I don't foresee any problems if external links ...
    (microsoft.public.project)
  • Re: Partioning a table
    ... > Thats like creating two separate tables and linking ... I've seen this technique ... showed you, create the partitioned view, query it, and look at the execution ...
    (microsoft.public.sqlserver.datawarehouse)