Put File Status Tracking into Vault Professional

[Neil_Cross]

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.

[ihayesjr]

See this forum post for reference as to why it is not in Vault Professional.

How to enable File Status? - Autodesk Community - Vault

[Neil_Cross]

@ihayesjr So I've read through Allans explanations/reasons but it doesn't entirely change my thoughts on this. 

100% understand the stance from you guys, the only thing there which seems to be concerning is when Allan said the flags could be "misleading" when lifecycles are introduced... but I don't fully understand the context behind this. 

But I'm assuming this is because:

- putting a part from WIP to Review causes a version bump

- this document version bump is the same regardless of whether it's a geometry change and check-in or a state change, so the parent will get an "update me" flag for all child state changes, which would indeed be useless.

Describing the above as 'misleading'... not sure, I'd call it useless and agree that wouldn't work.  However, just quitting and pulling the functionality isn't ideal either, again I'm saying this being ignorant to any and all efforts that may have happened leading up to that decision.

Now that we're 10 years on from Allans discussion, aren't there methods that can be deployed to work around this? Can't state changes be modified to being secondary or tertiary version numbers? Then if a file is checked out on a secondary or tertiary version number, increment that to the next full version number?

Do state changes even need to trigger a version bump?

Can't there be some logic injected into the Status Tracking, a basic IF statement, that instructs it to ignore files that bumped due to a state change? I can't say this would be straight forward, but there's no file in the filestore for that specific version... or just blanket ignore the first version following a state change (IF the state is different to the previous version).  This might then get complicated by potential purges etc but again, surely there's a way, if file status tracking is enabled then mandate that the first and last versions of any particular state can't be purged?

Getting into the weeds there but just thinking out loud.

[ihayesjr]

@Neil_Cross 

Thanks for your feedback. 

Changing the architecture of how Versions works as you described would be a large development effort that would have very little return on investment. We did decide back then that we would not put it into Vault Professional. Even in Vault Basic, the performance is not good once the environment gets large.