slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) (01/06/89)
This is a request for opinions about dBase III + (IV ok) vs. Paradox. I have a
small applications that will grow with time. The users are about as naive as
they come. The appilications will have two sugnificant features:
large files (zilions of records)
four files now, up to eight later, from which information will have to be
extracted.
The whole thing has to run on a PC (large disk).
I know of dBase and I have heard of Paradox. If you can suggest which one you
like better and why, OR if you can suggest another product that you think may
serve better, I would be most grateful for any advice. I would appreciate
direct e-mail responses; should their be numerous, I will post a summary back
here. If you cannot reach me by e-mail, please be assured I will check this
newsgroup daily for at least two weeks (probably end of January 89).
With manu thanks
Stan
---
Happy New Year!
Stan Olejniczak Internet: slores%gables.span@umigw.miami.edu
University of Miami UUCP: {uunet!gould}!umbio!solejni
Miami, Florida, USA Voice: (305)-547-6005
My opinions cannot possibly represent the views of anyone else!debra@alice.UUCP (Paul De Bra) (01/07/89)
In article <gables.426@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: >This is a request for opinions about dBase III + (IV ok) vs. Paradox. I have a >small applications that will grow with time. The users are about as naive as >they come. The appilications will have two sugnificant features: >large files (zilions of records) >four files now, up to eight later, from which information will have to be >extracted. >The whole thing has to run on a PC (large disk). >... If with a PC you mean that it has to run DOS, the large disk may not be very helpful, as each partition can be only about 30 Mbytes or so. So your database (even just one of the eight files) may not fit in one partition. For zilions of records you may need a database that runs on Unix (Xenix), so both dBase III+ and paradox are out. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
jbayer@ispi.UUCP (Jonathan Bayer) (01/07/89)
In article <8685@alice.UUCP> debra@alice.UUCP () writes: =In article <gables.426@umigw.miami.edu= slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: ==This is a request for opinions about dBase III + (IV ok) vs. Paradox. I have a ==small applications that will grow with time. The users are about as naive as ==they come. The appilications will have two sugnificant features: ==large files (zilions of records) ==four files now, up to eight later, from which information will have to be ==extracted. ==The whole thing has to run on a PC (large disk). ==... = =If with a PC you mean that it has to run DOS, the large disk may not be very =helpful, as each partition can be only about 30 Mbytes or so. So your database =(even just one of the eight files) may not fit in one partition. = Sorry. Much as I like Xenix, I have to point out that most versions of DOS which are sold these days now have the ability to have partitions of greater than 32 meg. If the dos doesn't directly support it then there is plenty of add-in software that will -- Jonathan Bayer "The time has come," the Walrus said... Intelligent Software Products, Inc. 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi
fyl@ssc.UUCP (Phil Hughes) (01/10/89)
In article <gables.426@umigw.miami.edu>, slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: > This is a request for opinions about dBase III + (IV ok) vs. Paradox. I have a > small applications that will grow with time. The users are about as naive as > they come. The appilications will have two sugnificant features: > large files (zilions of records) > four files now, up to eight later, from which information will have to be > extracted. > The whole thing has to run on a PC (large disk). Let me put in a plug for Progress. It is available for DOS (as well as UNIX and VMS). I have been using it for over 2 years under UNIX and am both impressed with the product and with the support. Progress Software Corporation publishes a list of bugs and which versions offer the fixes on a regular basis (every 3 months I think). When I have called their support number with a question I have either talked immediately to someone who knows something or they called me back within 30 minutes. This has not been my experience with other software companies. Rather than a lengthy sales pitch, lets just say it is easy to use (with one language to describe the menus as well as reports) great diagnostics and great defaults. They used to offer a test drive which was a complete version of the software except it would only support about a 50K database. I actually used this to develop our application before the real version arrived. They are Progress Software Corporation at 617-275-4500. -- Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155 (206)FOR-UNIX uw-beaver!tikal!ssc!fyl or uunet!pilchuck!ssc!fyl or attmail!ssc!fyl
greg@mdbs.UUCP (Greg Feldman) (01/10/89)
In article <gables.426@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: >This is a request for opinions about dBase III + (IV ok) vs. Paradox. I have a >small applications that will grow with time. The users are about as naive as >they come. The appilications will have two sugnificant features: >large files (zilions of records) >four files now, up to eight later, from which information will have to be >extracted. >The whole thing has to run on a PC (large disk). >I know of dBase and I have heard of Paradox. If you can suggest which one you ^^^^^ ^^^^^^^ I'd say more than about 20Meg would be really pushing these guys. >like better and why, OR if you can suggest another product that you think may >serve better, I would be most grateful for any advice. I would appreciate Take a look at MDBSIII (yes, we sell it). There are folks using it on LANs with databases around 400-600 Meg. They are quite happy folks. MDBSIII interfaces with various programming languages, like C, Cobol, Pascal, Basic, and a few of our own, Knowledgeman and Guru. P.S., I saw someone worrying about DOS's 32 Meg File limit, that can be taken care of by increasing your SECTOR size during disk config time. (like, it's a good thing to know ahead of time :-)) It's not really the 32Meg limit, but the number of sectors. Since there is a limit of 64K sectors, and the default sector size under DOS is 512, 64K * 512 = 32Meg. So, 64K * 2048 = 128 Meg. A larger sector size has it's good and bad sides, but that's another story... Also, you can partition your Large Disk so it can support multiple drives. P.S.S. --> how big's a zillion?
jec@nesac2.UUCP (John Carter ATLN SADM) (01/15/89)
In article <8685@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes: > In article <gables.426@umigw.miami.edu> slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: ] ]This is a request for opinions about dBase III + (IV ok) vs. Paradox. I have a ] ]small applications that will grow with time. The users are about as naive as ] ]they come. The appilications will have two sugnificant features: ] ]large files (zilions of records) ] ]four files now, up to eight later, from which information will have to be ] ]extracted. ] ]The whole thing has to run on a PC (large disk). ] ]... ] ] If with a PC you mean that it has to run DOS, the large disk may not be very ] helpful, as each partition can be only about 30 Mbytes or so. So your database ] (even just one of the eight files) may not fit in one partition. ] ] For zilions of records you may need a database that runs on Unix (Xenix), ] so both dBase III+ and paradox are out. ] ] Paul. Several vendors have software that 'fixes' the 32meg partition problem under DOS. Partitions of 280megs are mentioned in some of the ads. dBASE can handle something like 16 million records (per database). It's 10pm on Saturday night, all my reference docs are at the office, and this comes with no warranty or guarantee whatever. -- USnail: John Carter, AT&T, 401 W. Peachtree, FLOC 2932-6, Atlanta GA 30308 Video: ...att!nesac2!jec Voice: 404+581-6239 The machine belongs to the company. The opinions are mine.
jr@ncrsecp.Copenhagen.NCR.dk (Jakob Riis) (01/21/89)
In article <1626@ssc.UUCP> fyl@ssc.UUCP (Phil Hughes) writes: >In article <gables.426@umigw.miami.edu>, slores%gables.span@umigw.miami.edu (Stanislaw L. Olejniczak) writes: >> small applications that will grow with time. The users are about as naive as >> they come. The appilications will have two sugnificant features: >> large files (zilions of records) >> four files now, up to eight later, from which information will have to be >> extracted. >> The whole thing has to run on a PC (large disk). > >Let me put in a plug for Progress. I too have been happy with Progress. It is not SQL, and thanks for that! If, though, you should want to fire off a couple of these ugly, nested bastards, Progress will swallow it and you can even modify the statements with screen colors etc. When you have naive users, I think you should look at a product called FastTrack, which is an add-on to Progress, which allows you to build menus and screens fast. Menus in std-Progress is a pain in the **, the screens are easy as long as you accept the proposed from Progress. If you want to build advanced, customized (e.g. look like a form) you might be well of with FastTrack. FastTrack can even, I am told, be used by end users for report writing and QBF. One little piece of advice: If Progress is to be used in BIG applications it might be a good idea to take the Progress course that stresses index analysis. We had some very bad expiriences with response times because we didn't know what we were doing with the indexes (you can build the prototypes, though, without thinking of indexes, you can add them later). >It is available for DOS (as well as >UNIX and VMS). and even CTOS/BTOS too, if anybody is using that anymore. >They are Progress Software Corporation at 617-275-4500. My 2 cents, -- Jakob Riis, NCR Corporation Systems Engineering Copenhagen Jakob.Riis@ncrsecp.Copenhagen.NCR.COM or ....mcvax!enea!dkuug!ncrsecp!jr