It’s been like that since I’ve been using it. The error is often a memory error in SolidWorks. I fix it by accessing a part previously opened and rolling the bar up and back down.
It really isn’t something that happens on a weekly basis.
I’ve found a way of locating faulty file that has previously been saved in rollback state.
- Open the assembly that contains the rollback component.
- Navigate to FeatureManager and select ConfigurationManager.
- Right click on top component, select Add Configuration… and see the pop-up error message. The message should contain the name of the faulty component.
- Open the faulty component, undo rollback status and then save.
Sincerely yours,
Roberts
So, I played with “Check active document”, “Advanced Select”, “Performance Evaluation”, and “Assembly Visualization”.
All with no luck. None of those tools checks the rolled back state. (FYI, apparently rolled back state is not equal to the state that says “Needs rebuild” which I thought was going to be a winner…but nope).
That works!!
image.png
In addition to this, if you have multiple parts that are rolled back, it will specify each one separately.
I had this issue today (SW2024SP2.0) After all this time, still not fixed.
I know which part to which the issue referred. I actually did put it in a “rollback state” for , reasons. But I also did “roll to end” when I’d finished.
Thankds for your advise Roberts P. , but this did not fix my issue.
I tried this too.
But this did not do the trick.
I tried this too.
Even shutdown SW in the task manager. Reopened assembly, same problem.
Even restarted my pc and tried again. Nope.
In the end, I created a new subassembly within the assembly to which I wanted to move my assembly and dragged the components of the errant assembly into this new subassembly, one-by-one until all where relocated.
After saving the new assembly with a very similar filename I then deleted the problematic assembly from the model, saved everything, closed the software and deleted the problematic assembly from the project folder.
It was then a simple matter of opening the model and renaming the newly created assembly with the original assembly’s filename and moving on with my life..
For the record, there was no component in the"rollback state" SW was just to stupid to realise this and got stuck in some kind of feedback loop where it felt the need to double-down on its original incorrect statement. This from 2024 version.
the only workaround I’ve found for this is
in the top level assembly, start rolling back parts and assemblies.
if the assembly saves, roll forward a few parts at a time and keep saving.
once the assembly give you the error on save, you have found the offending part or assembly.
if it’s a part, just open it and fix it. if it’s an assembly, repeat the process on that assembly to find the offending part
it’s tedious and a pain in the @ss, but I’ve found it helps get you to the offending part quickly enough.
Were there ever virtual components within that assembly by any chance..? I wouldn’t be surprised if virtual components could trigger this even though they are not existant anymore.
Was the assembly too large to do a sort of troubleshoot as mpaul suggested? That’s generally how I proceed too.
Interesting…
I’ve never occurred to me to notice that an assembly might not save with a rollback’d part.
And so I actually just tried this, and my mileage varied greatly. Or I did it wrong.
My assembly did save without any issue despite purposely setting up a rollback’d part. No error or warning was offered.
And, I could not seem to get my assembly rollback bar to go any higher than the “Mates” folder. (In every assembly I tried..)
Traditionally, any rollback part issue I encounter is almost always clearly indicated by the forest fire of broken mates, and in-context features in the feature tree.
That is why the issue that led to this post was so confounding. There WAS NO rollback’d part.
SW was broken. Although there HAD BEEN a rollback’d part, I definitely rolled it forward againg.
There had to have been a glitch in the code somewhere that had corrupted that particular assembly I tried to move.
Thank you
Thanks Alex.
I never used virtual parts, so this is/was not my issue.
This rollback problem indeed exists on multiple levels.
Real rolled back components are a thing, but I had some corrupted files without any apparent issue.
I suspect that neglecting to rebuild all configurations with CTRL SHIFT Q (not only the active one witj CRTL Q) is going to bite back sometimes with the data Inside assy “not in sync” with the real state of its own components.
Add all the lightweight, and large assy mess we had in the last 15 years to the equation …
Also data based on bugged, corrupted or very old templates gave us some funny (not so) issue In the past.