Xref: utzoo comp.databases:2334 comp.sys.ibm.pc:27454 comp.binaries.ibm.pc.d:2681 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!silver!sl161011 From: sl161011@silver.bacs.indiana.edu (Kevin Clendenien) Newsgroups: comp.databases,comp.sys.ibm.pc,comp.binaries.ibm.pc.d Subject: Re: Dbase compilers information Summary: Clipper is a viable candidate Message-ID: <3753@silver.bacs.indiana.edu> Date: 15 Apr 89 01:59:58 GMT References: <2430@cps3xx.UUCP> <3785@utastro.UUCP> Reply-To: sl161011@silver.UUCP (Kevin Clendenien) Organization: Indiana University BACS, Bloomington Lines: 41 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 ------------------------------------------------------------------------