fritzz@lamont.ldgo.columbia.edu (fritz zaucker) (08/31/89)
Is there anybody who has expierence with different databases for UNIX? I am looking for something to run on a 386 based PC under ix/386. Thanks Fritz
bruce@mdi386.UUCP (Bruce A. McIntyre) (09/03/89)
In article <1652@lamont.ldgo.columbia.edu>, fritzz@lamont.ldgo.columbia.edu (fritz zaucker) writes: > Is there anybody who has expierence with different databases for > UNIX? I am looking for something to run on a 386 based PC under > ix/386. > Thanks, Fritz I have used the following: name: Progress from Progress Software, rate: Tops in most catagories type: 4GL / Integrated rdbms, next version(6.0) will access Oracle/Sybase O/Ss: Unix, Xenix, PC-Lan, PC-DOS, VMS, CTos, Aux, Aix, others coming name: Oracle from Oracle rate: Tops in breadth of market type: RDBMS with Forms, Reports, C interface, other 3GL interfaces O/Ss: Unix, Xenix, PC-DOS, VMS, Mcintosh, Aix, others name: Informix from Informix rate: Tops in report writer, good screen painter type: RDBMS with Forms, Reports. Add on 4GL, C-interface O/Ss: Unix, Xenix, PC-DOS, VMS, Aix, others name: Foxbase+ from SCO rate: Tops in dBASE compatibles for most environments type: dBASE compatible DBMS, runtimes available O/Ss: PC-DOS, PC-Lans, Xenix, Some UNIX, McIntosh I feel that for most purposes and the widest variety of systems where I have to deliver and maintain working systems in the minimum time and with the maximum performance and effectiveness, I choose Progress. I can literally move code to any of the supported environments unchanged, and it will run correctly. It is fast, solid, and with full transaction processing, automatic roll-back, etc. It is one system where I know that I can yank the plug out of the wall of a running application, and have the database roll itself back to the last valid completed transaction without intervention, even in a Unix environment. I have built systems where I had 100 users under Unix, and am now building an application that will have a working database size of over 2 GigaBytes. There is a good user community, several add on tools, libraries, etc. It has a C interface to call C routines, but the language is so flexible that I have never had to use it. It offers both the ease of a non-procedural language, and yet has the control of a 3GL where you need it. You can mix Progress 4GL language and standard SQL in the same procedures, as SQL is implemented in native mode, not an interface or embedded interpreter. There is a full development test system available for $95 for most of the standard environments, and the only limitation is the number of times you can start the server against the database. However, you could develop the complete application from the TestDrive. These opinions are mine, based on my experience, and while I do act as a reseller of Progress, there is no other connection. bruce -- ========================================================================= Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895 143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915 {wells|lgnp1}!mdi386!bruce bruce@mdi386 tbit+
dyer@spdcc.COM (Steve Dyer) (09/06/89)
Progress is rather nice in some ways, but the fact that it's a procedural
language without subroutines was ultimately VERY frustrating. You could
construct macro-substitution templates which expand in-line into code,
which gives you a subroutinish feel, but all the versions of the language
I used (up to and including 4.0--I don't know what's current now) had a
strict 64K limit on compiled-byte-code size, which liberal use of macro
expansions would break. Also, the lack of local variables was another pain.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edubruce@mdi386.UUCP (Bruce A. McIntyre) (09/16/89)
In article <4525@ursa-major.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes: > Progress is rather nice in some ways, but the fact that it's a procedural > language without subroutines was ultimately VERY frustrating. You could > construct macro-substitution templates which expand in-line into code, > which gives you a subroutinish feel, but all the versions of the language > I used (up to and including 4.0--I don't know what's current now) had a > strict 64K limit on compiled-byte-code size, which liberal use of macro > expansions would break. Also, the lack of local variables was another pain. > -- > Steve Dyer > dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer > dyer@arktouros.mit.edu, dyer@hstbme.mit.edu There are some real mis-communications and conceptions here.. First of all, the include file macros can be passed positional parameters or named parameters, and are a very fast way to work. If you must use subroutines, then you can run lots of small .p procedures to do what you want and configure the memory buffers to handle them well. This is true for both Version 3.x and 4.x, and we now use Version 5.x. As for 64K size limit, that is true, but for someone who wants to write with sub-routines, you can call any number of sub-procedures, each one of which can be up to 64K compiled size. Remember that is the compiled size, as the source can be larger, especially when using the include files. All variables can be defined as Global, Shared, or Private... in fact the default is private local. I think perhaps Steve gave up a little too soon. If there is anything that is idio-syncratic about Progress, it is the use of Scoping and Frames... But you learn to love it. Also with version 5.x, you can mix both Progress 4GL code and SQL statements in the same code, even use Progress Verb modifiers to SQL statements. It supports standard Ansi SQL. This is native mode, not just an interface. There is a Progress users BBS available at 215,446,4035 that is NOT run by Progress, but by Progress users. Give it a call if you have such questions.. bruce -- ========================================================================= Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895 143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915 {wells|lgnp1}!mdi386!bruce bruce@mdi386 tbit+