PDMWorks useful for single user?

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

Thanks

Mitch

Reply to
mitch
Loading thread data ...

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).

Reply to
Brian

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

Reply to
pete

How does it save headaches?

Reply to
mitch

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.

Reply to
pete

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.

Reply to
TOP

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.

Reply to
adam

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

Reply to
TOP

What happens to the design, DBWorks or PDMWorks as a result of typical Solidworks crashes?

I've seen a couple of crash "types". The first involves a lot of disk activity and then the program shutting down. A few times this has triggered document recovery upon starting SW again. The other (very rare) crash type is one where the whole machine acts as though I had pressed the reset button. An instantaneus and decidedly brutal crash. I've seen it happen twice in six months and, in both instances, it happend while closing SW.

I don't have PDM/DBW now but I am considering moving in that direction. What would be the consequences of the unavoidable SW crash on both these systems and, what's more important, the designs they manage?

Thanks,

-Martin

Reply to
Martin

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.

"Martin" wrote in news:0xehe.2892$3% snipped-for-privacy@newssvr13.news.prodigy.com:

Reply to
matt

matt wrote: ...snip

designers.

additional

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.

Reply to
TOP

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?

Reply to
Wilma

I may be mistaking, but doesn't PDMWorks modify the file structure (file names and directories) to maintain it's control? Where as DBWorks uses an SQL database to maintain this control? If users without an licensed seat of what ever PDM system one uses, wouldn't the SQL be beneficial since the file structure remains unmodified?

Keith

Reply to
Keith Streich

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.

Reply to
TOP

"Keith Streich" wrote in news: snipped-for-privacy@corp.supernews.com:

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.

Reply to
matt

The only reason we would want access to certain files is for viewing and printing capabilities only. Our sales and service departments need to view past information for current and past jobs. Since there is no way my company would pop for 30+ seats of an PDM package (unless one can purchase floating seats), this would be very important to access shared information. I would assume engineering and given sales personal would have licensed seats to create and maintain data.

Am I all wet on this? When one starts talking about license per seat of the PDM, additional SQL seats, then training, this adds up fast.

Keith

Reply to
Keith Streich

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

Reply to
Wilma

"Keith Streich" wrote in news: snipped-for-privacy@corp.supernews.com:

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.

Reply to
matt

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.