Opening 2007 file in 2003 ID bug

[Robin Roe]

Hi

We use 2003 in our company but get many files in from partner companies in
2007 format, which we can open with 2003 SP3.

Today we opened a 2007 schedule sent by a contractor and 2003 has totally
distorted the dates, which is a bit of a worry to say the least. When we
noticed we requested a PDF from the contractor to compare against what our
2003 version was showing. We also have a copy of 2007, and when we opened the
same file in that it, was identical to what the contractor had sent on the
PDF.

The IDs on the 2003 version don't match the 2007 version (different task
names to different IDs) and this seems to have distorted the dates.

Is this a known bug and if so do Microsoft have a fix? It's a rather large
problem, if we constantly need to cross check what we receive, never mind try
and fix it.

Thanks for your help

 

[Rob Schneider]

Others might know if ther are known bugs here ...

But what immediately comes to mind is that it's normal for ID numbers
(field=ID) to change. They change all the time. But the Unique ID
should not change (field=Unique ID) even with movement from one version
to another (although I have not tested that). Insert Unique ID onto a
column in the two files and see if you also see differences.

I'm also wondering if you have inadvertenly computed a new schedule
because you have automatic recalculation turned on (Menu: Tools/Options,
Tab: Calculation, the "Calculate" option).

--rms

www.rmschneider.com

 

[Robin Roe]

Thank you Rob for taking the time to answer.

Yes you are correct, the Unique IDs are identical, and again you are correct
in saying that if I don't calculate it, the schedule keeps the right dates.

While I agree with you that the IDs constantly change within a schedule
(when you insert/delete a task between other tasks etc), but there should not
be differences when opening the same file in two different versions, which
seems to be the problem I am having.

E.g.
2007
1 Project Management
2 Prelim Design
3 Detailed Design
4 Construction
5 Handover

2003
1 Project Management
2 Prelim Design
5 Detailed Design
3 Construction
4 Handover

While not calculating the schedule keeps the dates in place (but some of the
WBS is wrong), what happens if you need to edit it? Does it also mean we
can't calculate any schedules sent to us for fear of messing it up?

Thanks again Rob for your help.

 

[Rob Schneider]

ID's change. Even when you aren't crossing versions. That's the way it
works. I don't think there is anything anywhere which says they should
stay the same. They don't. And when you are working cross version I
guess more "unexpected" things happen. My advice is to not worry about
it. Focus on Unique IDs for that need to keep things the same.

Yes, when you get someone else's MPP file (remember it is "source
code"), and you change it in any way, you run the risk of "messing it
up". The absolute worst thing that can happen is when you "mess it up"
and don't know it.

That's why I would never give my MPP file to someone else unless there
is a good reason. There are usually few good reasons. When I do share
the MPP I ensure the person has a need (perhaps we collaboratively
working on a plan and we both know equally well not to "not mess it up").

There are other ways to communicate status, plans, forecast, etc. than
by sending MPP files.

"Just say no" when asked to send MPP files. And when receiving MPP
files, don't mess them up.

--rms

www.rmschneider.com

 

[Robin Roe]

Rob again thank you for your reply.

Unless I am misunderstanding something here or maybe I haven't explained my
problem very well, I must say that I disagree entirely with what you are
saying.

I accept that IDs change, but surely only if I do something to make it
change like add an additional task to the schedule. If I save a in 2007 file
and reopen it 2003 without doing anything to it, I don't expect the IDs to
change.

If I get an MPP file from someone else and don't do anything to it (just
open it), I don't expect it to be any different to what they sent me. To say
not to send MPP files around, defeats one of the main purposes of using MS
Project, so that you can collaborate with people. It's not an option, as
clients and partner companies demand that we do.

