PDMworks and DBworks??

Hi,
I've spent a lot of time reading about the two packages and I am leaning
towards DBworks.
The only concerns I have at the moment, is that PDMworks is to be an
integrated part of Solidworks 2004 and not as a separate add-in. As DBworks
is an add-in but also a gold partner Of Solidworks, do you see any future
problems? I've seen that many people have said that DBWorks is around $200
cheaper than PDMworks, does anyone know what the price is?

Also, is there anyone using DBworks that could give me some feedback,
positive and negative?

Many thanks
Pete

 

dbworks works fine, but user interface is totally and absolutely
crappy. people at mechworks are completely unable to produce any sort
of pleasant user interface and they don't mind in any way emails
received by users. never seen such a stupid interface since word for
dos 4.0...
you can't move across windows with <tab> key --not even when inserting
text in text boxes...--, you never get any reasonable responce when
pushing arrow keys and the main window uses the most stupid array of
controls they could choose to show you your documents. the nice thing
is that with every new release they change key assignments randomly.
in an unpredictable way, when creating a new project the subwindows of
the main window moves around and their sizes get messed.
when exporting a project or subproject tree to an html file you have a
relatively small tree-size limit, and this becomes quickly a problem.
the other thing is it uses some levels of nested tables and there are
many html tags errors in the output file.
removing parts from subprojects not always works as expected and often
you say bad words because of the dumb management of the main window
views of projects. they didn't thing about the possibility of showing
subtrees *while* building them. then, when you need/want to see a big
projects/subprojects tree you may have to wait some *minutes*.
probably in 2.675e+17 releases they'll fix all these things.

but user interface apart, it's a good package. powerful and working
fine.

my 2 eurocents.

 

Pete,

I've been playing with DBWorks 2004 Beta 3 for the last week or so.
Coming from a PDM\Works background (4 Years -- 30 seat install) I am
biased towards PDM/Works' simpler interface. The latest version of
PDM/Works (2004) has some very nice refinements.

However, I cannot see any new functionality being added to PDM|Works
without it encroaching on Smarteam's (Another Dassault
Product)customer base. Given the price difference between the two, my
guess is the margins are a lot better with Smarteam when you consider
the installation & configuration costs.

This can be seen with PDM\Works current pricing scheme which requires
users to coughing up another $5K for the Advanced Server. This module
basically allows access to the PDM/Works API calls.

The only rational for this type of marketing position (in my
opinion)is to allow SW salesman to up sell PDM\Works power users to
Smarteam.

i.e. "Given the cost of PDM\Works Advanced Server.... and the
customization required to make it work..... you might as well pay a
little extra to get the "out of the box" functionality of
Smarteam........"

For single users DBWorks is half the price of PDM/Works and 20x more
powerful. Granted the installation is more complicated (buy the
adminstration manual -- it is worth its weight in Gold) and the user
must know how SW works inside and out (hope you didn't fall asleep in
the SW class when they were going over the SW options).

Granted it has some quirks (like any other software) but I am really
beginning to like it.

My top ten reasons why I like DBWorks.

1. Simple to use.
2. Easy to maintain.
3. Automates drawing creation (filling in Title Blocks, Auto-numbering
files).
4. Revision control of configurations and derived parts.
5. Generation of Project BOM's and purchasing lists.
6. Different materials in a single part file (i.e. SST, Al, CS parts
with identical geometry).
7. Replaces all the third party macros/add-ins for entering
custom/configuration properties.
8. Allows the use of external database fields to populate dropdown
list boxes (i.e. use the MRP/ERP database to populate fields such as
suppliers, order quantity, etc..)
9. Addition of phantom parts in a BOM without having to fake it by
dropping an empty part.
10. Forcing mandatory fields to be filled in during saves or approval
process.
(i.e. lets engineers be loose with data during developement but then
making sure it is added prior to being released.

The list is growing daily.

In conclusion:

There are three types of PDM/PLM systems: Workgroup, Department, &
Company.
As you move from Workgroup to Company the functionality increases at
the same rate as the complexity of installing and running the system.

DBWorks is close to the functionality of a Company PDM\PLM with the
complexity between a traditional Workgroup and Department PDM system.

It offers very good value for the money if you use it "out of the
box".

Cheers,

Len K. Mar, P.Eng.
President
E-data Solutions

 

Hi Gianni,

In DBWorks 2004 the interface has been the first reason of concern and
it has been rearranged and improved:

1) DBWorks runs inside SW as a model window
2) The project tree page has been redesigned to offer all the features
previously offered by the lists window in a tidy, simple interface
3) Search interface has been simplified and made more appealing,
letting you recall all recent complex searches with a click
4) Workflow decisions have been simplified with a new interface

