I faced it long ago, for this reason ceased to use it.
Perhaps, there are some variants of a solution of this question, (type: ignore permissions in the previous status, allow to rewrite the version or the Check Out setup - only for the Author or another) but as to me to be remembered, it seemed still problems with high-speed performance or something else (now I will not remember).
The idea is seemingly good, but as I remember - has some restrictions which did not suit me.
The sense such seemed: it is recommended for use in static vault, for dynamic vault (In Work) - it is not recommended (if I am not right - let I will be corrected).
There is a very good reason it is like this.
Your files live on an archive server (let's call it Computer A).
Jim (Computer B), checks out files into his local cache. He makes changes to the file and the modified version lives in his local cache on his machine.
Mary (Computer C) cannot check this file in because the checked out version does not live in her local cache.
If Jim was to login to Computer C, he also cannot check the file in because the local cache is unique to that computer.
It can only be checked in by Jim from Computer B, the machine where it lives.
If user one checks the file out from folder A, then the file will show as checked out in folders B and C. This should make it unavailable to any other users. Then our user one tries to check it back in from folder B but it will not let him check it in because he checked it out from folder A. Our Vendor at MLC said that the file should be accessible for check in from any location as long as it is being done from the same computer by the same user that checked it out. I was told that Dassault has a ticket open about this issue (SPR-# 645585SPR)
I still think there is more to it than that.
I'll have a look at the SPR when I'm back in the office.
So, I did review the SPR and I believe this is a different issue. (It involved linking to an item).
I typically make sure the Checked Out In column is displayed to avoid the issue.
CHK_OUT_IN.jpg 39.6 KB
Yes our cards in PDM show whether the item is check out and by whom. The workflows stop others from checking out the file as well so it's really not a matter of someone else trying to make changes to a shared file, it's more a case of our users being confused about which folder they checked the shared file out from. I have to say that we like the idea behind the shared file option, there are just some improvements we would like to see with this feature. Thanks for your feedback it is very much appreciated.
It is a little more information.
Except the specified problem, still there are problems of removal, movement and renaming of such files.
Also if files have configurations or references to mirror components - too can be problems.
Besides there can be problems with welded details and many other things.
Also still there can be problems with the rights of users and various status of files.
I do not remember, but the problem of mates of such files (mates from different users seems are added to one file) - seems to eat that can create many problems.
I can be mistaken (as there is no time to check), but if simple files have the ID, then shared files in principle has to have ID there can be the same one.
And management of files is carried out not only through the SQL database (There are still external references in files of SolidWorks).
For these reasons - it is necessary to think well - whether it is worth contacting it. It is at least necessary to test very well everything in advance because then there will be many problems.
Perhaps I missed something, but it is interesting to me to specify about what files there is a speech.
Files of SolidWorks or only other types of files mean?
As it once interested me - there were some links - something can will it is useful:
Hello Sam Sam
Thanks for the links. They don't really relate to our particular problem but good information.
SWPDM is a folder based file management system. The folders have permissions and attributes that are applied to them. The files in those folders have attributes that are applied to them as well.
The check in behavior you see is due to those folder/file attributes. SWPDM does not see a shared file as a link to the original file and therefore does not apply the permissions or attributes based on the rules that govern one file. A shared file is similar to a situation where you have multiple different files saved with the same name throughout the vault. If you check out Screw.sldprt from folder A it will not check out Screw.sldprt in Folder B.
SWPDM works similar to this with files shared to different folders except that the metadata is the same between the files. So, since the version of Screw.sldprt in Folder A is checked out by Berry on their Computer SWPDM will add that information to the file metadata. The Screw.sldprt in Folder B shows that metadata. The only problem is that SWPDM tracks which folder it was checked out in separately and does not have a place to show that metadata. In the end the file in folder A was checked out and not the one in folder B, so you can't check in a file that is not checked out you can't check in any one of them except the one in folder A. When you check in the file from folder A SWPDM copies that file to all the other folders in the background.
This is the same for permissions. If only one person has write access to the original file that is shared to a folder that everyone has write access to the file in the original folder changes when anyone modifies the version in the second location.
In my opinion shared files should only be shared to folders that give the users read-only access to the file. If the file is modified it should be done from the original location. These files are usually what I would define as Library components because they are used in multiple projects. So, they should only be modified by the people that have write access to the original file. This takes away the issues of people in inadvertently updating the file when they make changes to their assemblies. It seems this stipulation on write access to the file would alleviate some of Sam Sam's issues as well.
Good Luck as you move forward.
Very good information. I think this will help us out. We like the paste shared option and I think we can make it work better by using permissions as mentioned in your reply.
completely I will agree with Paul Wyndham that it can be used as Library of sharing components.
I came to the same conclusion itself long ago, and so tried to use it.
But in practice, the author of the file not always foreknows what files can be necessary to other user and as they will be used.
I tried to leave the original file in the folder of the Project or to move it to Library and paste as shared in Project.
In each case the problems. As a result, meant well, and it turned out not really...
Probably, at observance of some conditions from it there can be an advantage. The problem is that in advance it is difficult to define all possible problems.
I expected wider scope from this option.
If it only for some folders, why in settings of all folders and statuses - paste as Shared?
Then for these purposes, it would be more logical to configure the choice of such folders (as Cash, Copy Tree, the Branch).
From information at a forum - or anybody has no problems with this option (what I strongly doubt), or it to very few people it is necessary (if at all practically someone uses it).
Other options are constantly improved, and this for some reason without changes. Why then it in current a look is necessary?
The personal opinion (I can be mistaken) - would be desirable to hear objections.