File Management Basics
One phrase that I always keep in mind when working with SolidWorks files is "single point database". In other words, data is stored in only one place and everything else that needs that information references it from the original.
Let's first take a look at the specific data or information contained in each file type and explore how these file types are associated.
The part files (.sldprt) contain the basic geometric information. This includes information such as chronological history and shapes of all the features, the material, and custom properties specific to the part. The part file does not know (or need to know) which assemblies use the part, or what drawings of the part exist. In other words the "where used" information for a part is not needed in the basic SolidWorks file structure. Note: This "where used" information is tracked in product data management (PDM) solutions, and can be searched for in SolidWorks Explorer.
The assembly files (.sldasm) contain information such as quantities, where the parts are located and mated in the assembly, and exploded view definitions. The assembly does not store the part information because it references the part files for the specific information it requires such as their geometric information. I like to think of the assembly as a classroom. Inside this classroom there are tables, just like in an assembly there are parts. The assembly knows that it contains let's say 10 instances of a table, and where they are located in the classroom. The bottom of the legs of the first table are coincident to the floor of the classroom, and the front edge of the table is 12 feet from the front wall of the classroom, and the right edge of the table is 6 feet from the right wall of the classroom, and so forth.
The drawing files (.slddrw) contain views of any combination of parts and assemblies. The drawing files contain information such as sheet format data, the component names that are shown in each drawing view, and their view orientations. The drawing also needs to reference the parts files for their geometric information, and assembly files for the part arrangement, and exploded view definitions.
That's why when you send a drawing or assembly file you need to send all the referenced component files as well. Tools like File, Pack and Go, and the reliable File, Find References are designed to gather all the files needed, to make sure all the associated files are copied and sent together. An exception to this is without the part files you can still open up the assembly and drawing files as Quick View. This allows you to pan, zoom, and rotate the view orientation (as applicable), but not edit the assembly or drawing.
When using the Pack and Go tool and you use the option to zip up the collected files, I have seen problems unzipping the files later if you use Windows Explorer to unzip. To work around this you can either unzip with a 3rd party tool other than Windows Explorer, or use the Pack and Go tool to gather the files into a folder, and then zip (compress) the files to be sent in Windows Explorer.
To illustrate how these file associations work, let's go over a simple example of an assembly consisting of a dowel pin pressed into a plate. An exploded isometric view of this assembly is to be shown in a drawing.
The dowel pin part file contains geometric information such as the diameter and length of the pin. The plate part file contains geometric information such as the thickness, length and width, and location of a hole in the plate.
The assembly file knows it contains two parts (one plate and one pin), the mates (the pin is concentric to the hole in the plate), and the exploded view information (the pin is separated 1" from the mated position along the axis of the pin). The assembly file needs to reference the part files for all the geometric information.
The drawing file contains an isometric view of the assembly. The drawing file stores the filename of the assembly, the view orientation, and display state (shaded isometric view of the exploded assembly). The drawing therefore needs to reference both the assembly for mating and exploded view data, and the pin and plate parts for geometric information.
What about associatively? If you open the pin part file, double click on the outside surface of the cylinder, change the diameter dimension, and rebuild, the geometric information is changed. If you then jump to the assembly file, the assembly reflects this new diameter. Likewise, the drawing will display the updated diameter in the exploded view of the assembly. That's because it's the same geometric information for the pin used in the part, assembly, and drawing file. In other words, the assembly and drawing files both reference the geometric information contained in the part file.
The exception to all this is the use of internal parts within the assembly file. When creating a new part while in the assembly using Insert, Component, and New, notice you are not asked for a filename. This is because the new part is considered an internal part. In the FeatureManager Design Tree these internal parts have [brackets] placed around the part name distinguishing them from the external parts. All of the same information is contained with the part definition, but the part file information is not stored as a separate file (.sldprt), instead this part definition is stored with the assembly file (.sldasm). Essentially you have your assembly file and inside of that file are the part definition(s) as well. Although confusing at first, there are advantages to this way of working (easy to rename the part), and it turns out, you can save the part definitions externally at any time. Thus you are back to the part and assembly files all written as separate files to the disk.
Make sense? Clear as mud?
Phil Sluder, mechanical engineer, owner of TriAxial Design and Analysis (http://www.triaxialdesign.com/), Certified SolidWorks Instructor, Certified SolidWorks Professional, a longtime member of the SWUGN committee, and leader of the San Diego SolidWorks User Group. He can be reached at firstname.lastname@example.org