PDM, From which config does the SW PDM add-in display the variable values?

[bnemec]

We have an interesting case where the PDM add-in is showing values for variables that cannot be found on data card. After a bit of investigation I'm fairly certain the add-in is getting info from an old config (sheet) that has been deleted. Then the @ and main sheet variables were updated. Everything (data card, where used and contains data grids, etc) but the pdm add-in shows correct data, the addin was pulling variable values from the config for the sheet that has been deleted.

The variableValue table made this clear. I recreated the sheet with same name per the database tables and was able to update that variable value so the add-in shows correct info, but it made me realize that I don't know which config/sheet the add-in pulls variable values from.

Thanks.

[jcapriotti]

I think its randumb. Seems it runs a query and whichever is "Top 1" wins. So deleted configs/sheets get included which stinks.

[mp3-250]

it depends. the add in coud be configured (tool - pdm - options iirc) to pull the data from SQL otherwise it is going to read from each file its data card related ptoperties.
this is apparently for data shown inside the SW add in in the task pane

In the PDM explorer cluent and for db-only variables we have a similar experience with a variable that was set history free at some point. one problem is that setting is working only sInce the next check in so the affected data retain past configuration values. then it cannot be linked to custom properties anymore so you need to delete leftovers inside the files or better use a newly made variable instead.
Another bug is the column settings that show a past value (probably from a @ configuration) if the current value in the datacard is empty (setting it to a single space character prevents it)

[JSculley]

This may be be relevant:

https://support.3ds.com/knowledge-base/ ... 0000109905
=================
QUESTION
Why do custom properties only ever populate a SOLIDWORKS® drawing's SOLIDWORKS PDM® data card '@' tab and not the drawing sheet tabs even when 'update all configurations' is used?

ANSWER
The 'Update all configurations' flag in a data card only controls how values entered in the data card should be handled when multiple configuration or sheet tabs are displayed for a file. If the flag is enabled, the same variable value is updated in all configuration or sheet tabs on the card.

However if you update the custom property value outside of the data card, the variable value in the card will only be updated in the configuration tab that matches the updated configuration. Drawing sheets do not have sheet-specific custom properties, unlike a part or assembly. Custom properties for a drawing always end up in '@' tab of the data card.

There are some sheet specific details (but not custom properties) that can be extracted as follows:
Block:
swsheetproperty
Attributes:
Name, Scale, PaperSize, Template, Width, Height, ProjectionType

To get values synchronized between a drawing's @ tab and it's sheet tabs the API could be used - see KB solution S-047019 for an example. Alternatively you can use Dispatch to copy values between the configurations tabs. The attached Dispatch example 'update variable_Number_on sheets tab.acn' shows how to copy values from the drawing '@' tab to all sheets.

[bnemec]

This may be be relevant:

https://support.3ds.com/knowledge-base/ ... 0000109905
=================
QUESTION
Why do custom properties only ever populate a SOLIDWORKS® drawing's SOLIDWORKS PDM® data card '@' tab and not the drawing sheet tabs even when 'update all configurations' is used?

ANSWER
The 'Update all configurations' flag in a data card only controls how values entered in the data card should be handled when multiple configuration or sheet tabs are displayed for a file. If the flag is enabled, the same variable value is updated in all configuration or sheet tabs on the card.

However if you update the custom property value outside of the data card, the variable value in the card will only be updated in the configuration tab that matches the updated configuration. Drawing sheets do not have sheet-specific custom properties, unlike a part or assembly. Custom properties for a drawing always end up in '@' tab of the data card.

There are some sheet specific details (but not custom properties) that can be extracted as follows:
Block:
swsheetproperty
Attributes:
Name, Scale, PaperSize, Template, Width, Height, ProjectionType

To get values synchronized between a drawing's @ tab and it's sheet tabs the API could be used - see KB solution S-047019 for an example. Alternatively you can use Dispatch to copy values between the configurations tabs. The attached Dispatch example 'update variable_Number_on sheets tab.acn' shows how to copy values from the drawing '@' tab to all sheets.

Agreed, may be involved. We had run into this in the past when users thought they could "fix" things by editing custom file properties. I did finally manage to put that to bed with some pointed one on one conversations of why their drawing pdfs were wrong at release and stopped making the fix path comfortable. So when I first saw this I assumed it was an @ vs sheet issue again. However, when that is the case the various places agreed on the wrong data. For example, if I selected different "configs" in the contains tab for the drawing it would confirm what I saw in other places. In this case the pdm add-in was all by itself. I could not replicate what it was showing for part number >any< where else. So I looked in the VariableValues table for that document and realized the pdm add-in was displaying the variable value from a sheet that has not been on the drawing since version 1 and the file is at v12. To test this I added the sheet back in with exact name then checked the file out. That allowed me to update the variable value for that config. I don't think that's the root cause though. I >think< the root cause is the add-in is just pulling from the wrong config, but I'm not sure.

