ds-blue-logo
Preview  |  SOLIDWORKS USER FORUM
Use your SOLIDWORKS ID or 3DEXPERIENCE ID to log in.
DWDevin Wyatt08/04/2016

Hi,

As you all know, Workgroup PDM is being phased out over the next two releases. I've decided to get a jump on this and switch over now rather than waiting until this time 2 years from now. But I have some questions about general best practices for setting up a PDM system. Is there any such document laying out best practices for those of us starting with a blank slate? Some specific questions below that I'm trying to find answers to.

1. How should I structure my vaults? Should I just have one vault with a series of folders within for each project/product? Currently in our Workgroup PDM system we have projects for each different product, then sub-projects for versions of that project. Should I take a similar strategy here with folders? I'm assuming I shouldn't create a new vault for each product/project. What about things like the Toolbox and my Design Libraries? Should they be in their own vault? Or just their own folders in my main vault? We are a very small company, I am currently the only Solidworks user. At most we may have 3 of us that access the PDM system some day.

2. Even higher level than that, when I setup my archive server, should I set my root folder to a folder on my server's OS drive? Or a storage drive? Does it matter? I know Workgroup PDM always seemed to insist on having it in C:\VaultData. Should I follow a similar strategy here? Obviously I'll be setting up backups and all that as well. Is there any benefit to having multiple root folders? Should I put each vault in a different root folder? I see lots of instructions on how to do things, but next to none on why I would do things one way or another.

3. Currently I have a shared Toolbox (hosted on our server) and a shared Design Library (also on the server). These are not in our current workgroup PDM system. But I would like to move them into the new system. Will this require I open all of our assemblies to update the references to their new locations? Or can I automate this in some way? Again, we are a small company so manually opening everything wouldn't be the end of the world. It would be a bit of a pain but totally doable. I'm thinking maybe get the Toolbox/Design Libraries into the new system, then migrate each product one at a time manually and update references as we go. I also just updated to 2016 SW so I could use this opportunity to upgrade files to 2016 as well.

4. The big thing I'm struggling with right now is how to import a file with a particular revision and have it set the revision in PDM Standard correctly. For example I have a file with revision B-03. This was set by Workgroup PDM and is stored in a custom property. When I check this item into the new system, it gets 'no revision'. Then I move it through the workflow and it goes to A-01. How can I override this automatically so that it goes straight to B-03 on my first import? Since this is PDM Standard I can't have multiple workflows so I think I need to add a section to the default one for importing existing stuff. This would somehow sync the revisions rather than assigning a new one ... my VAR pointed me to here: 2016 SOLIDWORKS PDM Help - Synchronizing a Revision Variable to a Revision Number but from what I can tell that doesn't help me. All it does is synchronize the variable (custom property) with the revision number. I want to do the reverse of this ...

5. What are people planning on doing with their legacy data? I will only be migrating the latest versions across to the new system since I've been told it is a ton of work to do more than that. So how will people access their legacy stuff after 2018? Will I have to keep a copy of SW2018 installed forever so that I can access my old vault? Any suggestions for the best way to handle this? Should I setup a virtual machine with my SW vault in it? At least that way it's contained and easy enough to fire up whenever I need it.

Sorry for the long post. Just trying to get my head wrapped around all this before we get too far into it.

Cheers,

Devin