We have recently outgrown our 5 users on DBA Classic, and have been told that if we purchased additional users we would also have to purchase add'l pervasive software V9 as well as the DBA licences.  Do you think that it would be wise to upgrade to a new version of DBA?  What would be the major differences and would it be easy to convert Classic over?
Any suggestions?

Is EVO-ERP also called DBA the Next Generation?

Currently on Pervasive 8, do I need to upgrade current users to Pervasive 9 or only add ons.

Not to hijac, but if I understand from the posts above, I can update my 2000i to the latest Pervasive and continue to run my DBA Classic??? I didn't know that was possible.  
 
It would be great if I could as I have written an internal GUI that we use to interface to DBA via odbc (not a complete redo with all the menus like Evo - just specialized entry fields/reports that show only what I need my employees to see/change). I can't get a DAC component to talk to 2000i, but they are available for later versions of Pervasive. That would allow me to dump odbc and talk directly to the db which would be faster. Plus I could go client/server which should buy me some more speed I think in doing selects from bk/mticmstr.
 
I think we are running 12 users on Classic, so I would need 12 update to PSQL9 I assume.
 
Thanks.
 
Lenny

Peice of advice!
 
If you are using ODBC to access pervasive on a Windows Server,  Upgrade to 9.5. You will thank me later!  9.5 runs much better on WIndows 2000 and 2003 servers with the ability to control processors and optimize for ODBC connections through the microsoft OBDC engine.  Also  Make sure you have the latest patch for MDAC on the server.
 
Hope it helps,
 
Tim

I'm firmly in Lenny's corner. No one MRP or ERP system fits our company well, nor can our little company afford to write something from scratch. The hybrid is the way to go. IS Tech has worked well with us hybrid folks so far and I prefer the current arrangement over working with an open source system. We have the rich, mature, stable feature set of a commercial application, plus the community atmosphere of a user-developed application.  
 
Also, I'd like to learn more about the parallel system for MRP. I may be interested in doing the same type of thing for scheduling / capacity planning.

GasGiant,
 
The parallel information is nothing more than just a MySQL server running with your own custom tables defined in it. It's really just like writing your own from scratch as you design all the tables & relationships. Plus, you have to code your own GUI to read/write it all. DBA is not going to have *any* idea of these tables. Not an easy task, but if you have someone on staff who can do it, it's really nice.
 
All of our barcode tracking is in mysql. (We mfg circuit boards) All pcbs are barcoded when they are kitted and then scanned along every step such as: smt assy, reflow, aoi, through hole assy, inspection, test, conformal, final inspection, ship. ect. Plus I store other pieces in there as well such as mnf part information changes, bom changes, ect. DBA can do some of this as well, but anything new I use MySQL. No way would I try to duplicate what DBA has done with accounting/GL/AP/AR. I would never find all the bugs I would create.
 
Scheduling/Capacity planning is on my todo list as well. We are constantly growing as our sales starts pushing our mnf capacity, good planning/scheduling is mandatory. A nice interface with drag/drop & the ability to push/nudge jobs around to see the results would help a lot. There are off the shelf schedulers but again, it's the same issue. They are garden variety & we will have special needs.
 
One thing to be wary of. If you are paying your IT person to do these things and they leave, the knowledge goes with them. I can guarantee it won't be documented well enough for just anyone to drop right in. If it were documented that well, it would cost you 4x more to develop. So there is a downside to have a custom widgit. For us, it's a moot point since I am an owner as well as the resident SW/HW geek.
 
I also like open source & have thought about migrating to an open source erp, but we have a ton of time/money/training invested in DBA to just switch without good cause. Open source with no ability to buy support I don't think is good unless you are a SW guru. I think the DBA/EVO thing works for many people because you do have an option to pay someone to solve a problem for you.
 
Lenny
 
 
 
 
 
Lenny

Quote from lenny_baledge on 10/01/07 at 09:54:03:

 
Should be easier than MRP, and no need to write back to DBA (which I assume you had to do for POs, etc. with the MRP). I recently wrote a browser-based order entry system and have used MySQL for storing and working with quotes. It is faster, simpler, more flexible, and works nicely through VPN for our field sales and service people. I insert the orders into the EDI module as quotes where the production managers check, convert, acknowledge, and print sales orders. It has been working so well that I'm going to do the same type of thing for RMAs now that the unified returns module is complete.
 
Quote from lenny_baledge on 10/01/07 at 09:54:03:

 
I am the IT person: systems analyst, MRP/ERP/CRM guru, web developer, programmer, IT project coordinator, etc. The tools that I have developed for our people are browser based and use standard web development tools like PHP, XHTML, DOM, Ajax, CSS, etc. Both the code and the project are documented, for my benefit as well as the company's, but my knowledge of DBA and its structure would take awhile to replace. However, if I were to walk away tomorrow, Evo will keep going and nothing would be lost except a bit of flexibility. By sticking with the hybrid the company is protected from the downside while I am free to spend as little or as much time as I want making things work better.