Normally we have no problems with this issue (or at least we thought we
didn't which is probably worse). But this one file is causing a problem. If I
could be confident that it is a one off, I wouldn't worry too much, but if
it's not, we will have to scrutinise every file we get.

 

[JulieS]

Robin,

As a quick suggestion -- does all go back as expected if you sort
the project by ID order?

Also, do you know if the partner is saving the files as a 2003 file
or are they sending you the 2007 file directly? I suggest asking
the partner (if possible) to experiment with you to see if there is
a difference. If possible, I would also ask the partner(s) what
service pack they have installed to Project 2007. You note you are
at SP3 in 2003 -- Project 2007 is at SP-2.

As far as "messing up the file", to the best of my knowledge,
opening a 2007 file in 2003 results in the file being read-only, so
you cannot over write the file with any changes you make.


I hope this helps. Let us know how you get along.

Julie
Project MVP

Visit http://project.mvps.org/ for the FAQs and additional
information about Microsoft Project

 

[Rob Schneider]

Excellent. I thought you might challenge what I said!

My goal, I guess, is to get us to think a little deeper about this.

Like I said, ID's change. That's how the Project appears to do it. I
recall this discussed fully in this forum many times over the years, and
I've seen it. Perhaps within the same version when files move around it
does not change ... I have not tested. I recall it documented somewhere
that ID's change.

Unique ID's fill the need you have. Focus on Unique ID's as the
non-changing identifiers for a particular line item in a particular file.

Collaborating is different than sending MPP files around. And just
because people do it and just because clients and partner companies
demand that it be done, doesn't -- in the absence of recognition of the
issues and risks -- make it good thing to do. I contend that the senders
and receivers have to understand these issues and risks and ensure both
parties are satisfied their interests are covered.

And I'm also wondering if the main purpose of Project really is about
collaboration. I'm a big fan of collaboration and believe it's
essential for project. But Project, the tool, main purpose is as a
calculation engine for project cost/schedule which provides a data
structure to put that data and a user interface to deal with that data
an the results.

When MPP files get sent out, then the sender no longer controls it. The
receiver can accidentally or deliberately make changes to the file. It's
just data. It doesn't on its own tell any sort of story. The data can
easily misrepresent the story. Even if the file is tagged "read only"
when you open the file you can change the contents. If calculation is
turned on to "automatic" it will recompute the schedule. Then no matter
how the sender left it, the receiver will see something different. You
were lucky enough to notice. Others aren't so careful.

If the purpose of sending the file is to to link it into a master
project to rollup programme status ... well, that's a great idea. And
should work. But it has to be done with a full understanding how
Project works. Further, unless certain precautions are taken, you can
easily get major corruption with the Project files. Corruption can be
avoided by taking precautions, but many do not nor know to do so.
Again: Project isn't really a robust "collaboration" media, in my view
to the extent that I'm happy sending the MPP files outside "my world".

If the purpose of sending the file is to get an update on on progress
.... well, I think it would be better for the senders to setup -- even
automate -- some standard views, reports, graphs, etc. and publish into
a PDF file. Put in some elaborating/explanatory text. Tell the story.
Do it as a Project Report.

If the purpose is to feed data into another scheduling/accounting
package ... well, send data as XML, ASCI, or XLS or something.

Like I said ... I know a lot of people/projects exchange MPP files and I
know it's demanded/contracted. It's just not a good practice, in my
opinion, unless specific precautions and controls are in place--but they
usually aren't. Hence the risk.


--rms

www.rmschneider.com

 

[Robin Roe]

Rob

Thank you for your posting. I accept what you’re saying about the potential
risk of sending files around, my own situation being a case in point, and
that perhaps we should possibly do things a little differently. What I don't
accept is that when we purchase a product that it doesn't do what it's
supposed to do, and that you can't have complete confidence that it won't
change the underlying data. If I send my accounts department an excel
spreadsheet (regardless of excel version), I don't expect them to have to
re-check back with me that the figures haven't changed when they open it. I
would accept if when I imported a project file into something like Primavera
that there may changes, but not from one version of Project to the next. Yes
I agree the likes of formatting could change but not the dates.

But for the moment what I really want to do is try and do is find out why
this problem happened, and how I can prevent it from happening again.

Thanks again

 

[Rob Schneider]

Robin,

Well, Project is not Excel (despite the label "Office" on the cover).
It's sophisticated and takes undestandingn to do it correctly;
especially when other people's money is at stake!

With all due respect, I think it's operating as it is supposed to. As I
said, I think it is documented (and understood by many) that ID's don't
remain fixed. Use UniqueID if you need them fixed. Documented not to
change. And, Dates *will* change when they are told to change!

the way to prevent it?
: use Unique ID's as you sign of uniqueness.
: look at the computed project end date and computed %Complete. Maybe
even write some code that could check "integrity" of the file to ensure
same as it was when left sender's hands
: ensure that what you are doing is actually fit for purpose. I don't
know your purpose, so I can't suggest. If there is a better way to do
it, then do it the better way.

--rms

www.rmschneider.com

 

[Robin Roe]

Julie

Thank you for responding.

When I sort by the ID, the tasks obviously reorder to accommodate and keep
the wrong WBS code (as opposed to what's correct in the 2007 version).

I have tried a few things as you suggested.

The contractor originally didn't have SP2, but when this was applied and the
file resaved, it didn't seem to make any difference when opening in 2003. The
IDs were still incorrect.

He then saved the file as a 2003 project file. It then opened correctly in
2003. So that seems to be the short term solution. So obviously there seems
to be a problem with the converter in 2003?

What seems to have happened, is the contractor inserted extra tasks, and
while in 2007 it reassigned the IDs to accommodate the insert (between
existing tasks as opposed to adding after the last task), when open in 2003
it seems to take the next available ID instead. Very Strange indeed!

Thanks for your help

 

[JulieS]

You're welcome Robin. I'm glad to hear that saving as a Project
2003 file explicitly in 2007 appears to have solved the short-term
issue.

You mention the WBS (not IDs) appear incorrectly. Is the WBS a
custom WBS scheme or the standard WBS field? If the contractor is
inserting tasks and using a custom WBS, the contractor must
explicitly renumber the custom WBS through Project > WBS > Renumber.
If the WBS field is the standard WBS field, it should renumber
automatically when tasks are inserted or deleted.

Julie

 

[Robin Roe]

Rob

I realise the IDs can and do change, I have no argument with that at all.
E.g. If I move a task from line number 1 to line number 6, it changes ID from
1 to 6. That's expected. (While the Unique IDs stay as they were originally)

My problem is that Project is changing them for no apparent reason from one
version of project (2007) to the next (2003) I am not amending or adding
anything, just opening it.

E.g. If I save a project file tonight and open it again first thing in the
morning, the IDs shouldn't change. All I am doing is opening it.

Hopefully I have a solution anyway, which Julie has kindly helped me with.

Thanks for your help.

 

[Robin Roe]

Julie

Talking to the creator, they just used the automated WBS coding system
rather than changing anything manually.

Thanks again

 

[JulieS]

Hmmm. That is odd Robin. Does this happen with all files from this
particular contractor or just one file? Is it possible that the
contractor has his/her calculation mode (Tools > Options >
Calculation) set to manual? I don't believe project recalculates
when the file is opened, but if you are seeing different data than
the contractor, it might be possible that one of you is calculating
automatically and the other isn't?

Julie

 

[Robin Roe]

Thanks again Julie,

The Auto Calc is turned on, on his side. To be honest, I think I will treat
this as a one off, and keep an eye on future MPP files that come in as I have
never seen this happen before. I don't think it's to do with the Calcs, but
possibly to do with corrupt IDs, which is changing the durations, because the
tasks are under the wrong WBS's and as a result wrong summary tasks. I think
it has to be a bug on Microsoft’s side, as it works fine when you save it as
2003, which would suggest the data is correct, but that perhaps the 2003 SP3
converter for 2007 files may have a problem.

Do you know of a facility to report this sort of problem to Microsoft?

Again thank you for all your help Julie, much appreciated.

 

[JulieS]

You're most welcome Robin and thanks for the feedback.

I think your suggestions are good. Keep an eye on what you expect
to see and what you are seeing. It sounds as though this is not
occurring all the time and therefore tracking down the root of the
problem is going to be difficult at best. It's possible the
contractor's file has developed corruption and that corruption is
appearing once it is opened in Project 2003. As an experiment, the
contractor may try rebuilding his file by saving as XML and then
re-opening the file from there. Then save as 2007 and re-send to
you to see if the problem recurs.

Because the difficulty doesn't appear to affect all files, it's a
bit difficult to report to Microsoft as a bug. If you'd care to,
you can send the offending file to me by email and I'll see if I can
reproduce here. If I can get the problem to reproduce consistently,
I'll forward the information to Microsoft.

If you wish to email the file, please zip and email to me at
prjng [at] maine [dot] rr [dot] com.

Replace the [at] and [dot] and remove spaces.

Julie

 

[JulieS]

For those of you following the saga. I believe the 2007 file had
some corruption as opening the file in 2003 showed extra tasks which
were missing from the 2007 file. The file also had a number of blank
lines which have caused problems historically.

I saved the 2007 file as XML and then imported the XML file as a new
file. Saved as a 2007 file which then opened without incident in
2003.

Julie

You're most welcome Robin and thanks for the feedback.

I think your suggestions are good. Keep an eye on what you expect
to see and what you are seeing. It sounds as though this is not
occurring all the time and therefore tracking down the root of the
problem is going to be difficult at best. It's possible the
contractor's file has developed corruption and that corruption is
appearing once it is opened in Project 2003. As an experiment,
the contractor may try rebuilding his file by saving as XML and
then re-opening the file from there. Then save as 2007 and
re-send to you to see if the problem recurs.

Because the difficulty doesn't appear to affect all files, it's a
bit difficult to report to Microsoft as a bug. If you'd care to,
you can send the offending file to me by email and I'll see if I
can reproduce here. If I can get the problem to reproduce
consistently, I'll forward the information to Microsoft.

If you wish to email the file, please zip and email to me at
prjng [at] maine [dot] rr [dot] com.

Replace the [at] and [dot] and remove spaces.

Julie