Why solidworks asks to save unmodified files?

[sergio.monti]

Very often when save changes to parts I'm working on, I'm also asked to save parts or subassemblies apparently unrelated to the part or subassembly I modified. I'm sue everyone using Solidworks noticed it.
Does anyone know the logic around it? What will be the implication to choose to 'save' or 'not save' the unrelated parts?
Thanks

[TTevolve]

I usually only see this when I am working on an assembly, generally when you save the assembly it will want to save the parts as well. Could also happen if you have references to another part in your part that your saving, I typically don't do that often though.

[DanPihlaja]

Things can get messy really fast if external references aren't paid attention to.

It could be loading parts into memory only that are referenced....and then trying to save them.

I have seen many designers just firing from the hip and not paying attention to the external references that they are creating. I have had to fix a few assemblies that just had a spiderweb of references all over the bloody place. Some of them looping. And then the designer decided that Solidworks was the problem instead of paying attention to what they are doing (not accusing you of doing this....its just what my experience has shown).

[bnemec]

@sergio.monti I'm curious, are your files in some PDM/Vault?

[Tom G]

I have experienced what you're talking about fairly commonly. What I think OP is talking about is not a contextual component that you would expect to save even with an unchanged rebuild, like a virtual weldment part. This happens to me with library components, a simple fitting or valve that is independent and used in many assemblies.

What I believe is a cause, though am unable to reproduce intentionally, is something as simple as showing or hiding reference entities, combined with the use of display states. This happened to me last week in fact, and it goes like this:

Open CurrentAssembly and work on it for a bit. Close the assembly. Open ArchivedAssembly for reference of how something was done before. In ArchivedAssembly, all I'm doing is taking a measurement, and maybe changing view either by section view or design state to expose what I want to measure. Then I close ArchivedAssembly, intending not to save the changes, and I am prompted the most basic and common library fitting needs saved, Tee.sldprt which is certainly present in both assemblies and not interacted with in any intentional way in this session. I bypass that dialog and continue my workflow without saving.

It is still due to change. Historical change, not something that you did to it now today.
* Since I am inspecting a past work, surely there are new configurations in this component added since then, for a new combination of rating, size, and material. Perhaps this could be a minor cause.
* More relevantly, perhaps in one assembly I had decided to hide or show something like its origin, a reference plane, or a 3D sketch, and the other assembly has a display state with opposite conditions. The Part is conflicted only in what is shown here vs. what is not shown there, and when opened in either context, the assembly will want to save this minor change back to the Part. Maybe in one assembly, I wanted a valve part's Handleswing Sketch hidden for clarity, and in another I wanted it shown as default so I could inspect for motion clearances.
* Yet another change could be the renaming of a reference entity used in Mates in both assemblies. When Archived was created, a primary reference entity had not been named "correctly" to agree with standardizations that came along much later. For example, at the time a primary Axis was still named Axis1 and mated to, when later it would be renamed in the Part to Axis or Through Axis. The assembly recognizes that the renamed entity is still the same entity and does not break mates which use it, but then wants to save the Part because something here being used has changed in its own context, and it doesn't want to lose anything for you.

That last bit is important and overarching. The software crucially does not want to lose anything you're doing. It doesn't matter how insignificant.

The components I am discussing are entirely independent library components, but that does not mean that they do not change over time, with expanded configurations, new references, or varied hide/show uses elsewhere. Another one that prompts very frequently for me is Socket Flange.SLDPRT for the similar reasons. It is used nearly everywhere, and is free to be implemented as needed where used by each user.

[HerrTick]

Set the option to open external references read-only. Take write access only when you need it. only save deliberate changes.

Also helpful to set collaboration mode so it's easy to toggle read-only/write-access

[Dwight]

I find that anything with more than one configuration is always marked as changed.

Dwight

[jcapriotti]

I find that anything with more than one configuration is always marked as changed.

Dwight

Happens a lot if you don't rebuild all configurations every time you work and save a part/assy file. Just a simple rebuild on one configuration will flag the others as needing a rebuild. If you only save the one, then any assembly that uses the others will want to save that part file.

[HDS]

Hiding planes or sketches can cause a change in the file that it will ask to save.

I think there a message just for this but if the file was created in an older version it will want to save it to the newer version when it is closed.

Henry

[Alin]

I suggest reading the What’s New in SW2023 document. You might be pleasantly surprised.

[Ry-guy]

The obvious answer is that the files may be an older verion of SW and when opened the "internals" of the file are updated to reflect any added data into the newer version part files.

But, as you have found, there are many, many different causes!

[ryan-feeley]

* More relevantly, perhaps in one assembly I had decided to hide or show something like its origin, a reference plane, or a 3D sketch, and the other assembly has a display state with opposite conditions. The Part is conflicted only in what is shown here vs. what is not shown there, and when opened in either context, the assembly will want to save this minor change back to the Part. Maybe in one assembly, I wanted a valve part's Handleswing Sketch hidden for clarity, and in another I wanted it shown as default so I could inspect for motion clearances.

Yes, I believe this is the expected behavior. You can freely chose from existing Part display states in an Assembly without changing it. RMB the component and select “Component Properties”. An assembly can only override appearances, so if you alter body, plane, or sketch visibility, the part requires save to apply the new settings to the part file.

However there is a bit of a quirky/bug, at least in every version I've used:

In an assembly, the visibility of a part’s planes/sketches/etc is tied to their visibility in the active Display State (DS) in the part model, NOT the Display State currently used by the assembly. So per the in-use or last-saved version of the component model.

