That all being said, this document outlines known issues that may arise as well as some practices that can help mitigate them.
The two main categories of issues are those that are due to hardware and those that cause logistics issues.
Hardware-based issues manifest in three ways: a specific error, corrupt files, and slowness during opening, saving, or general use of SOLIDWORKS.
Specific Errors: Known specific errors include “An API call exited abnormally” or “Failed to save document” when trying to save a document (shown below).
Both of these errors occur because of a loss of communication or connectivity between the client and server machines. The loss of connectivity may not have occurred during the save command (as this generally causes file corruption) but sometime during the open session of SOLIDWORKS while the model was being modified. While accepting the error and trying to use the ‘Save As’ command instead of ‘Save’ to save the model edits to a new file name can work at times, these errors are often terminal; the work done is lost and the file cannot be saved.
Corrupt Files: File corruption occurs when saving the file to a network location and can be linked to connectivity issues in the network (likely occurring during saving) or can be attributed to a crash of SOLIDWORKS during saving. Corrupt files can sometimes be repaired via a request to SOLIDWORKS by your VAR; often the files cannot be reconstituted perfectly and it is better to restore from a backup and proceed from there.
Slow Performance: SOLIDWORKS is measurably slower on opening, saving, and working with files on a network hard drive as compared to the client machine’s local hard drive. Saving and Opening operations are slow because the theoretical upper-speed limit of a network is still slower than the data access rate of a local hard drive. General slowness when working with a model after it has been opened is mainly due, in part, to SOLIDWORKS storing the temporary data for a file in the same directory as the original file, on the network hard drive. This constant, passive exchange of data between the client machine and the server causes a slowdown in all parts of SOLIDWORKS.
Connectivity Issues: The connectivity issues discussed thus far lead to instability in SOLIDWORKS when working with files stored on a network hard drive. The exact cause is not known but would seem to be heavily dependent on the architecture of the network itself that connects a client to the server. This instability will, at times, cause SOLIDWORKS to crash without any discernible pattern.
Logistics-based issues with how SOLIDWORKS opens and saves files causes issues with 1) external references in files, 2) revision control, and 3) document access and tracking
Broken References: SOLIDWORKS files contain references to one another that are not handled in any way by Windows Explorer. The actions of renaming, copying, and moving files can result in broken links between files which can be time-consuming to repair and must, at times, be completely remade.
Revision Control: Revision control is a completely manual process that involves not only renaming, copying, and moving files and all the issues that come with that in addition to not having a clear command that can revision singular files inside an assembly. The files must be copied and manually replaced within the assemblies it is used.
Access Control: Having users directly access model files on the network leaves no ability to document or limit access to documents to users editing, renaming, moving, and deleting files without the use of other third-party software.
Utilizing server storage outside of PDM does not have insurmountable issues that would prevent its usage. There are few processes that a company, as well as its engineers, can implement to keep the issues to an absolute minimum.
Server Backups: While storage on a network hard drive seems like a backup in itself, it is not sufficient in this case. Regular backups of the server data itself to a secondary location are crucial when trying to recover from these known issues. Since the file storage area is readily edited in ways that cannot be tracked or controlled in a meaningful way. Restoring to backups may become your only option to restore work to a proper and functional state in order to move forward from these issues:
Data Structure and Referencing: First, it is important to set up the file structure on the network before major work starts and brief all engineers on how the folder structure is meant to work. Beyond that, all engineering machines should be pointed to this folder structure via their ‘Reference Documents’ to ensure external references of assembly and drawing files do not become broken. Within SOLIDWORKS, under ‘Tools’, ‘Options’, ‘System Options’, ‘File Locations’ there is a drop-down list to ‘Show folders for…”. Under this list, the category for ‘Reference Documents’ should point to all the folders with engineering data that are stored on the network (referencing a top-level folder does not also reference the sub-folders so sub-folders need to be included). This should be identical on all engineering machines to ensure all engineers reference and use the same data.
Revision Control: Revision control should be managed using file names. In this scenario, the file name itself would contain a string of characters denoting the revision the file is to avoid external reference cross-linking. Cross-linked external references are common when many files share the same names; it is easy to open an assembly or drawing and accidentally link it to the incorrect file. This is also why you want regular backups as when assemblies/parts become cross-linked it takes less time to revert to a backup and move forward than the time it takes to sort out how the files are cross-linked and fix them. Whenever going to the next revision, use “Pack and Go” to copy, and rename (the revision strings in the file names) all at once. Sending files should be the responsibility of a single user who is very adept at the “Pack and Go” tool.
“Pack and Go”: Possibly one of the most important things you will do with your data is move, copy, or rename it. For these actions, always use the "Pack and Go" function (located under 'File', 'Pack and Go' within SOLIDWORKS ) for every copy, move, or rename operation in your revision system. This is to ensure that external references are maintained properly and that copied file sets (as are created when SOLIDWORKS ) are completely dissociated from their previous original file sets.
IT Level Access Control: It is advised that IT place some measure of control over engineering data. This would mean allowing read/write control to engineers working on the data whereas unrelated departments (sales, marketing, etc.) may only have read access to engineering data. The opposite also holds true in that engineers should be given read-only access to non-engineering data if necessary. This is to limit the possibility of unauthorized modification of the data (either authorized or unauthorized). As such, no engineering data should be stored outside of the protected folder structure and copies found outside the protected folder structure should, as a policy, be considered invalid (it is discouraged to have engineers making their own piece-work data sets).
Collaboration Tools: SOLIDWORKS contains a set of tools that, when turned on, allow a user to take ownership of a network file away from another user and give it to themselves to allow the file to be edited. These tools also allow files only to be viewed and not directly worked on to have file ownership released. These tools can help give users control over write access to files that are commonly in use where other users may inadvertently have them opened with write access when it is not necessary. Company policy should control how this is used.
The issues listed as ‘hardware-based’ cannot be mitigated without first copying the files experiencing those issues to the local hard drive of the machine. Because this inevitably leads to breaking external references of files as well as leading to version skew of a file within a single revision level (when one revision of a file exists in many different forms and places) it is not recommended to copy files to the local machine hard drive to try to get around these issues. It is when these issues lead to severe issues in the engineering workflow that a PDM system should then be considered. These issues are:
In conclusion, file management is possible without the use of PDM software but is rife with issues and limitations that, in practice, happen frequently within companies that use this method of file management. While issues can be mitigated they cannot be eliminated entirely.
I hope you found this article on non-PDM file management helpful. If you enjoy this content please consider subscribing to our blog.
About Ryan Dark
Ryan has been in the GoEngineer technical support team since February 2008 where he most notably provides support for all FEA and CFD software offered by SolidWorks. His most recent accolade is the title of Elite Application Engineer awarded by SolidWorks Corp.
Get the latest articles delivered daily to your inbox, unsubscribe at any time.