There's certainly more than this, but an entire list here wouldn't
make sense.
You can have a preview at the address:
http://62.101.95.130/mechworks/dbworks2004/html/intro.htm

You can see screenshot of the interface there, new elements are
described in detail. I won't discuss the 'crappiness' of the
interface, go there, look and make your opinion on the subject. If you
have any advice, send us an e-mail at

This brings me to another subject: you wrote "they don't mind in any
way emails
received by users". We have a good record of minding the users
opinions and are proud of it, so the first thing I did was looking for
e-mails from you through the years. No advice, no complaints, no
requests, nothing. If you want us to 'mind your e-mails' please help
us by sending an e-mail.

We receive e-mails of requests/advice from all over the world. Funny
we don't get feedback from a guy who lives at less than an hour drive
from our office.

Going back to complaints, after your message we will retest the use of
keys and of tab keys in particular.

Tree rebuilding has been made quicker, but the best approach is always
not to expand many projects at once (there's an option to make this
task automatic). In any case we're talking of very few seconds for 100
projects, nothing like minutes. Performance is a high reason of
concern for us and DBWorks is running in companies who manage very
large assemblies and large projects (SIG packaging, Bosch packaging,
to name two). If what you wrote was true, the would have discarded
DBWorks from day 1. I wonder how many projects you have, we can webex
you any time to check the performances on your system, just get in
touch.

About html output, there's an applet for parents and children and that
applet has a limit of 1000 elements because of limited space (ever
heard of an applet as big as more then 10 times the screen height?),
but there's no limit to the number of elements in the trees. The html
for the table trees is a bit complex because of dynamic behaviours
that mimic a tree (expand, collapse branches). If there's any tag not
closed, please let us know which. Our first reason of concern was to
make sure it works correctly and it's been doing it for years.
If you can't get an html for an assembly, send us a zipped copy of
your database and the ID of the assembly and we'll test in-depth until
we get it to work as expected.

By the way, thank you for the final line.

Giorgio Malagutti
MechWorks

 

hi giorgio. your name sounds italian
one of my employees in the technical office is named alessandro
malaguti

i'm glad to hear it. as i said in my past post, the user interface
wasn't what we'd like to have and it was a pity because of the good
engine of the program.

nice thing.

looking forward to see --and try-- it.

good choice.

i had a look at some of the screenshots and the new user interface is
far better than the actual one. it seems clear and well designed: i'll
let you know the real usability, but the look is appealing.

this may be due to our var, but everytime we asked why the u.i. was
designed in a certaing way or if there was the possibility to change
something we got the usual answer "it's impossibile" "the company
can't change nothing" "we received no answer" "blahblahblah".

from my --the final user-- point of view, this has been a problem in
many situations...

the most strange thing that happened --twice-- was that, without any
reason, dbworks window moved outside the screen. it got focus, it
received keyboard events but it didn't show in the screen.
we solved deleting dbworks user settings.

i don't know how the new interface will work, talking about keyboard
response, but since windows 2.0 for dos 3.30 the tab key has been used
to move thru the fields of dialog boxes, the arrow keys has been used
to scrool in combo boxes, drop-down list, list boxes and grids and
usually users has been able to press alt+<letter> keys to jump to the
most commonly used fields of the windows. nothing of this was found in
the u.i. up to dbworks 2003.
i understand that having user interface localized to many languages
can give some problems when assigning alt+<letter>, but done once,
done forever. at least, tab and arrow keys should work as expected,
that is just like any other windows software.

