Re: Opening 2007 file in 2003 ID bug

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

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

--
Robin


"Rob Schneider" wrote:

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 wrote:
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.


.

Relevant Pages

  • Re: Opening 2007 file in 2003 ID bug
    ... 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. ... 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. ...
    (microsoft.public.project)
  • Re: [Full-Disclosure] Anti-MS drivel
    ... Does anyone lose their keys on purpose? ... you can reduce the risk but you can never alleviate ... launch exploits is pretty much risk-free - some might argue it's ideally ...
    (Full-Disclosure)
  • Re: [Full-Disclosure] Anti-MS drivel
    ... Does anyone lose their keys on purpose? ... you can reduce the risk but you can never alleviate ... Charter: http://lists.netsys.com/full-disclosure-charter.html ...
    (Full-Disclosure)
  • Re: |[4e] Races and Classes - Class info
    ... willing to dedicate their lives, to risk themselves, for the purpose of ... Conclusion drawn from false ...
    (rec.games.frp.dnd)
  • Re: Probably Stupid Idea for Saving Hubble
    ... If the purpose is controled deorbitation, as opposed as a risk of ... > The risk of HST crashing on NYC is zero. ... > The risk of HST crashing somewhere and killing someone is about .001. ...
    (sci.space.policy)