Bill,
 
While I would agree with your statement as it is now, I would make one defense for the database design in that when it was originally planned in like 1991, it was fairly consistent with the state of things at that time.  Problem is that it never changed and grew with the rest of the industry.
 
Ezijobz is Mike's answer to that long, long, long long overdue change.

Quote from David Waldmann   on 04/14/03 at 14:38:28:

 
Just to clarify, I do plan to get my "free" copy of EJ-SME and check it out. It seems like it would be foolish not to.

It's overdue, thats true. However, the new program quite frankly looks like it will suck.
 
One of the main things I like about DBA is the availability of source code. Granted it's in an archaic programming language that no one I know programs in... but it's still available. I'm not sure why any of us would want to switch from a program w/ available source code that is working for us to a program w/ no source and that doesn't even import all of our data.
 
It doesn't take a rocket scientist to figure out how to do a near total data import when you are designing the new system and you have the source code to the old one. With all of the problems they've had getting Ezijobz out I'm starting to wonder if they hired highschool VB programmers to do this thing...
 
Quote from aricon   on 05/06/03 at 11:58:56:

kkmfg,
 
The difference with Ezijobz and DBA is that because you are given an open SQL editor, it is FAR less necessary to have access to the source code.
 
Consider.....if you make a modification to the source in DBA, you must constantly maintain that with every new mainstream update.  Maybe that is a problem, maybe not.  Depends on your situation.
 
With access to the SQL, if you want to make an application "on-the-side" so to speak, you can write the app in whatever language seems appropriate and connect it directly to the database through the SQL.  If there is an update, then your related application should not have to be re-written.  Unless of course it is a quite significant change in the manistream app.  But even DBA tries not to do really major changes too often.
 
And the open SQL editor tied to the open report writer in Ezijobz should solve one of the most frustrating problems with DBA in that it should be possible to get reports that provide the information that YOU want in the format that YOU want.
 
All of that said, according to Mike, there are still some BIG limitations on the import of the historical transactional data.  The reason for this is the totally different structure of the information in Ezijobz.  It is FAR more complex than you think to convert data when you have to change and combine and cut and paste and such with that data in order to get it in to a new format.
 
And, of course, it has to be done WITHOUT error or it should not be done at all.
 
And THAT is where Evolution comes in.  You can slowly get some new capabilities without making that leap.

Yes, the SQL interface will be nice. It would be better to be able to add on w/ seperate programs than to have to add on to source code that will change (of course, that's what diff, perforce, cvs, etc are for.) I agree that the new program will be far easier to interface with. Still, to a lot of people it might seem like a ripoff when they are used to source. I guess it isn't a huge deal really. My biggest problem w/ making interfaces to DBA was how stupidly the database format was laid out. It was probably fine in 1991 but it's terrible now. The new SQL interface will be a breath of fresh air.
 
And, I happen to have had the distinct honor (if you want to call it that) to have done some of that cutting/pasting/restructuring of database fields from one format to another. You are right that sometimes it's really tricky. Still, these people had the old design in front of them. They had an OPEN slate for the new design. Maybe hindsight is 20/20 but I would have thought that their overriding goal would have included support for a total conversion of data. It should have been possible to facilitate that to a large degree. Granted it does have to be done 100% or nothing but I still maintain the someone with access to the old should be able to design the new to be not impossible to convert to. Granted the old database layout is terrible... So maybe they just shot themselves in the foot 12 years ago.

We've been running dba since 1999 and don't plan on switching until the day that dba no longer supports it. Have enough trouble everytime we update. Don't want a lynch mob coming after me.
 
Gary Lampka
S.A. Day Mfg. Co.

Has any one run the EziJobz demos?  Comments?
 
 
Bill Leventhal
Circle Gear
 
 

We need to wait and see what kind of manufacturing capabilities are in the new product, specifically build-to-stock.  The demos I watched showed a product geared towards a service-type business or maybe a small job shop.
 
I assume the new product is still under development and that the intention is to modify the original Ezjobz product to make it attractive to the same user base as DBA.