atb@ncsu.UUCP (andy brown) (07/03/86)
[will someone tell me why these line eater things are here?] has anyone out there had any experience with with dbase iii or dbase iii+ compilers? i've heard that a company called Nantucket out of CA has one. how "bug free" are these programs? how much do they cost? maybe there is a better solution. the problem: i have several dbase programs that i wish to distribute to several small companies; however, they can't affford to shell out several hundred dollars for a full dbase development system or the runtime program dbrun. also, i am not going to give them copys of dbase. any information would be welcome. andy brown: i think this is my path-> decvax|mcnc|ncsu|atb the word for the day is "mombo" . . . use it today!
jim@randvax.UUCP (Jim Gillogly) (07/05/86)
In article <3091@ncsu.UUCP> atb@ncsu.UUCP (andy brown) writes: >has anyone out there had any experience with with dbase iii >or dbase iii+ compilers? i've heard that a company called Nantucket >out of CA has one. how "bug free" are these programs? >how much do they cost? Nantucket makes a dBASE III compiler; the latest version appears to be compatible with dBASE III+. I've had no trouble using it. Compiling is pretty fast, although linking takes a long time; they have a hacked version of Plink86 and a huge library. It appears to handle all of dBASE III (at least all that I've used) and I haven't found any bugs in it. By contrast, I've been bitten by several serious show-stopping bugs in dBASE. You can distribute the executable modules (which are large, by the way: over 100K for a null program). The executable module runs considerably faster than dBASE for user programs; it's about the same speed for things that are single-command dBASE commands such as reports and counting. >maybe there is a better solution. the problem: >i have several dbase programs that i wish to distribute to several small >companies; however, they can't affford to shell out several hundred dollars for >a full dbase development system or the runtime program dbrun. >also, i am not going to give them copys of dbase. Yes, there is a better solution: Paradox. It also has a programming language attached to it, and with version 1.1 (recently out) they offer a runtime module that you can include at a nominal extra cost with your applications. It also has the capability of preparsing routines into a canned library (not quite compiling) which offers you a little privacy for your programs if you want it. By all means check this out if your source code investment isn't too great. -- Jim Gillogly {decvax, sdcrdcf}!randvax!jim jim@rand-unix.arpa
jpg@nvuxf.UUCP (J. Gipe) (07/08/86)
I've been using the Clipper compiler from Nantucket since last November. I have not experience any bugs with the **current** version marked Winter of 85, however the Spring of 85 version had a nasty BIG bug when working with index fields. Occasionally records would not be found in index files. This occurred sporadically and would sometimes go away would you reindexed. Nantucket acknowledged this bug when I spoke with them but sent out no announcement about it. Of course I ended up looking like a jerk when my system didn't work before my customers. The new version has much better documentation, dBASE III+ features and some nice add ons absent from dBASE III, like virtually an unlimited number of files that can be opened at the same time. I'm not sure of the price, I think we paid around $300. I'd say despite my adventure in discovering the indexing bug, that I've been satisfied with the product. Compiled programs run about twice as fast (or better when little I/O is needed) and dBASE III is not needed. Some of the dBASE commands like edit and change are not supported by Clipper and the indexing scheme is incompatible Jan ihnp4!bellcore!nvuxf!jpg