ipart issue with previous version of Inventor

[peter.roman]

Some of our systems have been migrated to Inv 2022 and they've migrated some iparts in a shared workgroup path. I've just updated to Inv 2011.3 to be able to work with 2022 parts but these iparts still show as unresolved in assemblies where they are already used (I don't want to change any of them, just work with the assembly and access the BOM, which I can't because of unresolved components).

[mcgyvr]

Why not upgrade to 2022? Best to all be on the same version.. 

I'm not aware of the intricacies (if any) when dealing with previous version limitations like you may be experiencing but have you verified that the ipart members are in the expected locations? 

Have you tried to resolve them by running the resolve function and pointing to that correct folder?  

[johnsonshiue]

Hi Peter,

I think you mean 2021.3 update. It is not like you can open 2022 files. You can reference 2022 iam and ipt files. This is meant to be a temporary solution for a company in the middle of upgrading to 2022.

I don't believe this workflow would allow you want you are trying to do. Are you trying to design a model within both 2021.3 and 2022 together?

Many thanks!

[peter.roman]

It's just that we have some standard iparts like bearing units that are used in different projects, so someone else might migrate it to 2022, working on their project, but then it effectively forces me to upgrade right then (if I reload the model) because it's not usable with the unresolved references and BOM not working.

I can understand not being able to work with that ipart like changing the member but it affects working on the assembly (still 2021) in general.

[SharkDesign]

Unfortunately this has always been the case. 

If one person upgrades, everyone needs to upgrade unless you're running completely different project files and library systems. 

New features don't exist in old versions, that's the whole point of a new release, so Inventor can't build those instructions, only translate them to dumb geometry.  This leads to version lockout to make things simpler. 

But you're right, one person only has to open an assembly and update the parts and it knackers up hundreds of all assemblies for people on older versions. 

[jtylerbc]

It's too late for something like this to help you now.  But for future reference, this is how I (mostly) prevent this problem from happening in the first place during our upgrades.

---

@peter.roman wrote:

Some of our systems have been migrated to Inv 2022 and they've migrated some iparts in a shared workgroup path. 

---

• Instead of workgroup paths, we use library paths.  Since Inventor treats library paths as read-only, this prevents most accidental migrations.
• The library folder locations are locked down so that only a couple of people (myself being the main one) have anything but read-only access.  This prevents most other unauthorized changes.
• During upgrade season, I wait until all of the heavy Inventor users have been updated.  Then, and only then, do I finally migrate the libraries (generally using Task Scheduler).

So we run on old-format library parts until the upgrade is nearly done anyway, then migrate all of the library parts at once.  The obvious hole that this leaves is if anything needs to be added or fixed in the library during the upgrade cycle.  If that happens, sometimes we have some issues.  But at this point, our libraries are established enough that it is rare for anyone to get locked out of access to a commonly used component.