We've just begun evaluating dba's NG system (EziJobz SME) for an 'engineering-to-order' company.  Needs are relatively modest at this point and the system appears to be a good fit.
 
Not too certain, however, is whether the dba company is up to providing support.  Their approach to the pre-sales relationship is underwhelming.  The free single user system is a great idea and an easy way to get a feel for how it all works, however pre-sales support is either paid or non-existent.  Without this critical piece, there's no way to fully test-drive the software or the company itself before making a commitment.
 
Can anyone provide some insight / experience in their dealings with dba support?  If you're on a paid support plan, do they provide timely responses to user/implementation questions and bug fixes?  Are they courteous to you and/or your users?
 
Has anyone experience any major bugs or data loss with this product?
 
Thank you for any comments you can provide.

Ticketing system usually isn't bad, I've been getting responses usually fairly quickly. Sometimes I get a quick answer if it's a simple support question. Sometimes I get told to RTFM (my words), but the manual backs me up and they just say the manual is out of date. (Manual is still out of date in a lot of areas - things flat out don't work as described). Sometimes I get arguments because I can't/won't do something the way they think I should (usually, what's easier for them to work with, not what's actually needed in the shop). Sometimes I get an issue sent to programming (after extensive testing to document the exact steps required to duplicate it at their end). Just about fell off my chair the other day - actually got a personal support call and on-line session. The result? Next day I got told (again, my words) "You're right, it doesn't work. Tough sh*t." Are they courteous? I have to say yes. One of their techs is ok to deal with. Even if I don't always like what he's saying, he's (usually) willing to listen and understand what the issue is from my user perspective, and willing to admit a mistake when they happen. The others, I get the impression, are pretty green. They basically seem to say what they're told to say.
 
Fixes are a different matter entirely. There's a standard disclaimer that they give you when sending something to the black hole called programming - they will be fixed in the order that benefits the most users. Apparently that means that, if you have 25+ users you stand a chance. We have 1, and are still waiting for fixes that date back to the release of ver 3. (not including their dropping the configurator). Updates are getting more frequent, but I usually lose more in the update than I gain.
 
The ezijobz system they bought had more bugs than the Yukon, many of them structural. Some of them have been fixed, some not. We need the service module, since we do a lot of service-type (job-shop) work. Still waiting for fixes, though there have been a lot of changes to other areas, especially accounting. From the sounds of things, although they are promising an update to the service job module, the direction they say they are going to move in makes me wonder how long it'll actually be useful.
 
Specific issues for me, at the moment, have to do with purchasing and cost reporting - neither of them works well.  
 
Data loss? Data I can't get at through NG reporting because of the way they do their reports, but not really lost. Major bugs depends on the user environment. Items have key fields that should be unique system-wide, NG uses the visible part number as its key field in BOTH Items and descriptors with no crosschecking between them. Since you use both types of "parts" in a common BOM, it's easy to duplicate a number and confuse things. Nothing in the docs, and apparently it's not their problem to solve. Want to charge a purchase to a job? Item has to be added to job, then PO created from there if you want the costs linked. Anything added to the PO afterwards goes into stock (or wherever) but NOT to job. Buying a non-stocked part into a job is a major pain, and not going to get better.  You can set up a miscellaneous non-stock descriptor for purchases like that, and the costs are received properly in the database, but you need a different miscellaneous descriptor for every non-stock line on that PO because the reporting pulls costs out by part (descriptor) number. Nothing in the manual about that. Their freeform alternative works the same way (ie doesn't) even though it's the recommended procedure for this in the manual and is, in any case, being discontinued. Apparently EVERYTHING I buy that is "stockable" should be an inventory item (their words) with an assigned part number. Their program tracks items (their words) not costs (mine).
 
There are some things that I really like about the system, but I'm losing confidence.  
 
Anything else you want to know?

I don't like that the overall tone was as negative as it ended up being, but some of the issues in NG are buried. If someone wants to look at it, bless'em, but pay attention to the details  that aren't in their videos and TEST anything you read before you believe it. It does have value, and some relatively big operations are using it.
 
As I said, there are things I do like - mainly the data visibility. BOM access, which is often both hidden and limited in function in other programs, is right there. Reports (some need work) and inquiry functions (where used, history, availability, etc) are right there. Context switching between workflow functions is more than adequate in most areas (though there are hiccups) and getting better. Cost rollups, often the bain of other programs, are a trivial matter to do. The data grids and screen outputs mean I can format, filter and sort any of those screens quickly without exporting to excel first, and then output the prepped list to printer, file, etc.. The methods sytem is interesting and occasionally useful. For our operation, with limited requirements (most or all of what we need is available in most other related systems, it's the BOM aspect that typically falls short) it should be a piece of cake. Firebird, for me, has been plug & play, very compact and no problems. Time recording has improved dramatically since I first looked at NG - still slower than what we use now, but worth a serious review soon.
 
I don't know who was responsible for the list of features in Classic, but I seriously think they aren't with DBA now. Too many fundamental differences in program direction, and the "philosophies" they are trying to promote show a lack of understanding of how a working shop does things and why.  
 
You probably made the right choice for your operation. For ours, EVO has too many similarities with what we are coming from, that didn't work. I still have the demo, though, and it's still installed  

Quote from Steve Stoneman on 07/12/07 at 10:36:12:

 
DBA is at least fairly up front about that. I was aware that they don't guarantee anything in data conversion. It's one of the reasons we're using Evo instead of NG.  
 
Quote:

 
Short answer: you don't get those transactions back. You have to practically reverse engineer what they were supposed to be and manually add them.  
 
Quote:

 
Yes, any time you switch software you'll take it in the shorts a few times. New software = new things to adapt to.
 
Quote:

 
Yes, this is what I love about ISTech. They actually talk to you and you can bug them when things aren't working yet.
 
Quote:

 
Umm... It's a SQL interface, there isn't any such thing as a data dictionary anymore. At least there shouldn't be. It's simple, simple, simple to get the structure of a table in a SQL based DB.
 
Quote:

 
Yes, it's a TOTALLY different program. And the users here hate the way it's setup. It's akin to Microsoft buying OSX and switching all windows users to it. It's that different and that shocking of a change.
 
I still maintain that it's SQL based layout is better than BTRIEVE and Delphi is better than TAS.

So.. stop banging your head against a wall and upgrade your Classic to Evo.. It will feel so much better when you stop.
 
(Blatant sales pitch)  

NovaZyg - we will probably be talking! Got to take a breather first.

You are right, you definitely need more help looking at things. I had not heard of IBEXPERT. I ended up getting the Firebird Data Wizard from http://www.sqlmaestro.com/
 
It helped me view the data much easier and even output it into excel spreadsheets for me to peruse. Absolutely great tools but still looked like nondescript spaghetti to me (more like dog worms). I had to step back and say, "This is nuts!"

never heard of sqlmaestro, but I'll look at it.
 
IBExpert has free personal edition, lots of functions (most of which I can't use yet, or don't need).
 
-
 
I wonder if they wouldn't be better off open-sourcing it? Or, maybe linking it to an outside accounting package and concentrating on the shop end of things for now. There are things that are unique in it, with lots of potential.