The risks of importing a datacard as .crd file

I was bitten badly, so be aware that importing datacards as a crd file like I did the other day (to transfer them from my test environment into the production one) triggers, as stated in the manual:

You can export a data card to re-use it in another vault or create a backup copy. All controls, variables, images, and central lists are included in the export file.

Exporting a Data Card - 2025 - SOLIDWORKS PDM Help

What the manual fails to explain is that when the datacard is imported and ALL YOUR VAULT VARIABLES ARE MERGED and by merged (the “merge” dialog was barely visible and disappeared quickly so I had to look at it on my test server again to confirm) it means that all your vault variables are overwritten without knowing what is changed before starting the process.

I eradicated this bug that was very insidious and this morning it popped out again and it was PANIC TIME as the exported data to our PLM were corrupted again with a variable changing value or deleting itself on a simple check in.

At the end of the day I discovered that the impossible variable setting we had in our vault (version free + linked to user properties at the same time) was back…
I started looking everywhere and I noticed that the variable history (inside my lovely bug ridden PDM administration tool) had all our vault variables “added” again a couple of days ago. The time was roughly the same imported the crd file from our test server and I confirmed the behavior reinstalling our test server from an older backup.

crd file just overwrote all, no warnings, just a light flash dialog with “merging variables” (I do not know how it is called in english since we use the broken Japanese translation)

I had the crd card backup around since LAST YEAR, and only recently I had time to resurrect the plan to remake our cards with something more usable and with some smart “uber admin cheat mode” flags. Problem was that the card backup was carrying a bugged variable setting inside and this setting overwrote the correct one in our test server.
Since the bug it triggers is quite insidious and completely hidden unless you use a certain workflow it got unnoticed. I exported the card again to move it on our production server and…surprise it bombed the fixed variable again.

crd backup → import into test server → edit & test → export crd → import into production

Thank you again DS, for the nice ride, it was a lot of fun. Not for the faint of heart when you risk ordering an expensive equipment instead of a piece of aluminum because your codes are messed up randomly.

If you like extreme sports I can suggest you: RAFTING, PARAGLIDING, DOWNHILL and SOLIDWORKS PDM

Edit:

I forgot to quote the card import manual.

Importing a Data Card

You can import an exported data card. You can also import one of the default cards installed with SOLIDWORKS PDM Professional to restore default values.

To import a data card:

  1. Click File > Import.
  2. In the Open dialog box, use the Look in list to navigate to the location of the card to import.

Cards imported as part of the installation are listed in the Default Cards directory, usually located at c:\Program Files\SOLIDWORKS PDM\Default Card.

  1. Click Open.

If the variable mappings in the imported card already exist in the vault, the imported card mappings are merged with the existing mappings.

  1. Select the each card control and click Variables in the properties pane to check for duplicate Block / Attribute mappings.

Also, for CustomProperties blocks in SOLIDWORKS data cards, make sure that the same variable does not map to multiple custom properties.

  1. To save the imported data card, click Save (Card Editor toolbar) or File > Save .
  2. In the Save Card dialog box, navigate to the location for the card, type the card name, and click Save.

Importing a Data Card - 2023 - SOLIDWORKS PDM Help

If the variable mappings in the imported card already exist in the vault, the imported card mappings are merged with the existing mappings. … but also overwriting the existing one without any kind of warning, summary before launching the import process or (god forbid) a log of what was done after the operation.

Yeah, all dependecies are included whether they changed or not. This does make it challenging if you are doing multiple separate changes. I have to track/document everyting I’m changing in the DEV system so when I transfer I know whats updating. This of course affects how and when you move changes over.

Also, export your entire vault prior to any import so you can restore if needed.

1 Like

A very good advice.
I was mislead as one field on the imported card did not link back and I had to fix it manually.

It was a drop down list and its table from the variables was not linked back so the whole merge thing is not so solid imho…

There are gaps in the export function and merging changes. Just don’t see them doing much about it unfortunately, they want you on 3dx.

1 Like