Re: DB?

    My preference for database comes from many difficult old experiences with bottoming out spreadsheets. P3 users have always
resorted to flat-filing schedules or portions of schedules to facilitate building large projects. The editing features of
spreadsheets are very convenient, until you bottom out the memory. Database manipulations do not have that drawback and also the
database can do global types of change quicker and with fewer restrictions than the 'global change' module of P3.  With more memory
and faster computers the risk of 'bottoming out' is reduced but the experience is one that lingers.  I want to put in a plug for
emacs here - it has a virticle cut and paste feature I previously used in an editor called 'PE'.
    I am still not sure that MrProject needs to fill the role played by P3 - maybe it just needs to export cleanly which might be
easy to do with xml output. A simple scheduling tool is needed by various people in the beginning stages of every project.
    Having read the other comments I think there is another direction taking shape and a need of which I have had recient experience.
I have just completed a $110M design-build project and was appalled by the lack of project controls in the design phase, some form of
TQM is needed to develop better specifications. Scheduling is nebulous if the specifications are unclear and that was exactly my
experience. (Although this may be only my opinion about 'functional specifications').The goal of this proposed TQM would be to track
the specification item by item from its origination and conceputalization to its final solidification as a contract or submittal -
connected to procurement, fabrication, and installation activities in the schedule.  A wizzard to build the various schedule
activities out of the specification would be a nice touch.