is the assembly with references:
- checked in ?
- not open in any application (e.g Solidworks) at the time of moving files ?
Probably the grey folders indicate that the assembly was open at the time of moving.
hi dave i agree with peter. at our company we have been using epdm for 2 yrs and don't have any issues with broken references we have probably 4,000 job folders in the vault. once in awhile it can't find a part but it is usually because someone moved it
Everything was checked in. Solidworks was open, but no files were open. In fact one of the assemblies that was corrupted was locked in a released state. My first ECO and the assembly had 6 lost references. This was our first significant move of parts in the creation of a library and it resulted in 2 corrupted assemblies (so far) with a total of 7 lost references.
Steve, you said you occasionally can't find a part because someone moved it. Isn't that one of the key concepts of EPDM? You can move files and not lose references? So far my experience is to the contrary. It appears you have a similar experience.
We've been on EPDM since early 2008 with no broken reference issues.
When I moved parts from the job folder to a library folder, I lost references.
Are you saying that the "job folder" is outside the vault? If so then that is the problem. EPDM will only maintain references for files inside the vault. The Update References wizard was added in EPDM 2012 I think. I've only had to use it when adding an assembly that was done outside the vault.
Hi Dave, We do experience broken references... more often than I would like to admit. These issues arise for several reasons. First is the initial integrity of the data you migrated into your vault. If you did not have clean data (i.e. fix all the links, references, etc.) to begin with, this will contribute to your problem.
Secondly, if your data was not migrated correctly (that being all the references resolved to vault locations.. said another way, files still reference parts outside the vault), this will also lead to issue. This is one of the main reasons for the "Update references... " tool you are refering to.
Third, and my biggest issue as a CAD admin, is the discepline of the engineers/designers to NOT use files outside of the vault. We have guys that love to save local copies, which can be ok if handled correctly, but often times it's not and this can cause headaches.
Lastly, make sure each and every solidworks user is setup to use the same Vaulted libary locations. Check to make sure in solidworks the Tools-->options--> File locations are setup correctly. Among others, the referenced documents and seach paths very important. You should add your root vault directory to each of these and clear out any non-vault locations. Also, if you are using a common toolbox that is vaulted... be sure to delete any previous installation of the toolbox on the local computers and just cache the vaulted toolbox.
The one questionI would make is that you said your files were losing references during workflow... what are you doing in between Step A and Step B that is altering the file?
I'm still configuring our vault so I haven't let the engineers/designers try to break it yet but I think there is a solution to the local copies issue. On a Groups Properties > Warnings, I checked the "Outside SolidWorks Enterprise PDM" to block Check In of local files. In my testing, if I copy my drawing into the vault but leave the model local, I can't check in the drawing. Is there another way the users are getting files in that would bypass this?
In between pushing the file into the workflow and the ECO, I moved parts that were in the job folder into a library folder. We have about 6 years of data that is outside EPDM. Our process is generally to take an existing job and modify it to the new customer's specification. This means pulling in an assemblyof 1000+ parts from an old version of SW with messy metadata and cleaning and modifying it. In our case the job specific changes are always done first as we are usually building the enclosures before we know 100% of what is going in them and where it is going. These models and drawings get updated and cleaned and then pushed to manufacturing. Then the job is to clean everything else up and create final assembly prints. Part of that is to clean up and move the plumbing and electrical parts that are standard parts into the library where you can update the data cards properly and clean up the metadata.
Unfortunately it seems that our process is not conducive to SW maintaining our references well. I will look into the file locations and make sure I am pointing to right place.
All of these issues were with files inside the vault. I know well enough that moving things outside will cause plenty of issues. I verified that all the references were correct with File/Find References before checking assemblies in.
One thing that I have found that can cause this is the user that tried to move the part did not have 'delete' rights to the file. EPDM "moves" files by making a record change in the DB, the physical file is copied to the new folder on the disk (yes a folder does exist on the hard drive) and then part file in the old location is physically deleted from the hard drive. It sound like this may be what you ran into. Also remember that the user needs delete rights in the folder and workflow state!
I may have a few technical details wrong in my explanation. But the end effect is what I have seen in the past.
I have delete rights. The solution was to delete the local copies that solidworks re-created from the cached copies, clear the cache and then re-open the assembly and repair the corrupted references.
Honestly, my largest concern is that this happens at all. EPDM is sold with a promise that you can drag and drop files and the references will always remain. The problem I had to fix should never happen according to those who sell the software. In my experience from using other PDM programs, (not with solidworks) I've never experienced these kind of problems. I've been using solidworks for 8 years and was an admin for ProE using interlink. I just never expected to be dealing with lost references once things are inside EPDM.
So, my next question... Why does EPDM not have a proper move function. An operation that clears local copies, clears cache and actually moves a file without leaving garbage behind?
I wish I had an answer to your last question. Many of us that have used EPDM for years have been asking the same question!
Regarding the delete rights there are a couple of things to keep in mind.
- EPDM's Delete command does not truly delete a file from the local cache. The Destroy command truly deletes the local file, DB record, and the archive copies (after the cleaner function runs at night). The Delete only hides the file from the vault display and marks the record in the DB. Thus the file can be recovered from the trash. When SolidWorks "recreates" the file the file becomes visible as a "local file" in the cache.
- If the user did not have the Delete right in a earlier workflow state but has it assigned to him in a later workflow state the user may still not delete the file. Refer to the Ignore permissions in previous states option in the workflow states. This option has been the cause of many EPDM Admins sleepless nights over the years.
I have been around EPDM for a long time and has seen literally 1,000's of files moved around inside the vault without a single failure that I can remember as long as the vault settings were correct. So there must be some form of settings problem that you are running into or a new bug that I am unaware of.
I've been working with Solidworks and EPDM for a long time which gave no broken references.
There is a local file clean-up-setting at the group/user settings.
We also have "show only files that are part of the file vault"
I am very sorry to hear that you are having "Reference Problems".
1. Please confirm that you are"Moving Files" not "Copying Files" from the External location ito EPDM.
2. When you Move files into EPDM the Path needs to be the same, for instance
- Files outside are located in: C:\Projects\ACME\Enclosures\
- When you move them into EPDM you need to keep the path the same from \Projects\ACME\Enclosures\
- Check in all of the files
- Then move them in EPDM to the new location.
If you are moving files on the network, without updating the references before adding them to EPDM, you are starting out with broken references.
If you need additional help see us at:
Kip speck CEPA
I was moving files in the vault. This was a move from a vault job folder to a vault library folder. This shouldn't happen. It has to do with EPDM leaving a mess behind itself and not searching properly. There was a copy remaining in the local cache after the move. When the assembly was re-opened and the part was not found in the last location, EPDM recreated the part from the cache copy and corrupted the references instead of finding the correct part in the updated library location. Aparently move can only be done safely when all users have cleared their cahche. It appears this is an issue that Solidworks is aware of, but doesn't really have a fix for.
To reiterate what I said above. This could be fixed with a move operation that would remove all local copies and all cached copies on every machine.
We are experiencing similar issues. We are losing file references during moves as well as file renames. User A renames files in the vault with Solidworks closed. Everything appears fine on user A's machine. User B goes to open an assembly and now it's looking for parts with the old name. A get latest on user B machine doesn't seem to resolve it either. Only resolution thus far has been checking out the assembly containing the renamed part, fixing the broken references, and checking the assembly back in. I haven't been able to reproduce it consistently yet.
While it's not same here's an SPR for a similar issue SPR 514412.