Moving from PDMWorkgroup to DBWorks

[Overworked1]

In about a week the company I work for will be moving to DBWorks for our PDM system. We are currently on PDMWorkgroup. I will be an administrator of the new system along with 3-4 of my co-workers. Does anyone here have any information about making this switch that they would be willing to share?


Tips for making the transition, things to watch for, anything you think may be helpful would be much appreciated.



Aaron
SolidWorks (x64)/PDMWorks 10 4.0
CADKey 99 R1.0 (Yes, still using it!)

 

[ctopher]

I have not used DBWorks, but found this info.

https://forum.solidworks.com/thread/13077

Chris
SolidWorks 11
ctopher's home
SolidWorks Legion

 

[kellnerp]

dbWorks has a utility for converting the Workgroups vault. Ask them about it.

Did you bring this up when you took admin training?

Which modules did you buy?

Tips:

#1 Make sure you don't have duplicate filenames.
#2 Make sure you know what your company is really doing. What I mean is, make sure your company has a well documented procedure for handling it's documents.
#3 Allow ample time for dbWorks to register all your files.
#4 Since dbWorks will not be finding places to store your files in it's vault (because it doesn't have one) you will have to work out a file storage structure for your company. I would suggest something that ensures no more than 1,000 files in any folder.
#5 Take the time to setup the part number generator.

TOP
CSWP, BSSE

http://www.engtran.com

http://www.niswug.org

http://www.linkedin.com/in/engineeringtransport

Phenom IIx6 1100T = 8GB = FX1400 = XP64SP2 = SW2009SP3
"Node news is good news."

 

[Overworked1]

Chris,
Thanks for the response, I also found that post last week.

Kellnerp,
I have not been involved much yet with the entire process except
for initial discussions about which program to go with. Ultimately the decision was made by management and our I.T. department. We are having a VAR come next week to do the install and provide training. I did find out we purchased the express module to start with.

My understanding of DBWorks is it manages our cad files in a different way then PDMWorks does, but we (Engineers) will be able to access that data in a similiar fashion to how we do it now.

What I mean is we will still check-in/check-out files to a Vault that we will see with folders and a tree structure. Things we do now such as our file storage structure and the way we create part numbers should be able to be used as they were in PDMWorks shouldnt they?

Aaron
SolidWorks (x64)/PDMWorks 10 4.0
CADKey 99 R1.0 (Yes, still using it!)

 

[kellnerp]

I think your question will be answered in training.

One major difference is that where PDMWorks puts things in a vault with it's own file structure based on projects, dbWorks puts things in ordinary Windows folders and manages them by controlling permissions. However, the permission control comes with the Enterprise version, not Express.

It really is a good system and it can grow without having to throw out what you initially have setup.

Their tech support is pretty good, but their philosophy is to give the customer a much higher level of training than would be expected with a SW product. It is a much more open system that SW products. So pay attention real close in training.

Also,
#6 Go with their version of note handling in your drawings. It can really take a lot of work out of making drawings.
#7 Go with the database for storing what you used to store in custom properties. It works slick.

TOP
CSWP, BSSE

http://www.engtran.com

http://www.niswug.org

http://www.linkedin.com/in/engineeringtransport

Phenom IIx6 1100T = 8GB = FX1400 = XP64SP2 = SW2009SP3
"Node news is good news."

 

[SteveMartin]

I've never used PDMWorkgroup, but I currently use and sometimes administer DBWorks.

The program works well for a single location, but we have no end of problems with the database replication between sites. The site to site replication drops out with no notice or warning, and when we eventually realize it dropped (often months later) resyncing is a huge nightmare that often loses a lot of metadata.

Try not to have too many things stay in their 'checked in' state forever. We have a terrible habit of projects or portions thereof that get started and part or all never finishes, leaving tons of files checked in but not approved. You can have approved files spread over many directories, but checked in files are all in one place - ours currently has ~38,000 files, which makes troubleshooting anything that involves that directory a huge pain.

Definitely work with local copies of referenced documents. I still have co-workers who insist on not copying anything local and instead opening files direct off the network. It both slows them down and screws up other peoples' ability to do clean approvals - if somebody has a 'checked in' file open direct from the network and somebody else tries to approve it DBWorks won't be able to remove it from the checkin directory (though it will properly do the rest of the approval steps).

For everyday work I personally love using the DBWorks shortcut bar that pulls out/back on the right side of the SolidWorks window to access files instead of opening up the full-window DBWorks interface. Most people I work with hate it, and use the full window interface for everything.

 

[kellnerp]

Steve
See suggestion #4, don't let any folder fill to more than 1,000 files. It causes Windows to slow down.

I don't understand why you are moving files on approval. There is no need to do that from a PDM standpoint. Checked in or approved is all tracked in the database. If you leave them sit where they are when first created several of your issues go away.

