rollback a parent assy by mistake?

[mp3-250]

I did a rollback of an assy and its drawing only (no child components Included) last week. I am always extra careful with rollbacks as many unwanted referenced files could be included by mistake.

this time I rolled back 2 files but according to the history a third file, a parent assy of the rolled back one was rolled back at the same tIme losing about 10 versions...how is it possible?

the only case I had close to this was a drawing referencing 2 different modelsand the rollback check was on and greyed out so I had to rollback the drawing and the 3d data separately.
Anyway I am pretty sure that redirection aside it is not possible to roll back a parent assy from the rollback screen of a child... am I wrong?

[JSculley]

I was able to replicate this behavior with a pretty simple test, and it is quite alarming. Here's what I did:

1. Create a new assembly
2. Create a sketch in the assembly
3. Save
4. Create a second assembly
5. Create a sketch in the second assembly
6. Save
7. Create a drawing of the second assembly
8. Save the drawing
9. Add the second assembly as a subassembly of the first assembly
10. Check-in all three files with comment 'INITIAL CHECK-IN'
11. Check out all three files
12. Open the top assembly
13. Edit the subassembly in-context
14. Edit the sketch
15. Add a relation between the sketch and the sketch in the top assembly
16. Exit the sketch
17. Exit in-context editing
18. Open the subassembly drawing
19. Save the drawing
20. Return to the top assembly
21. Save
22. Check-in all three files with comment 'ADDED IN-CONTEXT REFERENCE'
23. Check out all three files
24. Edit the subassembly in-context
25. Edit the sketch and remove the in-context relation
26. Exit the sketch
27. Exit the in-context editing
28. Open the subassembly drawing
29. Save the drawing
30. Delete the sketch in the top assembly.
31. Save
32. Check in everything with comment 'REMOVE IN-CONTEXT REFERENCE'
33. View the subassembly drawing history
34. Select the 'ADDED IN-CONTEXT REFERENCE' version and click 'Rollback'
35. Tell the rollback dialog to rollback referenced files
36. The dialog will show the drawing and the subassembly. The top assembly is not listed
37. Complete the rollback
38. Open the top assembly
    
    Magically, the model has no issues. Why? Because the top assembly was rolled back and it was never mentioned during the rollback process. WOW! Just WOW. SOLIDWORKS obliterating data with no warning.
    
    So, this is one scenario where you can see the behavior you describe. Thanks, I hate it.

[bnemec]

If I follow, this is all due to the context ref back to the upper-level assembly. In Solid Edge files these refs were referred to as "reversed" which made sense to me.

Most of the files in our data set have many where-used so context refs are taboo. But that's not saying they don't exist, some users... Since PDM refuses to find a way to show where used, aside from drawing nodes, in the File Reference Dialog it's completely silent. Design Manager tool for Solid Edge is all about working on file reference structures but it can add where used files to the grid and effect changes to those as well. It seems PDM is effecting changes without showing the where used. I wonder if this happens to other things that use the File Reference Dialog such as change state, get, checkout/in...

[JSculley]

What should happen when the drawing and subassembly are rolled back is this:

The main assembly should not be touched at all and the references in the subassembly should become broken. The fact that PDM deletes one or more versions of the main assembly to meet the reference requirements of the subassembly is unacceptable.

Further experimentation shows that it only happens when you rollback the drawing and include referenced files. If you roll back the drawing alone, and then the subassembly alone, the main assembly is not rolled back. This is definitely a bug.

[bnemec]

I certainly agree it's undesired behavior. However, based on other things I've seen I wouldn't be surprised if they said it was intended behavior.

All too often the marketing message is how the software "fixes" things for you, and how many times has marketing mentioned things like "Do you struggle with broken references in your data set?" So, when there's an option between destroying data and "automatically fixing references" for the user I bet they chose "fix" references. This is why I always take note of the author and VAR/company of the blogs that push the data integrity back onto the user and educate how to keep the file references safe vs those that are claiming the software will effortlessly fix everything.

Or it was just going to take too much more time to implement the components of roll-back that would gracefully handle context/reverse refs. That ol' 80/20 rule that managers wield, sucks to be in the 20%.

I assume you've wrote exhaustive test plans where every possible path is identified and dealt with in some way.

[mp3-250]

@JSculley

Thank you very much I was able to replicate the issue on 2021 sp5.1

this is a very big problem for us.
forthe moment I will rollback the data Individually, but it is quite scary and it needs more tests.

[mp3-250]

@bnemec the main issue I have is the lack of warning or report BEFORE the rollback.
it took 1 day to fix the assy I broke and the engineering department noticed it because they are working on it right NOW.
what about the last 6months or 1 year or more ? are those data ok? are they broken at some level down the assembly??
we blamed the lack of pdm awareness, but this bug is making me think twice.

[bnemec]

@bnemec the main issue I have is the lack of warning or report BEFORE the rollback.
it took 1 day to fix the assy I broke and the engineering department noticed it because they are working on it right NOW.
what about the last 6months or 1 year or more ? are those data ok? are they broken at some level down the assembly??
we blamed the lack of pdm awareness, but this bug is making me think twice.

I'm not disagreeing with your points. Its just that this doesn't surprise me. I partially blame lazy/oblivious 3d CAD users of the early 2000s all crying about the file references they broke. (I still blame CAD users that are too lazy to understand 3d file references but that's another story) So CAD developers took that feedback as "never leave broken references at all costs" but adding all the logic to catch the nearly infinite set of cases then classify them into types so an accurate warning dialog can be displayed can be as big of a job as the base functionality, so it's often not done.
Also, another case of you can have function A and maybe use functionality C, but we don't know how it will react when you also use any functionality G through Z. So you want some kind of top-down modeling method that create reverse direction file refs? Okay. Oh, you want PDM, okay that might work with top down. Oh, you want to roll something back in PDM that has reverse file refs? No problem, we handled that too, it will even fix your file refs for you. But it's going to assume you want to throw away work and not ask about it. There are infinite ways for users to go off the path of good CAD data and no guard rails. Best part is the "training" that so many claim to be the cure all does nothing for this.

[mp3-250]

@bnemec

I got in touch with my VAR and the SW development guys confirmed that rolling back a parent assy is unexpected behaviour.
They assigned a SPR number and it is under review at the moment.

SPR 1245006
Parent assembly is unexpectedly rolled back when rollback is done for drawing in the component.

[bnemec]

@bnemec

I got in touch with my VAR and the SW development guys confirmed that rolling back a parent assy is unexpected behaviour.
They assigned a SPR number and it is under review at the moment.

SPR 1245006
Parent assembly is unexpectedly rolled back when rollback is done for drawing in the component.

good to be wrong.