You know when you open any Inventor Assembly or Drawing, and you get the dreaded 'File needs to be updated' message, you have no idea why, but you pretty much have to click Yes and either wait 10 minutes for it to chug through, or sit and watch whilst your assembly disintegrates? What's even more concerning, is when you see this message immediately after putting a dataset to WIP from the Released state, meaning something was put to Released with pending potential geometry updates that haven't been applied to the assembly or drawing.
I haven't used Vault Basic in 10+ years, but today I found myself telling someone how it all works. That was when I came across 'File Status Tracking', which caught me off guard as I didn't recognise it and didn't have a clue what it was.
The reason for that is because it isn't in Vault Professional.
File Status Tracking is the solution to this huge issue in Inventor. A problem that I didn't know there was already a solution to.
When enabled, File Status Tracking will enable a property in Vault Basic called 'Status' that flags up when an a parent references a child which has been updated, but that parent hasn't been checked out to inherit the changes in the child.
Are you kidding me?? This would and should be the first thing you enable in a Vault install. It even tells you which child part(s) are causing the pending update!
Why is this insanely useful feature available only in the bog standard version of Vault, and not in the Pro tier?
According to the Vault team, it's because of potential performance issues on the Professional server component when this is enabled.
That's as much info as I have right now, but I'm raising this as a wish list item with the following questions lingering:
- Some of Autodesks hardware advice & guidelines are based on compute performance benchmarks from over a decade ago. Are these 'performance issues' based on observations seen on hardware from 10+ years ago? Would the same issues be seen now on modern technology?
- If the performance issues are unavoidable and noticeable regardless, why not make it a choice? Make it off by default, and let the sys admin test the performance hit in a sandbox environment. If someone gung ho enables it on a live environment, make it so the enablement can be reversed and disabled. No harm done.
- Without knowing the extent of the performance hit and being ignorant to almost all detail, it could be argued that lost time & money due to out of date released data and time lost finding which files are causing the 'update me' flag is more severe than a upfront performance hit on the server. Again, give the user the choice.
Show More