PDMWorks useful for single user?

Is there any benefit for a single user on a single PC to use PDMworks?

Thanks

Mitch

 

I am currently using PDMWorks, and am the sole user. The largest
benefit that I can see is its use for revision control. Even with
relatively small assemblies ( ie 20-40 parts ), prior to its use, it was
pretty easy to miss changes to parts within an assembly. Now I can also
match revision levels of support files to parent ones ( like pdf,dxf, tiff,
ect ) without having to remake them every time to ensure their accuracy.
However, anything that PDMWorks can do for a single user, could also be
accomplished through very good file management discipline (something I
lack).

 

Yes, if prototyping, very useful.
Saves lots of head aches.

 

How does it save headaches?

 

If Solidworks or your pc crashes, you often loose any changes that you have
made, sometimes the whole document!
If you use Pdmworks and regularly check-in your documents, your changes will
be safe.
Revision control is easier with a PDM system, you can check-in at the same
revision, or have successive revision.
You can do life cycles, such as prototype, first release, current etc..
You can copy a whole project and save it as a new project, with different
document names and references, no more configurations, a whole new project,
without having to redraw the same things over again, great for a design
range.
You can use Pdmworks for all of your documents including Word, Pdf, bmp and
lots more.
You can do reports and save these into excel for costing etc..
You can add comments at check-in time too.
There are so many advantages, the list is endless.

You can get a 30 trial, give it a go, it seems daunting at first, but it
gets you working in a constant style.
Look at Matts Website, he has written some great ideas, do's and don'ts.

 

Absolutely, In fact that is one of it's best uses assuming you are a
designer and you create a lot of variations on a theme. I can't tell
you how much time PDMWorks will save when you are in a what if scenario
and have to keep files straight, separate and easy to find old
versions.

 

You may want to also look at DBWorks, it uses a database and PDMWorks does
not.. It can be use straight out of the box and has more functionality and
is more user friendly.

 

And PDMWorks will utilize a Samba server which is difficult with
PDMWorks.

 

Well, hopefully you'll be lucky enough to pick a PDM that doesn't
*cause* crashes. I've been there, and it's not fun.

The only time a SW crash is going to affect data inside a PDM package is
if you crash while writing data to the vault. If SW crashes when
working on data locally, the worst that happens is that the data is
corrupted or left in an unusable state and you have to get another copy
of the latest vaulted version. Generally, the vault is not on the same
computer as the user, and the vault computer itself should not be
crashing at all.

I've seen problems with SW crashing while either sending or receiving
large assemblies to/from the vault, but I'm pretty sure those were just
crashes due to maxing out the computer's memory.

If something crashes when writing data, you probably should go through
and check the data that was writing at the time and make sure it made it
into the vault and works properly when taken back out again. If you
have to clean things up, each system has their own way of handling that.
PDMW will allow you to rollback to a previous revision if the one after
it gets corrupted or will allow you to overwrite the latest rev with a
clean file. I've never seen a client crash bugger the vault. If things
do get out of whack, you can always stop and restart the vault, which
will cause it to rebuild and verify all its information. PDMW keeps a
log too, which you could look at and see the last thing to write and
whether it completed successfully or not.

