From: Curmudgeon on
I have a Proj 03 mpp with 6000+ tasks that has become corrupted. We
can still open and work with the file in Proj03, but it will not open
in Proj07, which has now become our standard version.

I have tried all of the standard fixes without success (compact by
saving on open, export to mpd/mdb/xml and reimport).

I was able to import the project to a new mpp file successfully, but
this results in the assignment of new TASK_UIDs. It is important that
we retain the original UIDs: I hit upon the idea of exporting the mpp
to an mdb, using TASK_ID as a join field, updating TASK_UID to the
corresponding TASK_UID in the corrupted file in all of the MSP_*
tables in which TASK_UID appears, and then importing the result back
into Project. This also failed, but I'm not sure why - only about a
dozen of the original 6000+ records were imported back to Project.

If anybody has any further suggestions I'd appreciate hearing them.
Unfortunately, because this file resides in a secure environment it is
not possible to turn it over to outside recovery specialists.
From: Curmudgeon on
On Jun 3, 11:48 am, Curmudgeon <eht...(a)gmail.com> wrote:
> I have a Proj 03 mpp with 6000+ tasks that has become corrupted. We
> can still open and work with the file in Proj03, but it will not open
> in Proj07, which has now become our standard version.
>
> I have tried all of the standard fixes without success (compact by
> saving on open, export to mpd/mdb/xml and reimport).
>
> I was able to import the project to a new mpp file successfully, but
> this results in the assignment of new TASK_UIDs. It is important that
> we retain the original UIDs: I hit upon the idea of exporting the mpp
> to an mdb, using TASK_ID as a join field, updating TASK_UID to the
> corresponding TASK_UID in the corrupted file in all of the MSP_*
> tables in which TASK_UID appears, and then importing the result back
> into Project. This also failed, but I'm not sure why - only about a
> dozen of the original 6000+ records were imported back to Project.
>
> If anybody has any further suggestions I'd appreciate hearing them.
> Unfortunately, because this file resides in a secure environment it is
> not possible to turn it over to outside recovery specialists.

I set TASK_ID as primary key in MSP_TASKS in Access, then reopened the
mdb in Project. It seems to have worked - the tasks are all there and
have the expected UIDs. We now need to validate thoroughly to make
sure this procedure didn't break something.