• Consequence 1: when you change the visibility of a part’s plane/sketch in an assembly, the change gets reflected in the current in-memory version of the part. Not the part’s DS used by the assembly. The **part file will be marked dirty** if it is open. If the part file is not open, when you try to save the assy, it will want to save the part file, and the saved changes will modify the DS that was active in the part’s “in-use” (last saved) configuration.
• Consequence 2: if you want assembly-level visibility changes to reliably propagate to the correct (i.e., current) display state of the part, you must:
  - link display states and configurations in the associated Part File
  - AND have only one DS per configuration.
  - But this forces you into configurations to manage appearances, which is likely a bad move. It forces any client of the part to juggle configurations.
• Consequence 3: if you have two copies of a part file in an assembly, if you change the visibility of a sketch in one, it is changed in the other as well.
  - This is true even if you have a different Part Display-States active for each copy.
  - This is true even if the part file is present as two different configurations
• Consequence 4: if you don’t want sketches appearing in your assemblies when sketch visibility is ok, make sure you have at least one part display state that hides all of them. Make this the active DS when you save the part.

If you just want to fiddle around with visibility in an assembly, but not save the part, the RMB and "reload" feature to reset the in-memory version of the part to match what is saved on disk is your friend. But be aware that if the active configuration is the model doesn't match the last-saved version, a part will be dirty even after reload. The software acts as if you'd reloaded the part, but then changed the active configuration, which is reasonable, but of course makes the part dirty.

[berg_lauritz]

I will list/gather some causes:

1. external references to a component that changed (this may include components that have equations linked to a file, linked sketch blocks, changed naming, sometimes faces (esp. within sheet metal parts) get a different ID when you slightly change a dimension on a part - anything i.e. mated/related to that face will need saving)
2. external references that are "in the wrong order": Part A is linked to Part B, Part C is linked to Part B - the update holders show though, that Part C is updated first:

   

   2022-12-19 09_15_28-SOLIDWORKS 2021 SP4.1 - [B080584.SLDASM [Read-only]].png (6 KiB) Viewed 10285 times

3. changing visibility of reference geometry of a component from a higher level assembly to i.e. mate (because you change it "within the component" for solidworks
4. double clicking a component feature (even if you change nothing you "edit" the feature & that will cause it to be "tagged" as changed. Features sometimes do only update properly if you edit them once - even if you "x" out of them the error will persist)
5. virtual parts (or worse: virtual assemblies with virtual parts in it <--- endless saving!)
6. inserting a component with a configuration that has no display data mark attached to it & it was NOT saved with that configuration visible (SolidWorks does not save graphics-data for configurations without a display data mark. So if you insert this configuration, SolidWorks has to calculate this exact graphics data & thus "changes" the component)
7. sometimes display states can cause an issue & they need to be re-saved to work properly (similar issue to above)
8. drawings sometimes need a double rebuild because the sheet format might not update properly the first time (it will be visible in the feature tree though)
9. any part (including virtual ones) that is not saved in the current version might cause this (you have to resolve the parts/virtual parts & save them to get rid of it!)
10. Equations (totally forgot that one @Frederick_Law, thank you for that!) - sometimes it might be fixed through multiple forced rebuilds, sometimes they will always fail depending on configurations, sometimes they will flip flop around...
11. Changes to properties / Changes to PDM data cards

& some more that I did not yet confirm but I do encounter them regularly:

• Old sheet metal parts (with no sheet metal folder in them) might need regular saves for no obvious reason
• sometimes you need to go into a specific feature & just hit okay & rebuild the part & save to fix it (often happens with i.e. sheet metal parts: You might have to switch the "reverse direction" checkmark to fix everything
• sometimes you need to delete & re-do a feature to make it work again (esp. assembly cuts seem to fail regularly - parts i.e. stay untouched by the feature although it says i.e. through all)
• pre-2019 cosmetic threads might need updating
• If you i.e. insert Part 1 first, then Part 2 & you link Part 1 to Part 2 everything might look fine - but as soon as you open the dropdown menu in Part 2 it might show you mate errors although it is fixed in place! Deleting & re-doing seems to be the only fix. The inserted order seems to play a role esp. with MasterSketch-Parts!
• Reference geometry/sketches in an assembly that i.e. change depending on configurations seem to need endless re-saving no matter what! Even adjusting the order of the update holders does not seem to fix it!

[Frederick_Law]

Equations.
SW don't solve some equations and it'll flip flop the result on each rebuilt.

[ryan-feeley]

Equations.
SW don't solve some equations and it'll flip flop the result on each rebuilt.

I've notice this tends to happen if you have "automatic solve order" unchecked for equations, and your equation order doesn't match the order of your feature tree. Depending on the model, I believe this can create a bit of a circular situation that solidworks doesn't flag. I've also seen situations where the "automatic solve order" appears to cause the problem. I guess the AI just isn't good enough.

To keep my models predictable, I use "automatic solve order" unchecked, but I try to keep the equations order and the feature tree order relatively in sync. After any big model refactor, I use a kludged together python script I wrote that processes

• an export of the equations to .txt

• a macro-based export of the feature tree to .txt

and tells me the order the equations should have to match the feature tree. This seems to help prevent this sort of unexpected modified/rebuild stuff.

I'm sure there could be a slick macro-only solution that would do all the work, and the re-ordering, but my python kludge works well enough for me. I'll can share it if anyone is interested.

[Chris Oxford]

Very often when save changes to parts I'm working on, I'm also asked to save parts or subassemblies apparently unrelated to the part or subassembly I modified. I'm sue everyone using Solidworks noticed it.
Does anyone know the logic around it? What will be the implication to choose to 'save' or 'not save' the unrelated parts?
Thanks

I've hated this for years. I think I finally solved it, at least for us:

In Options-->System Options-->External References, see below snip (check the Don't Prompt to save read only... and UN check Force referenced document to save...)

Made an account just to add this, so I can find it later.