We have situation which lead to conclusion that properties update makes file ‘dirty’, that’s mean trigger checked out/update/bump the version any other assembly using this file.
The issue is explained below with two scenarios:
Scenario 1:
1. open file from the vault (no files in C-drive workspace)
2. Hit OK for Check-out the file:
3. Message will appear about updating the properties:" Some prperties in the file ... may be out of the date. Would you like to update properties now?"
4. For this Scenario 1 choose “Yes”, and the result :file is dirty (with*):
Scenario 2:
1. open the same file from the vault (no files in C-drive workspace )
2. Hit OK for Check out the file.
3. Message will appear:" Some prperties in the file ... may be out of the date. Would you like to update properties now?"
4. For this Scenario 2 choose “No”, and result is file is clean:
Conclusion: properties updates make files dirty and it constantly dirty every time when this file is checked-out.
Qestions:
1. How to fix issue with constant ‘dirty’ files after updating properties?
2. Where to start to resolve this?
3. How to see which particular properties are ’out of the date?’
I think I found the reason for problem I posted previously, and I hope it will help whoever has the same persistent out of the date files upon checking out from the Vault. Through testing different situation it is appeared that the issue “updating properties make files dirty” is created by UDP mapping in the Vault.
There are three types of mapping direction to synchronize properties:
Last two mappings (from Vault to File and both direction) create “out of the date properties” precedencies if properties out of sync (files with * or dirty file). These two mappings have effect for all Provider’ file, that is mean for all Inventor files (ipt, iam. idw…) regardless assigned categories.
If from Vault to File or bidirectional mapping set for any Property, Vault pushes Property’ value to Inventor File. So Inventor File must be ready to accept this value, means Inventor file must have Property (as a container to accept pushed value). For Example, if Vault UDP “ approved by” mapped to File Properties “APROVED”, “APPROVED_BY”, and “ Engr Approved By” by from Vault to File direction(or bidirectional), these properties should exist in the file to accept the value.
There are two types of properties in Inventor Provider File: Standard (predefined already) and Custom (created by Users). Since Standard properties already reside in the file, only Custom properties we should worry about in terms of existence and mapping direction.
Another word, every Inventor vaulted file should have every single custom property created if in Vault this property is mapped bidirectional or from Vault to file direction regardless category file belongs to. Only under these conditions the situation with constant out of the date properties (dirty files every time upon check out without reason) can be avoided (proved by testing).
This setting may help as well.
It tells Vault if it should create the property or not if it does not already exist in the file.
Agree, but in our case initially it was set up to "No". If now we decide to change to "Yes", it will effect all vaulted files, meaning action…synchronize properties…bumped version-check/repair children-parents broken links... What I found is how it is important at the very beginning set up mapping, make sure properties you are mapping from the Vault are in the File template already and know all the consequences. I wish it will be highlighted in help/wiki help as a Note/warning somehow.
Thank you anyway,
Lyutsiya