Well the time has finally come. I have been given to start planning our new system. From what I understand (I have only been at this position for a little less then a year) the orignal system was written in the early 90's dBase IV and has been way outgrown and outdated as you can imagine. So my question is, what are newer better solutions that I should concider? I am currently plan on using PostgreSQL as a backend. For the frontent I am debating between a windows base GUI or something web-based. Visual C++ possibly or maybe Java via JSP for web-based. We need something that has good printing support and also will be able to integrate online. Anyone have any ideas?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Time to Upgrade 1
- Thread starter dcomartin
- Start date
Being involved with a similar upgrade process, I can understand some of the issues you're dealing with. Although Visual dBase is a definite improvement to dBase IV, I feel it simply will never have a huge global presence and therefore future programming enhancements may be limited. It's greatest advantage is to keep older dBase code going with minimum of change.
Since I (and the real decision makers I work for) are also familiar with Visual FoxPro which is more "mainstream", we are doing as much as posssible of the new programming in VFP. The language and concepts are quite similar to dBase, cousins so to speak, so the learning curve is not too bad.
There are limitation to running the 2 environment concurrently during the rewrite: VFP wants to create its own indexes, so neither language updates the other's indexes. Also, VFP creates tables that cannot be read by dBase, but it can copy them to the "older" format.
VFP can work with it's own tables, though they are not as secure and insulated as separate data repositories such as the pricey SQL Server, etc. (A major reason SQL Server is more robust is that servers in a locked room don't get turned off or unplugged or rebooted just any old time, like a worker can do to a workstation.) Yes, VFP tables cannot be larger than 2GBs but most files never reach that size anyway. VFP can also be a front end to SQL Server and other databases. As you can tell I like VFP. It and its keywords are oriented toward tables and databases. VB is popular too but is more of a generic program.
Is it that you'd rather not design 2 front-ends, such as both VFP program AND browser access? That's a design and needs issue. Both or either can be done.
If you use the browser as a front-end, it can communicate (such as from HTML accessing ASP code on the web server) with a VFP object for database access and programming logic processing as long as the code called does not ever try to write to a screen. (There is no screen available when a web page calls ASP which calls VFP COM-compliant object and so even a minor error cannot display.)
Additional reading:
thread184-686677
thread184-558851
thread184-499163
thread184-287740
thread184-148598
thread184-57123
dbMark
Since I (and the real decision makers I work for) are also familiar with Visual FoxPro which is more "mainstream", we are doing as much as posssible of the new programming in VFP. The language and concepts are quite similar to dBase, cousins so to speak, so the learning curve is not too bad.
There are limitation to running the 2 environment concurrently during the rewrite: VFP wants to create its own indexes, so neither language updates the other's indexes. Also, VFP creates tables that cannot be read by dBase, but it can copy them to the "older" format.
VFP can work with it's own tables, though they are not as secure and insulated as separate data repositories such as the pricey SQL Server, etc. (A major reason SQL Server is more robust is that servers in a locked room don't get turned off or unplugged or rebooted just any old time, like a worker can do to a workstation.) Yes, VFP tables cannot be larger than 2GBs but most files never reach that size anyway. VFP can also be a front end to SQL Server and other databases. As you can tell I like VFP. It and its keywords are oriented toward tables and databases. VB is popular too but is more of a generic program.
Is it that you'd rather not design 2 front-ends, such as both VFP program AND browser access? That's a design and needs issue. Both or either can be done.
If you use the browser as a front-end, it can communicate (such as from HTML accessing ASP code on the web server) with a VFP object for database access and programming logic processing as long as the code called does not ever try to write to a screen. (There is no screen available when a web page calls ASP which calls VFP COM-compliant object and so even a minor error cannot display.)
Additional reading:
thread184-686677
thread184-558851
thread184-499163
thread184-287740
thread184-148598
thread184-57123
dbMark
- Thread starter
- #3
I really appreciate the reply. You have start a spark for me to look into Visual FoxPro. I really had not thought about it. The main issue is printing and being able to create libraries that I can also be use from a web environment. Thanks again for the reply.
Derek
Derek
-
1
- #5
You might also consider the latest version of dBASE - dBASE Plus ( It can handle both types of interfaces without much extra work. It will interface with most SQL based engines or you can use the one that comes with it. The runtime version of the engine can be installed on a Web server free of charge. They even supply Web server software.
There's a nice article on their page about how to put live applications on the Web.
There's a nice article on their page about how to put live applications on the Web.
Having spent the last 20 years (?) programming in dB2,3,3+ and lastly dBXL, I have been looking at updating my company accounts software (dBXL). As Windows XP only just seems to run DOS apps, I have been looking at Visual dBase, Delphi (both going cheap) and Access. Completely unaware that Dbase (as in dBase Plus) was still available.
Any comments on Dbase Plus much appreciated.
Any comments on Dbase Plus much appreciated.
For converting to dBase Plus, look into dBase SE.
Christopher F. Neumann
[dBASE Charter Member]
Blue Star Visual dBASE graduate
ICCP TCP/IP Network Analyst
Data Communications Engineer
Christopher F. Neumann
[dBASE Charter Member]
Blue Star Visual dBASE graduate
ICCP TCP/IP Network Analyst
Data Communications Engineer
- Status
Similar threads
- Locked
- Question