Pdm administration is trash: Version free variables edition

SOLIDWORKS SolidWorks PDM
1

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 seems to be programmed by an intern, 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.



what happened

Engineers copied some old data from within PDM, and made some new drawings.

YEARS LATER they revised some 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.

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.
Their UI, once you check the "version free check box, it 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 the genius UI designer it was nice just to HIDE the file properties even if it was already setup and used.

result: we ended up using both version free variable and the same variable linked from 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, 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: the ghosts inside PDM

We had some other strange issue with our vault and they were basically caused by the ghosts inside our vault according to our VAR (aka no plausible explaination) and SW was not aware of any issue at the time. (as usual)

Well, one of the issues was a 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”.

Dear SW developers please listen to me AT LEAST THIS DAMN TIME: your administrative UI for PDM is like that temple in indiana jones films.

wrong button? you die.

right button? you die with MORE PAIN.

2

I agree with you about the hiding settings to “help” the user. I miss the days before context menus. Especially for admin type users, we tend to be utilitarian in general and do not care about pretty GUI. I can see how, in the variable editor, if the custom properties linking GUI elements were not hidden you could have discovered this situation much sooner.

Another “ghost” I’ve learned to look for when strange variable values crop up are values for old configs/sheets that no longer exist. Several times we’ve had ghost values in drawings where a sheet existed, the variable set ( IIRC this was a linked value/property), then later maybe after the drawing was copied to a new number that sheet was deleted. In SOME places that show data card variables this old value would show up. I would have never figured it out had I not searched on the dbo.VariableValues table. If you have ghosts in your data card variable values, I highly recomend getting comfortable with these tables. I have a few saved queries that join various tables, mostly Variable, VariableValue, Documents, and DocumentConfiguration. Also note the HistoryVerFreeVarChanged table.

3

Thank you for the comment.

The first thing I did was to dig inside dbo.VariableValues into every column and lookup for the “wrong values” of the linked properties.
they were not there apparently, I was not able to find a link between them and the filenames if the documents that had their datacards overwriten.
So they could be in the other places you mentioned or PDM is just hiding somewhere the history of supposedly history free variables…

the UI was such a pain that the I wonder how many settings have misplaced and ambigous UI elements.

At the moment I have the description field for user groups blown up and shown empty even if the db has the actual text inside.
Other bugs (one killed our vault for half a day once) were apparently fixed in 2024, but my hopes in pdm are not that high and usually new things are released broken to be fixed in a later stage. such attitude…

4

IMHO and as a absolutely not experienced VBA coder, that was a case for a radio box control that allow you to check one OR the other setting and just grey out the UI without hiding it.
Obviously when enabling the version free a nice popoup would come out telling me “enabling this will delete all the settings for linked properties: do you want to continue?”

SW tells us to avoid touching the DB all the time while they are acting like wild monkeys throwing bananas at it.

5

I just want to mention that we had a strange problem show up with PDM 2019 a few years back where data cards and linked properties on drawings did not match. It turned out to be a strange PDM bug (nothing to do with the admin tool or version free variables) where secret hidden custom properties were somehow created in the SW file that would override the value visible in the custom properties dialog. We ended up having to run a tool created by SW to locate any files with the secret hidden properties. Then we had to delete all the properties from the file and then use ‘Update values in files…’ to repopulate the custom properties from the database. Luckily we noticed it pretty early on and less than 100 files were affected. It was supposedly specific to SW2017 paired with PDM2019 SP5. We had to downgrade the DocumentManager DLL file to SP4 to prevent the problem.

Probably not what’s happening to you, but I thought I’d mention it just in case.

6

Also worth noting is that there’s two kinds of Version Free Variables. Updates All Versions and Updates Latest Version. From what I can tell the All Versions option stores the value as version (column name is revision) = 0. Updates Latest Version stores it more like the regular variable values, but retains value history. What I haven’t gotten to the bottom of is if the variable changes from versioned, to version free and updates all versions, does it clear out all the rows in the variable values table for that variable ID and “revision” >0? If not, I’d guess some of the various places that access the info in that table might be looking it up wrong, perhaps not checking what type of version free it is. This is the risk of third party API users going to the tables for data instead of calling proper API functions to get data. Hopefully the SW/PDM folks would always follow their own rules, but… Also, backward compatibilities are not as simple as using polymorphism.

