Downsides of allowing users to "Change state while file is open in another application"
Downsides of allowing users to "Change state while file is open in another application"
What are the downsides of allowing users to check in/check out files and transition them when they are open in SolidWorks? Why would I want to disallow users to preform these actions on a file that is open?
Re: Downsides of allowing users to "Change state while file is open in another application"
Because the application that has the file open likely has the file locked. So when PDM service tried to change the custom properties in the file (so that they stay sync'd with the datacard variables they are mapped to) it cannot. We have a couple of users that I'm trying to beat this into their skull that if they have files open in SW they need to use the SW PDM Add-in. But they are oblivious and continue to go to vault view or search tool to change state or check out a file. And it always messes things up.
Example:
User has top level assembly or drawing open, view only, not checked out, just looking. Ok they go into search tool to change state on some component. Our workflow is set up to set the data card revision variable to %nextrevision% when the file goes from Released to WIP. So it creates one version automatically in the state change and that version shows the correct revision value has been incremented. BUT since the oblivious user had a top level assembly open that contained this part in some sub-assembly level SW has the file loaded into memory and therefor locked (at least that's my understanding.) So next the user checks out the file and does changes. NOTICE, the custom file properties still show the old revision value and do not match the data card at this point. Then the user checks the file in and the wrong revision value is pushed from the custom properties TO the data card.
This is one example why I request that variable to custom property mappings be directional and we can set them to be to data card, from data card or both.
There's other cases I've seen like checked out files still have the read only flag checked; file was in use by another process when PDM service tried to remove the "read only" flag on the file. So PDM shows file checked out but SW won't save because it's read only.
Example:
User has top level assembly or drawing open, view only, not checked out, just looking. Ok they go into search tool to change state on some component. Our workflow is set up to set the data card revision variable to %nextrevision% when the file goes from Released to WIP. So it creates one version automatically in the state change and that version shows the correct revision value has been incremented. BUT since the oblivious user had a top level assembly open that contained this part in some sub-assembly level SW has the file loaded into memory and therefor locked (at least that's my understanding.) So next the user checks out the file and does changes. NOTICE, the custom file properties still show the old revision value and do not match the data card at this point. Then the user checks the file in and the wrong revision value is pushed from the custom properties TO the data card.
This is one example why I request that variable to custom property mappings be directional and we can set them to be to data card, from data card or both.
There's other cases I've seen like checked out files still have the read only flag checked; file was in use by another process when PDM service tried to remove the "read only" flag on the file. So PDM shows file checked out but SW won't save because it's read only.
Re: Downsides of allowing users to "Change state while file is open in another application"
I encountered this problem recently, this post confirms what I read in the knowledge base. The user will see dialogs pop up to the effect of "the file is writable".
I observed this particular user to have an astounding number of drawings open simultaneously in Solidworks, which may have something to do with the likelihood of encountering the issue.
I observed this particular user to have an astounding number of drawings open simultaneously in Solidworks, which may have something to do with the likelihood of encountering the issue.