Re: Importing 2001+ into 2004

SW isn't particularly good at making sure that old parts rebuild in new software. We've had issues with every release since SW2000. Ideally, when you think you are ready to "upgrade" you should open every part and drawing and do a ctrl-q on them to force a rebuild. (The parts that failed over the next two weeks may have failed when they finally needed to do a rebuild.)

Do the failed parts have lofts and sweeps? They are probably the most like features to fail. How about configurations? They are another weak point, where features seem to change suppression state on their own. (In fact, you should probably force a rebuild on each configuration as well.)

Corey's advice, to try updating from 01+ to 03, then 04, is probably good.

Jerry Steiger Tripod Data Systems "take the garbage out, dear"

Thanks for the advise. I forgot to mention that when these older parts are opened, I get an "unexpected file format" error. Does this sound familiar?

Again thanks,

Thanks for the advise. I forgot to mention that when these older parts are opened, I get an "unexpected file format" error. Does this sound familiar?

Again thanks,

Thanks for the advise. I forgot to mention that when these older parts are opened, I get an "unexpected file format" error. Does this sound familiar?

Again thanks,

Thanks for the advise. I forgot to mention that when these older parts are opened, I get an "unexpected file format" error. Does this sound familiar?

Again thanks,

It would appear you also have a problem with your email application's repeat and repeat button (grin)

Kman

Thanks for the advise. I forgot to mention that when these older parts are opened, I get an "unexpected file format" error. Does this sound familiar?

Again thanks,

Sorry about that. everytime I attempted to respond, Google replied that the message did not post to the usenet. hence, several of the same message.

RMH

It's quite handy, if you have an API, to run test migrations on little used machines, weekends, overnight, etc. and have the API program keep logs (and be able to restart from a log of untested files) of any problems, if it can document them. Sadly, in my experience, really bad part files can lock up the task (hence it's important as well to write the NEXT part to check to the log files before starting the check AND save the log file to disk).

Generally, you will probably find the most "corrupt" files came from specific users .... and there is also supposed to be an NFS corruption issue on some networks (that I don't quite grasp ).

After dealing with any & all corrupt files everything else should migrate ... one release level at a time .. each time using the software for the next release lavel, not the latest & greatest unless it's all only one release level behind. Sometimes you can migrate more than one release level (don't know about SW) but don't count on it at all.

Keep good backups before starting even the tests and at each stage.

Monitor which parts are in use and which are not often, if ever used. You have a good chance of migrating the little-used parts first, thus saving a lot of system resources at crunch time when the new release must be live. IF you have the spare system & disk capacity ($$$$) you can migrate in parallel to the live, production system and just swap the end data when the time comes, only having to migrate the last day's work at that time.

HTH