We are not planning on dropping the Classic product. Unless All our users just tell us to (I doubt that will ever happen). However there are thing that we are doing to the Evo versions of the program that we cannot do to the Classic version.
 
There are two things working against Classic. One is the compiler has a limit to memory size and quit a few of the programs are at that very limit.  Two, it is a DOS compiler.. it does not do handle windows things like Email and the Mouse , and multi tasking, etc..  
 
But it will continue to run and we are cleaning up the bug in both versions..

I think that IS Tech would be well justified in freezing Classic at the current version and offering only bug patches for that system going forward. It is time for Evo to split off on its own path where any further addition of new features, meaning a new "version", would no longer be bundled as a dual system with Classic. I have made Classic unavailable to my users, I did that without warning them, I did it months ago, and yet I have had exactly zero complaints. Long live Evo~ERP, kiss Classic goodbye  

I don't think it's a matter of hardware. All 25 of our computers are capable of running EVO. However, the cost to change over to EVO is not insignificant, and must be considered. So far I haven't seen any overpowering advantage to switch. Classic still has bugs. EVO has bugs, and I'm not sure which has fewer problems. I wonder how many DBA users have switched to EVO.

Would like to use EVO but everytime I try I end up going back to Classic because EVO hangs up and I have to shut down.  
I am the only one who is using it at all, everyone else took one look at it and went on using classic.

We only use Classic.  We tried EVO but had too many problems with reports not running or features not working properly.  But I voted freeze Classic.  We can live with what we have in Classic.  There's no need to try to improve it.  The future will be with EVO and that's where the effort should go.  We will try EVO again in the near future and see if it is more stable and the features weneed all the time work for us.  Meantime, Classic works fine.

A lot has changed about Evo in that time. Yes, speed has many improved in several areas. One of the secrets to start-up speed is to reduce the number of menu options, since the menus build at start up (use TAS-G to remove unused features). There have also been things discovered, like the fact that many corporate anti-virus programs will check every module, every time it loads. That can be shut off and load speed jumps dramatically.

I am absolutely astonished by the comment of KKMFG who said “good riddance to bad rubbish and trash DBA Classic”.  I have installed DBA Classic 5 times and found it to be one of the best packages around.  I have found, time and time again, that DBA can handle situations that other, more expensive systems (named below) cannot.  It has some glitches but I have been able to easily work around these.  
 
I have many years experience in manufacturing operations using ERP systems and DBA is much superior to other systems such as Made2Manage, Avante and JD Edwards, which were all pretty bad.  MAS90 is a fairly good product but not as good as DBA Classic.  Intuitive ERP and JobBOSS are excellent packages but cost 10 times what DBA costs (as does the other four systems I mentioned).  JobBOSS is top class when used for component manufacture, but a bit clumsy when making complex assemblies.
 
I have not tried out EVO ERP for about 2 years but decided against it at that time, basically because clients did not like the “look and feel” of it.  I have not had a chance to review any EVO enhancements over the last 2 years or so, as I have been very busy, but I have written Lynn a couple of times encouraging her to complete EVO as quickly as possible.  If she develops a product which has the functionality of DBA Classic, in a truer Windows environment, she will have a world beater, in my opinion.  The one area where most of the above mentioned ERP systems are superior to DBA Classic is that they have a slicker GUI, although to be fair, this is something that has never bothered me or my clients.
 
In this latter respect I do agree with KKMFG that Lynn should focus her efforts on EVO and just offer bug fixes for Classic.  I also agree with “callclay’s” comments.

I think we are violently agreeing !!!
 
I do agree with you wholeheartedly that Lynn should just continue with bug fixes for Classic and get EVO completed as soon as possible.
 
Also it is more difficult to sell Classic when one has to explain to a potential client that DBA has dropped this 'great' system (i.e. Classic) in favor of Next Generation (which I worked on for 10 weeks and drove me crazy 'cos the MRP and scheduling does not work).  So the sooner EVO is complete the better, and that will be accomplished sooner if Lynn just focuses her development efforts on one system - i.e. EVO.
 
Regards

Quote:

 
Yes, this was one of my biggest concerns. I don't want Evo crippled just because classic was written back when punch cards were cool and computers were the size of refrigerators. (Just kidding!) Seriously, backwards compatibility sucks for the developer and usually for the end user. MS is taking a lot of flack for Vista and Apple took a lot for OSX but both broke backward compatibility for a reason. Granted, in Vista's case one might be forgiven for thinking that reason is to drive the end user crazy...
 
Give me encrypted passwords and better data layout and I'll be happy.... for a while...

Quote from timgolds on 03/22/07 at 11:24:42:

 
Yeah, I'd like to see CR in place of the Addsum editor (especially since I'm not even all that fond of Addsum but that's a different story) but CR licensing would greatly increase the price of not only development but distributing the program. Not everyone would want to shell out the money. Still, I think it would be interesting if us users reimplemented some of the reports in CR and shared them.
 
But, yes, please, lets get the data structures up to date!

Quote from kevind on 03/22/07 at 13:48:46:

 
There's nothing stopping the group from developing the reports and using them in place of the RTMs as each sees fit. It might be nice to unify our focus onto one reader, as well, but I don't think we should expect IS Tech to put their effort toward this at any time in the near future. It would be problematic in that the Business Objects folks would likely make demands before IS Tech would be allowed to package reports with their product, no matter what reader would be used.

So, the only reason that folks would need CR is to modify the reports. They would also need a viewer to view the reports, which could be built into the app. However, the app. would have to be written in a supported language, which leaves TAS7 out, I suppose.
 
Well, regardless of the implementation (I'm sure that we will come up with several), we can start sharing our reports. We need a bucket on the Wiki and then we can start filling it.

I've had to pull teeth to get users to change over from Classic to Evo.  Some of our users have been using Classic for close to 10 years, and when we needed additional seats Classic was maxed out, so we had to go Evo.  The most common complaints are:
-don't like the interface (solved for the most part by switching modules to 'Classic View')
-prefer text reports to PDF because more info can be squeezed into less space and it's easier to copy/paste from text report previews (again, mostly fixed by going to Classic View)
-network performance is faster in Classic (seems to get better in Classic View too, weirdly enough)
-sort list defaults (they didn't know how to change, but we eventually got it 'sorted')
-icons in Evo had no text indicators (again, Classic View fixes)
-work order schedules bug in Evo (that was fixed by a patch)
-weird multi-monitor behavior in Evo (still an open bug but we've figured out how to work around it)
-Evo tends to freeze/lock-up for a couple of users, though I've never witnessed it myself and it doesn't happen consistently enough to troubleshoot.
 
So basically, our users are happier running Evo in Classic View, and by changing some of the default programs called from Evo versions to Classic versions.  There was only one instance where the Evo View was preferred:  SO-A.  We could not figure out how to search by customer PO# in Classic View, but the users could in Evo View.
 
If Classic were to be frozen, I'm not sure how that would effect our ability to run in Classic View.  Would things eventually break as the two code bases start to diverge?

Thanks, Lynn.  I didn't realize how old this thread was til after posting!  But your reply is still helpful.
 
Tim