Here's a shot I took for my own record/note of the variableValues table filtered on that docID and the variableID.

[jcapriotti]

So I looked in the VariableValues table for that document and realized the pdm add-in was displaying the variable value from a sheet that has not been on the drawing since version 1 and the file is at v12. To test this I added the sheet back in with exact name then checked the file out. That allowed me to update the variable value for that config. I don't think that's the root cause though. I >think< the root cause is the add-in is just pulling from the wrong config, but I'm not sure.

I can get the same thing for a part model with a deleted configuration. A search on the "Number" field was pulling version 3 of 6 "VariableValue" data in the search. I'm guessing version 4 was when it was deleted. There are a couple of SPRs where they fixed similar cases but this one still persists in 2023 sp5.

[bnemec]

I can get the same thing for a part model with a deleted configuration. A search on the "Number" field was pulling version 3 of 6 "VariableValue" data in the search. I'm guessing version 4 was when it was deleted. There are a couple of SPRs where they fixed similar cases but this one still persists in 2023 sp5.

I'm assuming that search was with "Search in all versions" >not< checked? Otherwise that would be expected behavior.

The search, that from vault view or search tool? So it's not unique to the pdm add-in?

[jcapriotti]

I'm assuming that search was with "Search in all versions" >not< checked? Otherwise that would be expected behavior.

The search, that from vault view or search tool? So it's not unique to the pdm add-in?

"Search in all versions" is checked. I'm searching in the "Drawing Number" which has the same value in all configurations across all versions (It never changes). Normally if no configurations have ever been deleted, it always pulls the latest versions of all other variables and the "Found in version" number column matches the latest version number. But in these cases where a config has been deleted, it sometimes pulls the deleted configuration values for all data in all columns.

I hate that it just randomly picks a configuration to pull the values from. Would be nice if there was an option to expand and show rows for each configuration.

[bnemec]

"Search in all versions" is checked. I'm searching in the "Drawing Number" which has the same value in all configurations across all versions (It never changes). Normally if no configurations have ever been deleted, it always pulls the latest versions of all other variables and the "Found in version" number column matches the latest version number. But in these cases where a config has been deleted, it sometimes pulls the deleted configuration values for all data in all columns.

I hate that it just randomly picks a configuration to pull the values from. Would be nice if there was an option to expand and show rows for each configuration.

Ah, wow! grabbed a deleted config. So it was reporting "Found In" at the latest version but showing value from a config that's been deleted. But it did get the value from the latest version (revision) in the variable value table for that config. So correct data, from the wrong config. Wouldn't unchecking "search all versions" clear that up in the search use case? Do you keep that checked most of the time? Changing it to default unchecked was one of the better improvements we made to our search card; curious the use case for having it checked.

I had to go to search tool to find where to search by config/sheet name then I remembered, there is no (decent, let alone good) way to link config/sheet name to data card variable or custom file property.

[jcapriotti]

"Found in" says version 3 (of 6). That "number" variable has the same value in all configs set at version 2. The config in question was deleted along the way on version 4. So the search with "all versions checked" is finding that deleted configuration first, then pulling all the variables for version 3.

Thing is, if the config had never been deleted, it would pull version 6 for everything. This is determined by the "DocumentRevisionConfiguration" table which stores all ConfigIDs for each version of a document.

I think its the wonky way the search works. It can only display column data for one of the configurations, so it picks one based on some logic....maybe lowest ID as this one was the first created in this file.

[jcapriotti]

Changing it to default unchecked was one of the better improvements we made to our search card; curious the use case for having it checked.

It's conditional. For some variables like Drawing Number, it should be unchecked since the number doesn't change ever. For "ECO Number" it should be checked since each revision has a different ECO number. Unfortunately there isn't way to control the check / uncheck condition. Been trying to hide/unhide it with mixed results.

[bnemec]

It's conditional. For some variables like Drawing Number, it should be unchecked since the number doesn't change ever. For "ECO Number" it should be checked since each revision has a different ECO number. Unfortunately there isn't way to control the check / uncheck condition. Been trying to hide/unhide it with mixed results.

Do you mean dynamically (at search time) set or clear the check box automatically based on something else?

Also, why would it need to be checked when searching Drawing Number? The Drawing Number on latest version will be same as any other version. Won't the results be the same if the value never changes?

[jcapriotti]

Do you mean dynamically (at search time) set or clear the check box automatically based on something else?

Also, why would it need to be checked when searching Drawing Number? The Drawing Number on latest version will be same as any other version. Won't the results be the same if the value never changes?

Unchecked on Drawing number, but checked for ECO number. I did manage to get the hide logic to work when typing an ECO number....so the form defaults to showing the "Search all versions" checkbox but the default value is unchecked. Then hide when entering ECO number which searches all versions. Still pulls the old version for the ECO file list but that's better than when searching by drawing numbers.