well, in 2012 the do not show works for the session of SW, so you wouldn't need to hit it as often if you could upgrade.
it is probably worth your time to update the part files to your current version. there is currently a tool to batch do this in EPDM, not sure if it was there (or how well it worked) in the 2010 version (we have not had EPDM that long).
I share your pain and confusion, Dave. I see a lot of the same thing.
I noticed that since we upgraded to SW 2012 (from 2010), when I open an assembly that contain files that were saved as 2010 files, PDM consistently flags them as 'dirty', ie, files that have been changed but the changes have not been saved. I feel that this is not proper behavior because they have not in fact been changed, and I don't like SW constantly pestering me just because older files have not been updated. The majority of those files will never be revised so they will likely never be updated to a later file format. I would like SW to just accept that fact and move on.
This is probably the cause of much of the problem you're seeing, as you have already surmised.
There is also another strange behavior that could be causing some of this problem as well, and needs to be kept in mind. Apparently (and for reasons that completely escape me) whenever a file is inserted into an assembly, the assembly attempts to update the file to store information about the most recently used configuration. If you're using the same configuration as the last assembly that used the file, there's no change, but if you are using a different configuration, SW feels the need to store that info back into the referenced file. This creates a two-way updating scenario which is difficult to manage, and it causes SW to report the inserted file as 'dirty' when in fact it has not been changed (nor, usually, even opened). This is the identical symptom as you are seeing, but created by a totally different cause.
So, we have two separate situations which cause SW to erroneously (and pointlessly, IMHO) complain that files have been changed, and the only way to stop it would be to check out, save and check back in each and every file affected. Not only would this be a major time and productivity waster, it would also cause problems by creating a new (otherwise useless) version in the file history of each of these files. Such files would appear to have been modified after the last release (revision) point, and so:
- Users who always get the latest version would not see the file reported as the officially released version
- Users who get the latest officially released version would not have the 'fixed' version, so SW would continue to bug them about the file being changed but not saved.
Bottom line: SW developers and EPDM developers need to sit down together in the same room and make their disparate products play nice together.
have you looked at the file upgrade tool? there are option in there that may address your concerns over versions and revision flags.
Thanks for the responses everyone. Randy Ooms' solution works!
Thank you for detailed solution
Is there a way to do this in PDM Standard?
This is the closest to an "options" I can find for the PDM Standard server.
I was hoping there was something available in the "warnings/errors/messages" section of the PDM Administration and/or the solidworks system options.
Can anybody shed some light on getting rid of this annoying prompt?
Same issue here, using Solidworks PDM Standard 2018.
Cant find anywhere to turn off multiples of "The file being modified is not checked out in Solidworks PDM" messages error.
Can anyone help!?
Try setting this registry key.
HKEY_CURRENT_USER\Software\Solidworks\SOLIDWORKS 2018\Collab\Abort Read-only Top Docs = 0
Hi Steven Dod,
I originally thought your solution had worked, but it seems some of our users are still experiencing the problem.
It appears that the "Abort Read-only Top Docs" registry key is default set to 0 and assumingly setting it to 1 should prevent the message.
After setting it to 1 users are still unfortunately receiving the message
Resetting our machines seems to set the key back to its default 0.
After digging a little deeper, I believe the error may be attributed to majority of our library components being 2017 version files. We recently just upgraded to 2018.
I will save all files to 2018 and report back.