The file is not rebuilt

[bnemec]

Skipping rebuilds in PDM could and will lead to a lot of unpleasant things.
our best practice so far: starting from the single part at the very bottom leaf of the assembly tree, rebuild, save and put the data in a locked state so no unwanted edits allowed when the related assembly is loaded.
this operation could be automated imho.

when you have the lowest level of parts rebuilt and locked (usually hardware and catalog parts) start with the sub assemblies at the bottom of the tree and go up rebuilding and locking sub assemblies, but do not lock them until every part inside is locked. we had some very unpleasant surprise with partially locked subassemblies, so if you are doing the job do it properly.
while this operation could be automatized I think an engineer supervision is needed.
it depends a lot on your company wokflow, data structure (shared units, sUb assemblies vs all project in one folder etc), but in the end someone must look at the data and say “ok this one is finished” otherwise it will blow up in your face at some point. and you could find yoirself rebuilding a vault from scratch again.
we are at the 2nd rebuild facing a 3rd one due the the past admin “quick and dirt” decisions. this on top the usual SW bugs and user “techniques” that are already blowing up our legacy 3d models…

Are you saying no file in the vault should want to rebuild when it’s opened? Ie. every single file in the vault should not request a rebuild upon opening?

[mp3-250]

bnemec locked (official-released) data should be rebuilt before lockIng them. at least.

but I had some case of an engineer not rebuilding assemblies.

Engineer A checked in an WIP assy (looking from explorer it had only 2 components in the pdm BOM in fact there were dozen in multiple sub assys inside the 3d data)

As result engineer B with read only permission in the vault loaded that assy and was not able to see a new added part that was supposed to be there in the latest version.

Problem was SW loaded the not rebuilt assy found it broken and modified it locally somehow so engineet B “latest version” was not the same as the server one (green clock icon) and the new added part was not referenced anywhere inside the assy.

I made engineer A load the broken assy he made, check it out, rebuild it from the leaf and check in again.
engineer B was able to see the assy as designed with the real latest version from the server.

My explaination is engineer B was stuck in a loop: he took the latest version from the server (broken) SW overwrote it creating a local new version on the spot (triggering the “newer” flag on its pc; or better a “different from current and past versions stored in the server” flag) remember this user was supposed to read only the vault data.
And even rebuilding the WIP assy locally on his pc was useless.

PDM is a nightmare without proper settings and discipline.

[jcapriotti]

mp3-250 The read-only user having a newer “local (green icon)” version without it being checked out is either a bug, or the user manually removed the read-only flag on the file.

The bug being that sometimes the system may fail to reapply the read-only flag to the local file on check-in, if the user never had checkout rights then that may not be the case here. I’ve seen some programs (like Altium) uncheck the read-only flag themselves but not SolidWorks or office docs. The other way I’ve seen this happen is the user right clicks the file, select properties and removes the read-only flag themselves without checking out the file. Then they can write to their local copy.

[mp3-250]

Engineer B uses SW to check A design he has not interest or skill to tamper the system, he mesasure here and there nothing more.

it could be a bug, but when I made engineer A rebuild its files the BOM tab magically shown dozen of files and B was immediately able to take the latest version as expected.

very likely A put together the top assy checked in once without rebuilding at all than modified only one sub assy witthout touching the parents.

I should have time I investigate properly, but all the hours I spent in debugging SW and PDM (like their bugged reference scripts in task) are hardly paying back my salary TBH.
I would prefere to solve problems with SW rather than solving SW problems.
sorry for the rant

[bnemec]

@bnemec locked (official-released) data should be rebuilt before lockIng them. at least.

but I had some case of an engineer not rebuilding assemblies.

Engineer A checked in an WIP assy (looking from explorer it had only 2 components in the pdm BOM in fact there were dozen in multiple sub assys inside the 3d data)

As result engineer B with read only permission in the vault loaded that assy and was not able to see a new added part that was supposed to be there in the latest version.

Problem was SW loaded the not rebuilt assy found it broken and modified it locally somehow so engineet B “latest version” was not the same as the server one (green clock icon) and the new added part was not referenced anywhere inside the assy.

I made engineer A load the broken assy he made, check it out, rebuild it from the leaf and check in again.
engineer B was able to see the assy as designed with the real latest version from the server.

My explaination is engineer B was stuck in a loop: he took the latest version from the server (broken) SW overwrote it creating a local new version on the spot (triggering the “newer” flag on its pc; or better a “different from current and past versions stored in the server” flag) remember this user was supposed to read only the vault data.
And even rebuilding the WIP assy locally on his pc was useless.

PDM is a nightmare without proper settings and discipline.

I’m pretty sure that if B already had the assembly file and it’s refs in local cache when A made the changes then B would need to actively get latest to see the changes.

When user B opens the file (not checked out so it’s read only) but SW will still update if it thinks it’s needed, then they have changes, but that user should not be able to save the file to their local cache. So user B can see all kinds of changes, but cannot save them. That is tough for some users to grasp that what they see is not necessarily exactly what is checked in.

Let me ask, do you ever change a component (transition to WIP and check out and check back in) that is used by a released assembly that cannot be checked out, even by A due to it’s state?