A while ago one of our engineers called me to show what is happening with a certain assy and its drawing.
he opens the drawing and check it out together with its assy from within solidworks.
At this point the drawing disappears and another assy shows up and when it is fully loaded disappears and the initial drawings comes back.
He told me that the first time he checked out the assy another big assy in the same folder (apparently unrelated) was loaded taking quite some time and it was quite annoying.
I gave a quick look at where used etc but apparently those files are really unrelated no parent children relation between each other.
next week I will try to take a better look, but there is no apparent reason to fully load a random (?) assy when checking out a drawing and its assy.
Once loaded sw switch back to the original drawing window like nothing happened. This is one of the strangest thing I ever saw in PDM and I have a nice collection of oddities.
Checkout triggers unrelated files to load
Checkout triggers unrelated files to load
I finally analyzed the file and it was a user made problem.
First during checkout I looked at the confirmation screen and the first thing to notice was the "total files" involved in the operation in the bottom left corner of the window: it was three files instead of two (assy and its drawing).
that total is the sum of every check boxes activated inside the confirmation dialog: it gives you the "checkout" + "get latest" columns total.
In our case the user selected the assy and its drawing to check out and SW AUTOMATICALLY added another assy checkbox in the GET column and loaded it up.
why that happened?
because the user imported a huge assy as a reference for two small components position, made it a virtual component, "forgot" to delete 99% of the other unused components and instead SUPPRESSED them all.
This triggered SW to GET the whole suppressed assembly during checkout (for its own reasons) and unchecking it gave the expected result of an instant checkout.
I have not stressed enough to avoid to use SUPPRESSION as a cheap and quick alternative to DELETE.
Then I am not a fan of virtual components as I had some users that did not realized the the virtualization made their assy completely detached from the external models they thought they were referencing. Let alone performance issues and the possibility of data corruption as those virtual components are cached into the temp folder outside the vault potentially creating caos.
Go to full postFirst during checkout I looked at the confirmation screen and the first thing to notice was the "total files" involved in the operation in the bottom left corner of the window: it was three files instead of two (assy and its drawing).
that total is the sum of every check boxes activated inside the confirmation dialog: it gives you the "checkout" + "get latest" columns total.
In our case the user selected the assy and its drawing to check out and SW AUTOMATICALLY added another assy checkbox in the GET column and loaded it up.
why that happened?
because the user imported a huge assy as a reference for two small components position, made it a virtual component, "forgot" to delete 99% of the other unused components and instead SUPPRESSED them all.
This triggered SW to GET the whole suppressed assembly during checkout (for its own reasons) and unchecking it gave the expected result of an instant checkout.
I have not stressed enough to avoid to use SUPPRESSION as a cheap and quick alternative to DELETE.
Then I am not a fan of virtual components as I had some users that did not realized the the virtualization made their assy completely detached from the external models they thought they were referencing. Let alone performance issues and the possibility of data corruption as those virtual components are cached into the temp folder outside the vault potentially creating caos.
Re: Checkout triggers unrelated files to load
Check to see if any part in the assembly has an in-context feature that references the other assembly that is loaded.
Re: Checkout triggers unrelated files to load
I suspect it is the case, but our settings disable the update of external references and they should not be loaded at all.
I will check the system options and from the assy tree RMB menu the external references.
Re: Checkout triggers unrelated files to load
I finally analyzed the file and it was a user made problem.
First during checkout I looked at the confirmation screen and the first thing to notice was the "total files" involved in the operation in the bottom left corner of the window: it was three files instead of two (assy and its drawing).
that total is the sum of every check boxes activated inside the confirmation dialog: it gives you the "checkout" + "get latest" columns total.
In our case the user selected the assy and its drawing to check out and SW AUTOMATICALLY added another assy checkbox in the GET column and loaded it up.
why that happened?
because the user imported a huge assy as a reference for two small components position, made it a virtual component, "forgot" to delete 99% of the other unused components and instead SUPPRESSED them all.
This triggered SW to GET the whole suppressed assembly during checkout (for its own reasons) and unchecking it gave the expected result of an instant checkout.
I have not stressed enough to avoid to use SUPPRESSION as a cheap and quick alternative to DELETE.
Then I am not a fan of virtual components as I had some users that did not realized the the virtualization made their assy completely detached from the external models they thought they were referencing. Let alone performance issues and the possibility of data corruption as those virtual components are cached into the temp folder outside the vault potentially creating caos.
First during checkout I looked at the confirmation screen and the first thing to notice was the "total files" involved in the operation in the bottom left corner of the window: it was three files instead of two (assy and its drawing).
that total is the sum of every check boxes activated inside the confirmation dialog: it gives you the "checkout" + "get latest" columns total.
In our case the user selected the assy and its drawing to check out and SW AUTOMATICALLY added another assy checkbox in the GET column and loaded it up.
why that happened?
because the user imported a huge assy as a reference for two small components position, made it a virtual component, "forgot" to delete 99% of the other unused components and instead SUPPRESSED them all.
This triggered SW to GET the whole suppressed assembly during checkout (for its own reasons) and unchecking it gave the expected result of an instant checkout.
I have not stressed enough to avoid to use SUPPRESSION as a cheap and quick alternative to DELETE.
Then I am not a fan of virtual components as I had some users that did not realized the the virtualization made their assy completely detached from the external models they thought they were referencing. Let alone performance issues and the possibility of data corruption as those virtual components are cached into the temp folder outside the vault potentially creating caos.