I just spent one day to track a problem connected to some issues with had in the past years.
And the likely cause is (again) the administration UI that is "sub optimal" judging from the level of bugs and its poor usability.
This time I got a call from a dept that used to make orders exporting a Solidworks PDM BOM. They noticed some order codes were overlapping and repeating in different parts.
We were lucky to catch them at that stage before ordering a lot of parts.
what happened
Engineers copied some old data from within PDM, and made some new drawings out of them. (tree copy usual stuff)
YEARS LATER they revised some of those drawings and the moment they kicked off the revision transition, the order code variable changed into a value it had within the file it was copied from.
the variable in question is currently "version free" so it is supposedly overwritten at every change and it does not have any kind of history into the DB.
The background
until 2019 we used the variable for the order code in pdm linked to the file properties: in case of a code update you needed to check out the file and it was a pain to maintain.
In 2019 the former admin changed the variable to "version free".
At this point according to solidworks you cannot use a linked property with the version free together.
The UI, once you check the "version free check box, hides the file property link interface so you cannot use both settings together.
THIS IS, WELL.... IN THEORY.
Our former admin did not delete the property link BEFORE turning on the version free check.
According to thepdm administration UI designer it was nice just to HIDE the file properties portion of the settings dialog even if it was already setup and used in the vault.
result: we ended up using both version free variable and the same variable linked from within the file properties at the same time, a thing that should not be possible according to solidworks.
And the file property variable was prioritized and overwrote the version free one in the datacard.
We have like some 100s files that are showing a wrong code atm.
The solution
I am waiting for SW developers to answer my long list of complaints via our VAR, so it is a provisional solution I tested in a non production vault.
1. disable the "version free" check box for the variable
2. at this point the old setting for the linked file properties shows again (sic)
3. delete the linked property leaving everything empty.
4. check again the version free box
I need to test it a bit more but it seems to work and the transition does not trigger the version free variable overwrite in the datacard, as expected.
This issue got unnoticed for likely long, because you know, we tend to "trust the system" for basic stuff.
And we needed to kick the revision of these data to trigger it.
Another explanation could be a REGRESSION in solidworks and since 2019 we moved to sw 20,21,22,23 all SP5 (or SP5.1 depending on the year) and we noticed the issue was THAT BAD only recently after 1 year of sw2023 sp5.
After thoughts:
We had some other strange issue with our vault and they did not have a plausible explanation according to our VAR and SW was not aware of any issue at the time.
Well, one of the issues was a explorer column that was showing the very same variable I am talking here.
the problem: sometimes the value inside the column did not existed in any past version the file had.
it had nothing to do with it at all and it did not matched the datacard either. (including @ configuration or any other inside the datacard if you were wondering it)
Still it shown that value for "reasons".
That was for some simple hardware, that was likely copied from a similar file inside the vault, then renamed and somehow it kept its "father" variable value...for reasons.
Now I probably understand those "reasons". Please FIX the PDM administration once and for all.
EDIT:
I would like to clean up once and for all the pdm database from the linked file properties dbo.variablevalues table does not seem to have them. where are they saved?
