msr@tropix.uucp (Melanie S. Roche) (09/27/90)
I would like to here from anyone who has experience with the Empress DB package. I am currently thinking of purchasing this package for a new project. Any information about the package would be appreciated. Please use email to respond. Our news is about two weeks behind because of disk space. My email address is tropix!msr@gca.com. The application that we will be using this package for is a medium to large size database accepting information from many other machines and will be running on the Solbourne model 5/600.
ethan@thinc.UUCP (pri=-5*Ethan A. Lish of THINC) (09/28/90)
In article <1990Sep26.192938.1101@tropix.uucp>, msr@tropix.uucp (Melanie S. Roche) writes: > I would like to here from anyone who has experience with the Empress DB > package. I am currently thinking of purchasing this package for a new > project. Any information about the package would be appreciated. Please > use email to respond. Our news is about two weeks behind because of > disk space. My email address is tropix!msr@gca.com. > > The application that we will be using this package for is a medium to large > size database accepting information from many other machines and will be > running on the Solbourne model 5/600. Greetings - PROGRESS(tm) runs on the Solbourne 5/600 ( *AND* many other UN*X/DOS/VMS/OS2/CTOS/OS400 platforms) A *Quick* list of Features: o Database indepentent 4GL layers on top of; PROGRESS(tm), Oracle(tm) and Rdb/Rms(tm) Databases o Enhanced data dictionary simplifies management of PROGRESS(tm) and alternative data structures. o Support for X-based window managers; MOTIF(tm), OpenLook(tm), Presentation Manager(tm) o Embedded ANSI-standard SQL with Host Language Interface o PROGRESS(tm) and SQL can be intermixed o C routines callable from 4GL o Library of plug-in components and routines o Extended alphabet support for multi-lingual applications o DIF,SYLK,ASCII file import/export o Client/Server architecture and high performance multi-threaded database engine o Distributed processing with two-phase commit o Concurrent access to data in multiple databases o On-Line backup and tuning controls for System Administrators o Run across hardware, Operating Systems, Network Protocols, Databases, and Graphical User Interfaces. o Encrypted Source Code for easy application deployment o Automatic Crash Recovery o Security Controls o Distributed Processing o Variable Length Records **** For more information on these or other PROGRESS(tm) Features *** You may call/write/email you questions to the address below. **** Let me show you how PROGRESS(tm) can solve your application issues *** Thank you, Ethan -- "Life's an adventure.. go for it." Ethan A. Lish ---- 301.652.0651 ---- {uunet}!thinc!ethan Tomorrow's Horizons, Inc.,4807 Bethesda Ave, #330, Bethesda, MD 20814
evan@telly.on.ca (Evan Leibovitch) (10/06/90)
In article <1990Sep26.192938.1101@tropix.uucp>, msr@tropix.uucp (Melanie S. Roche) asks for opinions on Empress: In reply, in article <96@thinc.UUCP> ethan@thinc.UUCP (pri=-5*Ethan A. Lish of THINC) replies: > Greetings - > > PROGRESS(tm) runs on the Solbourne 5/600 > > A *Quick* list of Features: >[...] >**** Let me show you how PROGRESS(tm) can solve your application issues *** Sigh. Maybe someone should tell Ethan about how the net just LOVES postings which parrot marketing babble. Without even the class to send said babble by private mail, as Melanie specifically asked for. Sigh. Lest this be considered totally a flame, let me say that I have spent considerable time working on both Progress and Empress. Both have their strengths and weaknesses, and I must say up front that our company ended up deleting our copy of Empress from the hard disk while we became a Progress VAR. But Empress may still be preferable in some circumstances. Progress is clearly the choice for any developer planning to resell programs or distribute programs to branch offices, as EMPRESS isn't available in a run-time licence. Every site running EMPRESS applications needs a full-development licence. However, for a site which doesn't care about re-distribution, Empress is more complete - some 'C' language interfaces, like imbedded SQL, as extra-cost in Progress but standard in Empress. I like Empress's implementation of SQL better than Progress's. But if you're not wedded to SQL, Progress's native programming language is faster in both time to develop and time to execute. Since going to Progress, despite spending years on Empress and Informix SQL, I found it better to learn the internal Progress language. One feature Empress has which Progress lacks, which is a REAL difference if this matters to you, is its ability to contain arbitrary-length information as a database field. The Empress "bulk" data type is great for applications which may want to contain, say, a video image stored in binary format, as merely a field in a database. A "text" field type is a little like dBASE memo fields but is more flexible. Progress is two major releases away from providing any such capabilities. Where the two differ the most is in the interface presented to the applications programmer, and the reason we dumped Empress. Its M-Builder is very clumsy, uses non-standard mechanisms for describing terminal keys and characteristics (no termcap or terminfo), and is especially awkward at simple pick-and-point operations. There are more things to keep track of when programming Empress, while many Progress defaults are often sufficient for good intuitive operations. The only area of programming where Empress is superior is with its M-Writer report-writing language, which I found a joy. But for menus, entry screens and conventional script logic, Progress is better by miles. Hope this helps both of you. -- Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario evan@telly.on.ca / uunet!attcan!telly!evan / moderator, rec.arts.erotica Of all the things I've lost, I miss my mind the most
louk@tslwat.UUCP (Lou Kates) (10/08/90)
In article <270DDFD3.426A@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >In article <1990Sep26.192938.1101@tropix.uucp>, msr@tropix.uucp >(Melanie S. Roche) asks for opinions on Empress: > >In reply, in article <96@thinc.UUCP> ethan@thinc.UUCP >(pri=-5*Ethan A. Lish of THINC) replies: > >Progress is clearly the choice for any developer planning to resell >programs or distribute programs to branch offices, as EMPRESS isn't >available in a run-time licence. Every site running EMPRESS applications >needs a full-development licence. However, for a site which doesn't care >about re-distribution, Empress is more complete - some 'C' language >interfaces, like imbedded SQL, as extra-cost in Progress but standard >in Empress. I don't know about Progress but we found that Empress' entire development system cost less than the runtime of many other vendors' systems and its often handy to have the development system on the client's machine. >Where the two differ the most is in the interface presented to the >applications programmer, and the reason we dumped Empress. Its M-Builder >is very clumsy, uses non-standard mechanisms for describing terminal >keys and characteristics (no termcap or terminfo), and is especially Since Empress runs on some non-UNIX systems, being able to set these items up in a way which is independent of the way the UNIX utilities work does have the advantage that it would allow you to use identical terminal setup procedures on various versions of UNIX and on non-UNIX computers. >awkward at simple pick-and-point operations. There are more things to We are not using the M-Builder part of the package so perhaps I am wrong about this but since you are currently using Progress and used to use Empress I suspect that you may be referring to an old version of M-Builder. From information I have seen, the current version (version 4.3) supports mouse and touch screens for pick-and-point as well as text terminal emulation of this. Also it should be mentioned that some things that the Empress database supports (I don't know what Progress is like in these respects) include referential integrity, updateable 1-1 views, distributed updates over multiple nodes with two phase commit, user defined SQL functions, read/write access to the system tables and everything comes with the base package except maintenance -- there are no hidden extra cost options. Lou Kates, Teleride Sage Ltd., ...!watmath!tslwat!louk
evan@telly.on.ca (Evan Leibovitch) (10/09/90)
In article <330@tslwat.UUCP> louk@tslwat.UUCP (Lou Kates) writes: >In article <270DDFD3.426A@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >>programs or distribute programs to branch offices, as EMPRESS isn't >>available in a run-time licence. Every site running EMPRESS applications >>needs a full-development licence. >>in Empress. >I don't know about Progress but we found that Empress' entire >development system cost less than the runtime of many other >vendors' systems Not at all the case. The Progress runtime for a 386 running Unix, unlimited users, is <$800 U.S. >and its often handy to have the development >system on the client's machine. This, I guess, is a matter of philosophy. Having development systems on each clients' system allow, even encourages, "quick fixes" which are not applied globally. The developer is saddled with the support nightmare of dealing with different clients, each of whom uses a version of the software on their system slightly different from the original. And I don't know about you, there are clients I have who I want nowhere near the ability to change the database schema/dictionary. >>Empress' M-Builder >>is very clumsy, uses non-standard mechanisms for describing terminal >>keys and characteristics (no termcap or terminfo), and is especially > >Since Empress runs on some non-UNIX systems, being able to set >these items up in a way which is independent of the way the UNIX >utilities work does have the advantage that it would allow you to >use identical terminal setup procedures on various versions of >UNIX and on non-UNIX computers. Sorry, but that's no excuse for Empress having such a miserable way to define terminals. Both Progress and Empress run on Unix, VMS, and MS-DOS (Progress, also on BTOS/CTOS). Progress uses a superset of termcap, while Empress uses a series of terminal database files in which each function key, escape sequence, screen function, and screen attribute is a separate record. Both use their respective terminal description methods across all platforms. But VMS, BTOS and MS-DOS systems rarely have to deal with a wide variety of terminals. It's mainly in the Unix environment where this is necessary. So why not borrow from the widely-used Unix techniques, rather than re-inventing wheels? (This probably has to do with the historical roots of each product. Empress was a VMS product ported to Unix. Progress was a Unix product ported to VMS. But the developers of Empress were quite familiar with Unix by the time they developed the M-Builder terminal interface.) I've had to write terminal definitions for both Empress and Progress. The Progress termcap approach is a winner before you start, because there are so many existing termcap entries floating around. One can run infocmp on any of the many terminfo definitions supplied by AT&T and come up with most of the requirements of a "protermcap" entry, Compared to this, the Empress method is indeed clumsy, and far slower to implement well. The approach to writing for termcap and terminfo is better documented, not only by AT&T but by third-party books such as the (highly-recommended) Nutshell book. The Empress docs, while adequate, are nowhere close. The terminal-configuring procedure, of course, wouldn't be a bother if the vendor supplied a complete list of supported terminals. But in the case of Empress, there was no definiton for something as basic as the Wyse 60, and I recall the AT386 console description being broken. -- Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario evan@telly.on.ca / uunet!attcan!telly!evan / moderator, rec.arts.erotica Of all the things I've lost, I miss my mind the most
alan@cwi.UUCP (Alan Wright ) (10/10/90)
In article <270DDFD3.426A@telly.on.ca>, evan@telly.on.ca (Evan Leibovitch) writes: > Progress is clearly the choice for any developer planning to resell > programs or distribute programs to branch offices, as EMPRESS isn't > available in a run-time licence. Every site running EMPRESS applications > needs a full-development licence. This is absolutely incorrect! Empress does have runtime licenses. Our product, for example, is built around Empress.
louk@tslwat.UUCP (Lou Kates) (10/10/90)
In article <27112761.EC@telly.on.ca# you write: ->In article <330@tslwat.UUCP> louk@tslwat.UUCP (Lou Kates) writes: ->>In article <270DDFD3.426A@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: -> ->>and its often handy to have the development ->>system on the client's machine. -> ->This, I guess, is a matter of philosophy. Having development systems on ->each clients' system allow, even encourages, "quick fixes" which are not ->applied globally. The developer is saddled with the support nightmare of ->dealing with different clients, each of whom uses a version of the ->software on their system slightly different from the original. -> ->And I don't know about you, there are clients I have who I want nowhere ->near the ability to change the database schema/dictionary. -> The reason that having the development system on the client machine is useful is: (1) the client base has a wider variety of machines than you have inhouse (2) clients would not typically wish to make schema changes but they might want to interactively perform ad hoc queries using SQL and possibly write up some reports themselves Lou Kates, Teleride Sage Ltd., tslwat!louk@watmath.waterloo.edu