Autodesk Vault Professional 2012 Revision and Lifecycle states are really impressive features. However when things go wrong, they become quite frustrating. This is exactly what happened after working with revisions, and then stepped into Lifecycles.
Null revisions are an empty version, possibly always version 1, that occurred when an assembly was initially checked into the Vault with a default category with no revision structure attached. This would be useful if lifecycle states were not desired. When that assembly’s category is changed to a more suitable version with lifecycle and revision states, the initial Revision is added as A, and a comment for a category change. That Revision A lies at version 2. A null is left behind at version 1.
Assembly won’t release
Eventually we need to release the assembly to manufacturing. The parts are all released, but the assembly balks giving us the error that says that the assembly is linked to a part who has a version that is not released. I’ve actually seen different versions of this error, depending on what options I monkeyed around with.
What it looks like is that version 1 of the assembly (Revision Null) is tied to version 1 of all the parts (Revision Null). Since the null is not supposed to be there, and cannot be revisioned, it cannot be released. Kind of a catch-22.
Old versions of current revisions
the Assembly’s latest version of Revision A is linked to the latest version of a part’s Revision A, and at the same time, a previous version of the Assembly Revision A is linked to the part’s revision null.
Workspace cache hung up
What makes this worse is that when you check out the assembly, quite often the part files are read from a cache that isn’t being updated from the Vault. (We found this to be true of the Vault’s Content Center components, which was corrected easily by erasing the temporary workspace). Be mindful of this because it can cloud the results of your troubleshooting.
Here’s the really solid foundation step through that not only got this bug fixed, but helped with other troubleshooting issues as well. I’ll lay it out in steps:
Step 1: Change the state of everything in the assembly to ‘Work in Progress’. Odds are that all the parts that were checked in at the same time are hung.
Step 2: Check all of the files out through Vault, including both the assembly and parts. This will overwrite the old components in the temporary cache.
Step 3: Check the same files back in through Vault. There are several reasons why this is not the best practice, but it is tremendously faster than check out and check in through Inventor, and I experienced some instances where Inventor could not complete the task with this bug in the way.
Step 4: Change the Lifecycle state of all these files to ‘Released’ in Vault.
What we did was bring everything back to a non-released state, and checked them into the Vault together. That killed the links to non-released versions buried under released ones.
This is not the best place to do this at. If you can perform this from the Inventor add in panel for Vault Professional then by all means do. Hopefully it will be easier going than it was for me. This bug really seemed to confuse the Vault to Inventor interaction, and in some cases vault could not get the parts checked out properly because of the workspace cache. I found the Vault route much less painful, especially after weeks of searching for a solution.
I’d like to thank Scott Moyse from New Zealand for helping with the workflow to beat out this solution. You can catch him on Twitter by following @ScottMoyse.