i'm not saying this is the best way to use keys, but this is the most
common one and a user will expect all the softwares to work the same
way and, possibly, to have similar interfaces.

i understand this, but since "add project to selection" doesn't always
work as expected --that is, it should just add the project i choose to
the previous selection--, you quite often need to rebuild the whole
projects tree and then choose the project you want to work with.

or, since project management has changed heavily at least 2 times in 4
years, you may have decided to organize your projects in a certain way
and you may need to change it because of the new features of today's
software. then, the projects you start now will have names you decide
today, but older ones can still have names with the older conventions
and, while you don't reorganize them and rename most of them, looking
for them in a 6 lines drop down list isn't that comfortable. then a
complete project list comes useful.

another possibility is when you get a new employee, who doesn't know
how you organized your projects: he/she will often need to navigate
the complete project list to find what he/she looks for.

actually, a very annoying thing is the filter window behaviour. we
usually choose the "filter all the tables" and "filter all database"
options because of our parts and assemblies codes.
should, for any reason, you filter tables when the selection focus is
on the projects list, you loose the complete project list, meaning
that you don't see any projects anymore. i mean any of the selected
nor the unselected ones. pressing the "home" button doesn't help,
because it rebuilds all the windows but the projects one.
then, the only way --and it doesn't even always work...-- is to
uncheck che "show only selected projects" option and select again a
list of projects to work with.

maybe there is some way to fix this --wrong, imnsho-- behaviour, but
my var hasn't been able to tell me how.

100 projects were born in three days when we bought the first 3 seats
in 1998. in a company with 5 seats you can quickly reach thousands of
projects. i can't even imagine in big companies the huge projects tree
they can have.

but the disappointing thing is, probably, not the fact that rebuilding
a 3.000 projects tree takes too long --talking as a programmer, you
probably didn't choose the best way to display the project tree--, but
the fact that while building you can do nothing else.

if my complete rebuild takes 3 minutes --and this is very next to what
happens-- and i do it three times a day --for any reason i may want to
do this--, i loose one hour a week, that is 60 dollars. i have only
four seats, then i'm probably loosing 150 dollars per week on tree
rebuildings.
if i could spend those minutes working on some opened models with swx
it would be far better. this is also because *i know* nobody works
hard 8 hours a day, but people want to choose on their own when to
take a break and *having to* do it when *dbworks* decides disappoints
people working in my technical office.

sure i will, because i hope my problems are my fault: if i'm right,
just changing the way we work can improve our performances.
but, as i told you, our var --and we're talking about the one that is
known to be the best in our area-- hasn't been able to tell us how.

i don't think i need to mention that dbworks and solidworks files are
located on a file sharing server dedicated to the technical office and
not on the workstations swx is running on.

no, i haven't. and it wouldn't be a good choice.
a good choice would probably be keeping in memory the whole tree and
having an applet as big as the window showing you only the part
filling in the available space. this is often done when having big
trees because of the refresh/repaint speed of controls having too many
lines.

actually, i don't know where the problem can be, then.
i'll try to understand it.

now, somebody could call me crazy because i'd like to have a complete
project tree exported to html --and then printed--, but since the
biggest monitor you can buy is enough just to show one 50th of the
projects we have, being able to rearrange the tree on paper before
moving the things on the computer would be pleasant.

sure. but i guess the problem is at an earlier step: if you export a
3-level project tree, you find the same error on all the 3 levels. if
you export a 5-level project tree, the same html error is found on all
the 5 levels of the tree and repeated on all the branches of the tree.

probably the engineer that developed the procedure writing the html
code made a mistake in a recursive subprocedure.
but, as i said earlier, the tree is rendered correctly by internet
exploder, so it's ok for me. problems came when showing it with older
mozilla for linux versions, but today we're no more interested in
this.

i'll print a rather complex tree project and will mail you what i
found not to be perfectly ok.

and it still does. simply, when looking the sources, there are
--were?-- some minor errors.

you're welcome. in 2 words, what really matters in a software is that
it works fine and does what it's supposed to do.
the second thing is the user interface, but it's secondary to the
correct working of the software. of course, as soon as a software
works fine, the first thing you ask for is a good user interface.

cheers.