scholten@cpsvax.cps.msu.edu (David Scholten cps) (04/10/89)
Hello netlanders, I am in the processes of developing a simple inventory database system for my parents. What I need is a DbaseIII compiler to finish the job. I am currently looking at DBfast (because it is cheap). Can anyone send me info (advantages/problems/pros/cons...etc) about the available compilers. I need something cheap since they (nor I being a student) can afford something like DbaseIV. Please send email Thanks in advance, Dave Scholten
emuleomo@yes.rutgers.edu (Emuleomo) (04/11/89)
Although Foxbase+ is not a strict compiler, it still allows you to "compile" your DbaseIII language code into a superfast ".FOX" module. Also, since you are thinking of compiling your code, you MUST be interested in PERFORMANCE. It is no secret that Foxbase+ is the fastest gun in the land!! Emuleomo O.O Accurate Information Systems <A satisfied Foxbase+ User>
hgcjr@utastro.UUCP (Harold G. Corwin Jr.) (04/12/89)
In article <Apr.10.17.04.11.1989.17768@yes.rutgers.edu>, emuleomo@yes.rutgers.edu (Emuleomo) writes: > Also, since you are thinking of compiling your code, you MUST be interested > in PERFORMANCE. > It is no secret that Foxbase+ is the fastest gun in the land!! Speaking of database managers: I'm about to embark on a cataloging project that will eventually entail working with many MB of data files, both numerical and ASCII. I'm looking for recommendations for a dBase III or IV compatible, relational, programmable database manager with at least a subset of SQL implemented, that supports IBM's high order ASCII character set, AND that supports a LONG text field (4KB or more would be fine). The text field is needed to carry along notes on the catalog entries. Since I'm running an 8MHz AT clone, some sort of optimization for speed would also be desirable (additional machine features if important: 640K base memory, 2M extended memory, 80287 coprocessor). Leading contenders so far include r:Base for DOS, Paradox (though the text field would have to be kludged from a bunch of 255B fields), and FoxBase Plus (I don't know if version 2.1 supports a text field beyond 512B). Any others that I should be thinking about? I'll summarize if there is enough interest. Many thanks! Harold Corwin -- Harold G. Corwin, Jr. UUCP: {backbonesite}!{noao,cs.utexas.edu}!utastro!hgcjr Internet: hgcjr@astro.as.utexas.edu MaBell: 512-471-7463 Astronomy Dept., RLM 15.308, Univ. of Texas, Austin, TX 78712-1083
alexis@ccnysci.UUCP (Alexis Rosen) (04/14/89)
In article <2430@cps3xx.UUCP> scholten@cpsvax.cps.msu.edu (David Scholten cps) writes: >I am in the processes of developing a simple inventory database system >for my parents. What I need is a DbaseIII compiler to finish the job. >I am currently looking at DBfast (because it is cheap). Can anyone >send me info (advantages/problems/pros/cons...etc) about the available >compilers. I need something cheap since they (nor I being a student) >can afford something like DbaseIV. What you really want is performance, not an EXE. Get FoxBase+. Not only is it incredibly fast and bug-free, but it has many features that make things which are difficult or impossible in dBase III very easy to do. It is one of the truly finest pieces of software on any platform in terms of conception and execution. Also, it runs even better on the Mac than on the PC, so it's near my heart for that reason also. :-) --- Alexis Rosen alexis@ccnysci.{uucp,bitnet}
sl161011@silver.bacs.indiana.edu (Kevin Clendenien) (04/15/89)
In article <3785@utastro.UUCP> hgcjr@utastro.UUCP (Harold G. Corwin Jr.) writes: >Speaking of database managers: I'm about to embark on a cataloging >project that will eventually entail working with many MB of data files, >both numerical and ASCII. I'm looking for recommendations for a dBase >III or IV compatible, relational, programmable database manager with at >least a subset of SQL implemented, that supports IBM's high order ASCII >character set, AND that supports a LONG text field (4KB or more would be >fine). The text field is needed to carry along notes on the catalog >entries. Since I'm running an 8MHz AT clone, some sort of optimization >for speed would also be desirable (additional machine features if >important: 640K base memory, 2M extended memory, 80287 coprocessor). >-- >Harold G. Corwin, Jr. Clipper from Nantucket will fit the bill quite nicely. It supports character fields up to 32K bytes. It has some nice functions for dealing with strings up to 64K bytes. It is 99% dBase III compatible. But better yet, it has so many extra functions, that you'll yearn to throw off dBase III code compatibility, and just go with Clipper code. If you want to maintain dBase III compatibility, it provides you with a public variable that your code can test. If it's true, your program uses Clipper code, if its false, it sticks with dBase code. It will default to index files of its own making (they make for faster searches than dBase index files), but you can instruct it to stick with dBase index files. Best of all, it compiles into machine executable code. No need for runtime packages, or licenses. In my experience, running on a PS/2 network, it is easily five times faster than dBase III. There are only two drawbacks that I know of. It has a few bugs. I have not yet found one that I could not work around, but they were annoying until I isolated them to bugs in the compiler and not my code. I have not encountered a new bug in well over a year, so I suspect there aren't many to be found. The other drawback is that the code generated from linking includes all Clipper libraries, whether or not they are actually used or not. This may just be a function of the linker supplied with Clipper, but I've learned to live with code that is a minimum of 150K. Clipper provides support for overlays, either external or internal, and will take advantage of memory above the 1M level to use for buffers. All in all, if given a choice, I would choose Clipper over dBase III any day. ------------------------------------------------------------------------ sl161011@silver.UUCP Kevin Clendenien ------------------------------------------------------------------------
alexis@ccnysci.UUCP (Alexis Rosen) (04/16/89)
In article <3785@utastro.UUCP> hgcjr@utastro.UUCP (Harold G. Corwin Jr.) writes: >Speaking of database managers: I'm about to embark on a cataloging >project that will eventually entail working with many MB of data files, >both numerical and ASCII. I'm looking for recommendations for a dBase >III or IV compatible, relational, programmable database manager with at >least a subset of SQL implemented, that supports IBM's high order ASCII >character set, AND that supports a LONG text field (4KB or more would be >fine). The text field is needed to carry along notes on the catalog >entries. Since I'm running an 8MHz AT clone, some sort of optimization >for speed would also be desirable (additional machine features if >important: 640K base memory, 2M extended memory, 80287 coprocessor). > Leading contenders so far include r:Base for DOS, Paradox (though >the text field would have to be kludged from a bunch of 255B fields), >and FoxBase Plus (I don't know if version 2.1 supports a text field >beyond 512B). Any others that I should be thinking about? I'll >summarize if there is enough interest. Many thanks! First of all, Neither Paradox or rBase are in the least bit compatible with dBase. Fox is by far the fastest, and FoxPro, due early June, is up to three times faster than the current version. SQL support isn't there yet, but they are working on a Novell-based server product which will speak both Dbase and SQL (and it will really speak SQL, not translate like dBase IV). As for long text, Fox has memo fields but you can't use them for much in the current version. FoxPro, on the other hand, has unlimited-length text fields (maybe limited to 4GB- not a real problem :-) which can be manipulated like and text object. (In addition, the length of program lines can be up to 1K now, wihch can be convenient.) For example, you can say Stuff(Replicate("abcde",5000), 5000,10000,"x") which evaluates to a string which is 20,000 bytes long. More practically, you can test for emptiness or a particular substring, and you can index on these fields and search for them. I know this will be in FoxPro because I saw it not five days ago at comdex. In general, FoxPro is an astonishingly slick package. When you see it, you won't believe your eyes. It's like nothing ever done on a PC before (but in fact it's rather exactly like something that was done on a Mac: FoxBase+/Mac). --- Alexis Rosen alexis@ccnysci.{uucp,bitnet} alexis@rascal.ics.utexas.edu (last resort)
allbery@ncoast.ORG (Brandon S. Allbery) (04/18/89)
As quoted from <Apr.10.17.04.11.1989.17768@yes.rutgers.edu> by emuleomo@yes.rutgers.edu (Emuleomo): +--------------- | Although Foxbase+ is not a strict compiler, it still allows you to | "compile" your DbaseIII language code into a superfast ".FOX" module. | Also, since you are thinking of compiling your code, you MUST be interested | in PERFORMANCE. | It is no secret that Foxbase+ is the fastest gun in the land!! +--------------- It's also no secret that Ashton-Tate's ARCing over about it. (Think about it....) Frankly, I suspect that that lawsuit will benefit Oracle, Informix, the folks who make R:Base, et al. more than it will A-T or Fox; I, for one, would steer clear of both products and anything similar to dBase until the legal shenanigans are concluded. A rewrite now is cheaper than a rewrite later (or a speed loss possibly hitched to a price hike, if A-T wins). Just my opinion, you understand. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
cs3b3aj@maccs.McMaster.CA (Stephen M. Dunn) (04/21/89)
In article <3753@silver.bacs.indiana.edu> sl161011@silver.UUCP (Kevin Clendenien) writes: ... >many to be found. The other drawback is that the code generated from >linking includes all Clipper libraries, whether or not they are actually >used or not. This may just be a function of the linker supplied with >Clipper, but I've learned to live with code that is a minimum of 150K. >Clipper provides support for overlays, either external or internal, and This is not due to using PLink86; it also occurs with DOS LINK and Borland's TLINK. As for using the supplied linker, I wouldn't bother unless you need overlays; it's dreadfully slow!!! I don't have any real numbers here, but I gave up Plink long ago for the DOS linker due to speed problems, and then I switched to Tlink. I have a package that links in about 6 seconds on a 12 MHz AT clone with a 25 ms hard drive using Turbo Link; with the DOS linker, it takes about three times as long! DISCLAIMER: I have absolutely no connection with Nantucket, Microsoft or Borland other than the fact that I have used some of their products. -- ====================================================================== ! Stephen M. Dunn, cs3b3aj@maccs.McMaster.CA ! DISCLAIMER: ! ! This space left unintentionally blank - vi ! I'm only an undergrad ! ======================================================================