When opening an assembly sometimes this message can appear.
"Changes have been made to some assembly components since this assembly was last saved which may affect component size and position.
To witness these changes during Save, adjust prompting options for Recomputable Updates, found in Application Options"
Would you like to update the assembly now?"
This is happening because Inventor recognises that the last time the IAM was saved, some changes have happened to some of the Child components. At this time, it might not be clear, what those changes may be and I would like to find out.
If you click "Yes", Inventor then tries to edit the files. If they are Vaulted, but not checked out, a message appears
"Component <PATH>\<FILENAME> is read-only or in use. Continue with edit?"
In this instance, I want to see the latest updates, so I click "Yes".
This is what is presented initially.
Switching to the Vault Browser we can see that the files need modifying because they show the "dirty" asterix (*) character next to the filename.
So what can cause this to happen, even if you are sure that the files have not actually changed?
In this instance, the Assembly contains iParts. "iPart_Child-01.ipt" and "iPart Child_02.ipt".
If you look at the Vault Client you will see the following.
The above image shows that the first column "Vault Status" is a white circle. This means that the local file is the same as the Vault. It also shows that there is only one Vaulted version of the file. And we have it! So why is Inventor trying to edit the file?
The answer in this situation lies with the iPart Factory. If we look in the Vault client for that file it gives us another clue.
This shows that the local "iPart Factory.ipt" is also the same as the latest version, but there are two versions.
What has happened is that the iPart Factory that defined the iPart Children in the Assembly, has been edited and vaulted. Indeed, the iPart table row that defines that particular iPart Child has been edited. When Inventor opens the file, the iPart factory is still local and it sees that it changed and does offer to update the part. If you open one of the children on its own you will see in the browser a small lighting flash indicating that the file needs updating.
View the Workflow that causes this in the following movie.
If you add a new row in the iPart Factory, instead of editing any existing rows, then you wont have to update the children. If you do edit the row or add a new column, you are faced with the inevitability that you will have to check the children out, generate new versions of them, and check them back in again to avoid this message in future.
So in summary Vault is not necessarily the root cause of this behaviour. When an iPart Factory is edited, Inventor will use the latest version of that file. The inter-file relationships are forcing the assembly to be updated, when opened and because the files are Vault controlled,
Subscribe
Hi Richard,
Great post. Are there any changes that can occur in the iPart factory that happen automatically? We regularly are required to save changes to children files (often the same child) despite the fact that no changes have been made (manually) to the factory files. Furthermore, our factories lie within a vaulted library folder.
We also get this same behaviour with content centre files.
Regards
Posted by: Gerrard Hickson | October 28, 2010 at 05:24 AM
Auto-Migrating to the current release, maybe. Possibly sharing the library. Maybe a user is using another IPJ that does not have the library defined in the IPJ as a Library. I am hopeless at guessing because there are possibly a million reasons.
I am guessing from your email address you are Oz based. I am in the UK. I would like to analyse the issue you are experiencing as I have a thing at the moment in trying to nail down and document behaviour like this. It would be better if I witnessed the behaviour. Can you log a support case and mark it for my attention? I am hoping I can connect remotely to analyse at a mutually convenient time.
Posted by: Richard | October 28, 2010 at 11:58 AM