If your server has a catastrophic drive crash, you should be able to
recreate the vault in another location very quickly. Working from
incremental backups is not recommended, you shouldn't just restore a
section of the vault (unless you really know what you're doing).

The really nice thing about PDMW that it's detractors like to scoff at
is that PDMW doesn't use a real database. PDMWorks is meant to be
installed, implemented, maintained and used by engineers and designers.
You don't need someone who knows Oracle or Sql. There is no additional
cost for the database licenses, and in fact, many places do it with no
intervention from IT at all.

The nice thing about having a database like DBW is the additional
function, but the trade off is the additional maintenance task and
expense. If you want something simple that works today and you can
maintain yourself, get PDMW. If you have more infrastructure or can
deal with the database considerations, then there are a lot of other
things you can look at DBW being just one of them.

 

matt wrote:
....snip

Fact is that PDMWorks is a database, just not a SQL compliant database.
It just depends on how you define the word database. If you define
database as a repository of information which allows the information to
be organized, stored, deleted, operated on and retrieved on a computer
then PDMWorks and even SW can be considered databases. The people that
say that PDMWorks is not a database merely mean that it is not a
database in the sense that it doesn't perform its function using
(apparently) common standards like SQL. AFAIK PDMWorks basically
creates its own database in memory from data stored in directories know
as a vault. Because it is not a SQL compliant database any new
functionality or variations of capability require writing new code for
those capabilities. The PDMWorks database is limitied to doing just
what it does and nothing more which makes changes in its configuration
or capabilities more difficult, but also takes that responsibility
completely away from the user which makes it easier to maintain.

This is kind of the same argument that goes on between Windows and
Linux. Supporters of Windows say it is easy to use because the choices
you have are limited, (to ordinary non-programmers anyway) while
detractors of Linux say it is hard to use because it requires a lot of
setup savvy (which is not really true anymore either). The real
difference is that Windows is largely undocumented, proprietary and is
meant to run, as is, out of the box with limited configurability, while
Linux is designed so it can be reconfigured in an almost infinite
number of ways to suit it's use and provides an easy to understand
method of doing so being based on more or less open standards. Another
Windows factor is that the user is at the mercy of the MSoft as to what
capabilities and methods will be in the OS over time, while with Linux
being based on open standards will be much more stable over time froma
configuration standpoint.

With that analogy, if PDMWorks does everything you need to do in the
realm of PDM it is probably a very good choice. If it does not do
everything you need, then DBWorks or one of the other configurable SQL
based PDM systems may be a better choice. Also, if you cannot take the
risk of features being changed outside of your control the SQL based
PDM systems may be more suitable.

But again, for a single user, these issues will probably have less
impact than ease of use. If you start with PDMWorks it is probably not
a big deal to change over at a later date.

 

Yes DBWorks does run on a database, which gives you more functionality, but
with just one seat you can easily use the free database that comes with
windows. DBWorks does not in anyway cause a crash if anything I have seen it
help stabilize SolidWorks.. Because of the 100% integration and the fact
that DBWorks does not mangle the file names if SolidWorks crashes any
information in DBWorks is safe... The best thing to do is get an evaluation
of both PDM software and try them out and see which one YOU like best! Go
to their web pages and download an evaluation, if either one will not let
you test if for free first, then why would you want it?

 

PDMWorks creates a directory structure for each document. As I recall,
the folder name would be the document name, i.e., Part1_SLDPRT and the
subfolders within would be named by the revision for the part, i.e.,
1,2,3, etc. The actual document filename is the filename without
extension IIRC. At any rate, the important thing to know is that any
document within a revision folder can be made readable to SW by copying
out of the vault, renaming to it's original name and opened in SW,
excel, or whatever. To summarize, PDMWorks creates a little file tree
for each document. It is pretty easy to understand.

In addition to the folder system, PDMWorks also drops various text
files in each folder that contain certain bits of information about the
document and it's revision level.

However, these document file trees can be organized any way you want on
a macro level. Usually this would be by project or part number
hierarchy and normally would be little different from the way pre-PDM
users typically organize files.

When the server starts it creates a database in memory from a traversal
of this folder structure. That is one reason why a PDMWorks vault
should be protected so that only the server can read, write or change
the folder tree. If the in memory database and the information in the
folder tree get out of sync there can be disaster.

Programs like ecoSqueeze will unfrag the files in the vault when the
server is shut down because it can detect that the files are structured
storage files. So PDMWorks does not mangle the files themselves, just
the filename.

There are third party programs that will be able to traverse the vault
and convert to a new release of SW. Why SW doesn't have this
capability itself I have no idea.

DBWorks on the other hand makes use of file permissions and compression
and renaming to keep various revisions of file separate. It tracks all
this in a SQL database. So you could put all the files in one big
folder if you wanted to and they could still be kept separate by the
DBWorks program.

If you are using PDM I am not sure you would want non-PDM access to the
files unless you want to create a big mess. Both DBWorks and PDMWorks
should be set up so that the only way to access files is through the
PDM system.

 

Personally, I think it's a very bad idea to allow people to have direct
access to files inside the "vault". You lose all traceability and control.

PDMW does have a function that allows you to do this, even though I never
recommend it to anyone. There is an option to keep an unrenamed file in a
separate location, ostensibly for backup, but I know that people use it as
you say, to get around the interface.

SmarTeam also renames the files by adding the item number or something to
it. I forget what ProductCenter does.

 

DBWorks will run on any of these Access, MSDE, SQL, and/or Oracle, were MSDE
is free. You can buy 1 floating license.

 

You can still do that if you want, but I never recommend it. It's risky
accessing what is otherwise a controlled document. Regardless of what PDM
product you use.

Most PDM products have some sort of a view only module where you don't have
to buy the whole enchillada, just a relatively inexpensive viewer which
allows you to control access. I know SmarTeam's is about $5k ("cheap" in
SmarTeam terms), PDMW has the Web Portal or a Standalone Client. I'll let
the shills for other products tell you what they have.