7

IIRC from what I read from the KB when you switch variable type it is not immediately reflected on all past versions until you open every single file. that’s probably why we started to see our file histories filling up with variables updates entries…

8

I had a database backup from 2022 (sw2021) around and recovered it in sw2023.
Apparently we had very few cases of this issue even back then: still I found 1 file with 5 files copied from it sharing the same code… I looked at their history and the revision was dated 2020… so this problem was likely with us at least since 2019 and simply grown together with our data.

9

Yep, that sounds about right. The system leaves the existing variable values as they are, when admin changes from update latest version to update all, until that file and config needs updated, then it clears out the version rows for that file, config, and variable then makes one at version 0. Well, I think whether it clears the versioned rows for all the configs might be related to if the data card is set to update all configurations.

About the dbo.HistoryVerFreeVarChanged rows. I’ve had success clearing those out. I’d doubt it’s recommended, but they can render the file history window useless. So I delete the rows that are a result of automated ver free var updates.
https://www.cadforum.net/viewtopic.php?p=38093#p38093

10

I did try setting up a test variable in PDM 2023 sp5. I made it a regular variable mapped to a SolidWorks model property. Checked out a model and change the value back, check in, then check out and changed it again. Next I edited the variable and changed it to version free (all versions). The custom property mapping hides. I close the variable editor, then reenter and toggle version free off and the custom properties are gone, so it appeared to deleted them on “ok” of the variable editor.

With it set to version free, I tried updating the custom property directly and checked the file in, it no longer updates the data card. mp3-250 Maybe it was a bug in previous versions. Possible it may not get fixed in 2023 until you edit the variable, toggle the version free box and “ok” the dialogue.

11

Our legacy data had the property linked to the variable in the data card.
Some new data were tree copied from those files to make new drawings and assigned a data card value. it worked even if the custom property from their derived original file was copied inside them and, as you experienced, ignored as expected. then the files changed to a revised state.

The problem did not shown until the instant a revision was triggered.
The file changed state to under revision and the old custom property inside the file overwrites the datacard value that was ok until then.

to recap
legacy data file A with custom property
↓
tree copy new file B with same custom property as A
↓
file B datacard populated
↓
file B released rev: - (no issues)
↓
file B is moved under revision rev:A
(property within the file overrides datacard with same value as file A)

12

This would take some SQL DB table investigation. I’m not sure how well you get around SQL, but here’s where I’d look.


  1. Get the Variable ID from the db table “Variable”.
  2. For that variable, verify that column “FlagFreeUpdateAllVersion” or “FlagFreeUpdateLatestVersion” is set to a value of “1”.
  3. Open table “Attribute” and search for the VariableID number above.
  4. For version free variable, it shouldn’t exist, it got deleted in my case. Maybe an old bug in an earlier version didn’t delete it.

I looked through a bunch of other tables and I couldn’t find any reference between data card variables and attribute mapping other than the “Attribute” table above. Since your VAR already had you edit the variable, toggle off version free and remove the attributes, its likely fixed now. Or do you still have the issue showing up?

13

Since I am waiting for a comment from my VAR I think I could solve it by deleting the linked property and reenabling the version free flag in the UI.

I looked at the variable value that came back from the properties, but I was not able to find it anywhere I looked at. Probably the attribute table has some hints for us, will look at it next week. variablevalues do not have any link between the document id and the file property value. nothing apparently, but since that value came out again it must come feom somewhere buried in the DB and not reset.

If it is an old bug it is with us since 2019 at least as some sample data point in that direction.

Thank you for your contribution I will look again in the db.

14

bnemec

I looked at the attribute table and Tor Iveroth from pdm dev team pointed me to QA00000111142 query


it returns this so indeed there is a link between the version free variable and the file custom property.

Variable Name Type Unique Mandatory Block Attribute Extensions
item number Text CustomProperty item numbe sldasm, sldprt

“item number” is the version free variable, while “item numbe” is the mapped property inside sw files.
the two are apparently still linked into the DB after 5 years.

Our problem is probably a bug that was present in SW2019 SP3 administration or something strange happened down the road at some point, but nothing recent from what I can see digging the data.