I contacted support about the replication issue:

The database replication process is 100% handled by Microsoft SQL and it has very good tools for monitoring its status and reporting accordingly. If [you] are not validating that SQL is able to communicate between sites properly on a regular basis (every couple of days at the most) you should be. It probably takes 5 minutes to validate SQL’s replication status.

You might want them to have a look, it shouldn't be a big deal.

And 38,000 files that were never approved? Does that mean they were never manufactured?

The OP is going to be using Express, so some of these issues like remote syncing won't be an issue.

I never ran into an issue with network slowness or collaboration until IT decided to virus check SW files coming over the network. That stopped when they saw it wasn't necessary. The advantage of working over the network is that others can see the changes in higher level assemblies right away.

TOP
CSWP, BSSE

http://www.engtran.com

http://www.niswug.org

http://www.linkedin.com/in/engineeringtransport

Phenom IIx6 1100T = 8GB = FX1400 = XP64SP2 = SW2009SP3
"Node news is good news."

 

[SteveMartin]

kellnerp,

I can't say why ours is set up with a checkin directory that is separate from all of the approval directories. I was not involved in the initial setup, which happenned before I started here. As you say, some of our issues would go away if files didn't move around.

I'd LOVE to get all of our directories under 1000 files, but it's a battle I've already fought and lost. There's at least one directory where I don't think it's possible (local copies - which I don't know how to subdivide). Our checkin directory isn't getting that small either without serious rebuilding of how we've configured DBWorks, which won't be happenning in the near future.

Most of those 38,000 checked-in files were never manufactured and never will be. They're either concepts that went nowhere or imported reference parts. A small handful (probably under 100) are files that somebody is currently working on.

As for the replication validation, we've been in contact with our support rep on multiple occasions, mostly about this. I don't know the details because I'm not usually on those calls, but it has been a recurring problem for us. At one point it was due to using an outdated SQL, but I believe that was updated and I'm not sure what's caused our latest round of problems.

I'm sure most of our problems are could be solved by better setup of the program and better admin training. We lost our DBWorks administrator and IT manager last year, and to my knowledge neither has been replaced yet (five months and counting).

 

[kellnerp]

People arguably have a reason to be concerned when riding the L train after seeing the driver get off two stations back.

I'm sure most of our problems are could be solved by better setup of the program and better admin training. We lost our DBWorks administrator and IT manager last year, and to my knowledge neither has been replaced yet (five months and counting).

dbWorks has excellent training. But if the guys they trained move on, what can I say? Even PDMWorks needs a dedicated manager and something as complex as you have, it is a must.

Now the 38,000 file issue can be solved in a number of ways. If it is concepts stuff, create a concept project and a revision scheme for pre-release of development parts. Something like X0, X1, X2, etc. Release the parts to that project and make sure that manufacturing can't see those parts. Same thing with reference parts.

I did some reading in the help last night to refresh myself on Local Checkin Mode. It is meant to work the way it is for you, just having so many files in that one folder is a killer.

A trained dbWorks admin can probably clean up the 38,000 files in a day or two.

The other question is, if you are just checking them in and not releasing them, why control them with dbWorks? Somebody has to make some hard decisions.

Just my 2 cents.

TOP
CSWP, BSSE

http://www.engtran.com

http://www.niswug.org

http://www.linkedin.com/in/engineeringtransport

Phenom IIx6 1100T = 8GB = FX1400 = XP64SP2 = SW2009SP3
"Node news is good news."

 

[SteveMartin]

I agree with all of your points kellnerp. Some of the cleanup you've suggested has even been scheduled once or twice before, but always pushed off.

I would love to have the time, training, and authority to attack this stuff myself. Unfortunately it doesn't look like I'll get any of three of those any time soon. And while they inefficiencies in our current implementation are aggravating, they're definitely not the biggest headache of my daily work.

 

[kellnerp]

Be patient. The help is good. Self train, maybe you will get an opportunity.

Sounds like a political solution and not a technical solution is needed. That's something I can't help with

Who sets up the projects? Maybe you can get someone to setup a development project and just nibble away at releasing the 38,000. Why have PDM and not use it?

TOP
CSWP, BSSE

http://www.engtran.com

http://www.niswug.org

http://www.linkedin.com/in/engineeringtransport

Phenom IIx6 1100T = 8GB = FX1400 = XP64SP2 = SW2009SP3
"Node news is good news."

 

[SteveMartin]

Projects in the database are set up by engineers as needed. The windows file structure where the files actually reside is set up per company policy. And you're absolutely right - most of what's needed is a political solution, which I don't currently have the political capital to effect. I think there may be a few technical hurdles buried, but I won't find them until the political ones are cleared.

Also, I may not have made this clear in this post, but DBWorks is definitely a boon to our organization compared to pre-DBWorks. It's just not as good as it probably could be with better oversight.