atieu@skat.usc.edu (Anthony Tieu) (02/13/90)
Need a review on Clipper, the dBASE compiler. Does it really compile dBASE code into EXE files without modifications? How is it in support, documentation, bugs, etc.? Any experiences, good or bad? What is the latest version? Anthony
ajauch@ics.uci.edu (Alexander Edwin Jauch) (02/13/90)
In article <22844@usc.edu> atieu@skat.usc.edu (Anthony Tieu) writes: >Need a review on Clipper, the dBASE compiler. Does it really >compile dBASE code into EXE files without modifications? How ^^^^^^ ^^^^^^^^^^^^^ >is it in support, documentation, bugs, etc.? Any experiences, >good or bad? From my (albeit limited) experience there are a number of procedures that differ from dbase 3 to Clipper. Usually it takes me about three hours with a Clipper manual to translate a medium size program. This is because of Clipper limitations, the modified program still runs under dbase fine. Alex Jauch AdCom, UCI ajauch@bonnie.ics.uci.edu
tenbarge@pewter.ucs.indiana.edu (02/13/90)
/* Written 6:18 pm Feb 12, 1990 by ajauch@ics.uci.edu in pewter:comp.databases */ In article <22844@usc.edu> atieu@skat.usc.edu (Anthony Tieu) writes: >Need a review on Clipper, the dBASE compiler. Does it really >compile dBASE code into EXE files without modifications? How ^^^^^^ ^^^^^^^^^^^^^ >is it in support, documentation, bugs, etc.? Any experiences, >good or bad? From my (albeit limited) experience there are a number of procedures that differ from dbase 3 to Clipper. Usually it takes me about three hours with a Clipper manual to translate a medium size program. This is because of Clipper limitations, the modified program still runs under dbase fine. ^^^^^^^^^^^ I wouldn't say that the modifications were due to Clipper's limitations but rather differences in a program that is compiled versus one that is interpreted. Also, Clipper enhancements that add to the dBase language are not part of dBase 3+. Kris Tenbarge tenbarge@silver.ucs.indiana.edu
eichi@forty2.UUCP (Stefan Eichenberger) (02/17/90)
In article <20900016@pewter> tenbarge@pewter.ucs.indiana.edu writes: > >/* Written 6:18 pm Feb 12, 1990 by ajauch@ics.uci.edu in pewter:comp.databases */ >In article <22844@usc.edu> atieu@skat.usc.edu (Anthony Tieu) writes: >>Need a review on Clipper, the dBASE compiler. Does it really >>compile dBASE code into EXE files without modifications? How > ^^^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^ ..... >I wouldn't say that the modifications were due to Clipper's limitations but >rather differences in a program that is compiled versus one that is >interpreted. Also, Clipper enhancements that add to the dBase language are not >part of dBase 3+. > > >Kris Tenbarge >tenbarge@silver.ucs.indiana.edu About the only limitation is that a compiler has to know at compile time, what commands should be translated. Therefor, nasites such as the following macro substitution is not allowed: command = 'use' &command database where database is a *.dbf file. Of course, parameters can with no problems be substituted: dbfile = 'database' use &dbfile is just all right. Furthermore, Browse, create and such full-screen commands of dBase III are not supported by clipper - there are separate utilities supplied to create a new database, create from a structure file is all right, and there is a replacement for browse, which better fits in a programmers environment. There are many enhancements to dBase III +, and of course execution is much faster. *.ndx files are supported, but there are also faster *.ntx files as indexes available. The smallest *.exe file created however is about 100 kByte, about the only drawback. Hope this helps. -- ---------------------------------------------------------------------------- UUCP: ...mcvax!cernvax!forty2!eichi Stefan Eichenberger BITNET: K807817@CZHRZU1A University of Zurich ----------------------------------------------------------------------------
adf@mace.cc.purdue.edu (Brian Moore) (02/18/90)
In article <22844@usc.edu>, atieu@skat.usc.edu (Anthony Tieu) writes: > Need a review on Clipper, the dBASE compiler. Does it really > compile dBASE code into EXE files without modifications? How > is it in support, documentation, bugs, etc.? Any experiences, > good or bad? Clipper is close to dbase with some of the following differences: The edit and browse functions are not there. it is recomended that you use the ntx format for indexes "it's much faster" some functions have been changed to do what they should have done in the first place. you can have arrays. with DOS 3.3 you can have open 255 files. Additional functions. And Much Much More... The support people at Nantucket are fairly good at what they do, at least from my experience. My main problem with Clipper is the EXE overhead. If you were to compile a program with just a rem statement the file would be aprox. 150K. Growth after that isn't so bad, I wrote a 6500+ line program and I think the EXE size was about 350K. If you need more room the linker supports overlays. It's a rather nice system once you get use to it. > What is the latest version? The current version is Summer 87, but they are working on Clipper 5.0. Thats right Summer 87 ---> Clipper 5.0, I think every body is jumping on the 5.0 band wagon. (MSC 5.X, WORD 5.0, WP 5.X) +------------------------------------------------------------------------------+| Brian Moore | || Purdue University Computing Center | We are all just objects in a giant|| Internet: xadf@vm.cc.purude.edu | C++ Program. || Bitnet: XADF@PURCCVM.BITNET | |+------------------------------------------------------------------------------+
sjhaller@lily.waterloo.edu (Steve Haller) (02/20/90)
In article <4175@mace.cc.purdue.edu> adf@mace.cc.purdue.edu (Brian Moore) writes: >The current version is Summer 87, but they are working on Clipper 5.0. >Thats right Summer 87 ---> Clipper 5.0, I think every body is jumping on >the 5.0 band wagon. (MSC 5.X, WORD 5.0, WP 5.X) Does anyone know when Cliiper 5.0 is due out, or if it is already out? Based on Nantucket's history, Would it be advisable to invest in this right away or wait a while until the bugs are ironed out? -------------------------------------------------------------------------- Steve Haller sjhaller@lily.waterloo.edu 4B Honours Computer Science sjhaller@lily.uwaterloo.ca University of Waterloo ...uunet!watmath!lily!sjhaller
awd@dbase.A-T.COM (Alastair Dallas) (02/21/90)
In article <22844@usc.edu>, atieu@skat.usc.edu (Anthony Tieu) writes: > Need a review on Clipper, the dBASE compiler. Does it really > compile dBASE code into EXE files without modifications? How > is it in support, documentation, bugs, etc.? Any experiences, > good or bad? > This is another message in my series entitled "Trust me; my mind is not captive to my employer" :-). I've developed several real world applications in Clipper and I can highly recommend it. Of course, I'm a C programmer so I'm used to edit-compile-link cycles. The language is essentially dBASE, but Clipper has added lots of incompatible extensions that are really nifty but which keep you from using the dBASE interpreter for debugging. Clipper is typically much faster than dBASE III PLUS, but Fox continues to win most benchmarks (and, wordfromoursponsor, dBASE IV is much faster than III+, too). The main problem with Clipper is that the .exe files are minimum 150K or so. Clipper is a mature product, well supported, and I can recommend it wholeheartedly for applications development. Someday soon, Ashton-Tate will offer a Professional Compiler that will be superior in several ways, but until then, I give Clipper high marks. /alastair/
timk@xenitec.on.ca (Tim Kuehn) (02/22/90)
(Steve Haller) writes: >(Brian Moore) writes: >>The current version is Summer 87, but they are working on Clipper 5.0. >>Thats right Summer 87 ---> Clipper 5.0, I think every body is jumping on >>the 5.0 band wagon. (MSC 5.X, WORD 5.0, WP 5.X) > >Does anyone know when Cliiper 5.0 is due out, or if it is already out? >Based on Nantucket's history, Would it be advisable to invest >in this right away or wait a while until the bugs are ironed out? >Steve Haller sjhaller@lily.waterloo.edu >4B Honours Computer Science sjhaller@lily.uwaterloo.ca >University of Waterloo ...uunet!watmath!lily!sjhaller I called Nantucket a couple weeks ago asking about this and upgrades - apparently 5.0 is still in beta test, and the secretary I talked to didn't know of any release date. She did say that if you have proof-of-purchase of the Summer '87 pkg after June of '89 (Or some such month) you can get the upgrade to 5.0 for free (or some nominal shipping/handling charge). +-----------------------------------------------------------------------------+ |Timothy D. Kuehn timk@xenitec.on.ca | |TDK Consulting Services !watmath!xenitec!timk | |871 Victoria St. North, Suite 217A | |Kitchener, Ontario, Canada N2B 3S4 (519)-741-3623 | |DOS/Xenix - SW/HW. uC, uP, DBMS. Quality SW Guaranteed | +-----------------------------------------------------------------------------+
pete@csd4.csd.uwm.edu (Peter T Teresinski) (01/11/91)
I have been trying to compile a large program with clipper 5.0 to run on an ibm-compatible pc with 500K of ram available. I keep getting a run-time error "swap space exhausted." The clipper manual does not discuss run-time errors so I'm not sure what it means. Does anyone know what this means? Any Ideas on how I can reduce the amount of RAM required to run an application compiled with clipper? I've forced most of the source code into overlays. Is there some way I can get clipper to leave some of the unneeded functions out of executable code? How much memory is used when clipper opens a file? Can it be reduced? I'm using a couple of monster-sized dbf's ~900 fields of N8,0. Any feedback would be greatly apprecited.
tleylan@pegasus.com (Tom Leylan) (01/12/91)
In article <8833@uwm.edu> pete@csd4.csd.uwm.edu (Peter T Teresinski) writes: > > I have been trying to compile a large program with clipper 5.0 > to run on an ibm-compatible pc with 500K of ram available. I keep getting > a run-time error "swap space exhausted." The clipper manual does not > discuss run-time errors so I'm not sure what it means. Does anyone know > what this means? > Well Peter, there is a problem with the VMM system of Clipper 5.0, a fix disk is being prepared and is currently in beta test. In the meantime can you pinpoint the line where the error occurs. It usually occurs when some internal requests a large amount of memory, memoedit(), dbedit() and such. I have only encountered the error once (I believe) which was in strtran(), it turned out to be an unnecessary call so I just removed it and everything was fine. If you have compiled a straight S'87 program you can reduce memory and also eliminate some problems by converting the PUBLIC vars to STATIC and PRIVATEs to LOCALs whenever possible. Also convert single vars to arrays if you are not already doing it (well I mean collections of single vars). Are you using .RTLink ? tom
eichi@forty2.physik.unizh.ch (Stefan Eichenberger) (04/04/91)
I'm looking for software to solve the following problem:
Given a database programmed in the dBase compiler Clipper (Sommer 87, not
yet version 5.0).
One would now like to extract organigram-like reports: The user has to be
able to define the 'graphic': Who is the boss, who are the subordinates, etc.
(It won't be a fixed hierarchy, once and for all, it should be redefinable
for each report printed).
Once the hierarchy is defined, the individual boxes of the organigram should
be filled with data from a *.dbf file, that contains one record per member,
with data such as birthday, address, etc. This insertion of data is always the
same and sould therefor be automated.
Any ideas, how this could be done? Libraries for Clipper? Organigramm Packages
that could import data from *.dbf? And would allow a relatively easy 'link'?
Example:
The user defines:
Max
|
|---------------------|
Peter John
|
Eric
Existing database:
:
Max 1.1.50 US Citicen
Peter 1.1.40 Spanish
Eric 3.3.60 Canadian
John 2.12.55 French
:
Printed:
Max
Born 1.1.50
US Citicen
|
|---------------------|
Peter John
Born 1.1.40 Born 2.12.55
Spanish French
|
Eric
Born 3.3.60
Canadian
Any help appreciated! I'll summarize, if need is.
--
----------------------------------------------------------------------------
iNet: eichi@physik.unizh.ch Stefan Eichenberger
UUCP: ...mcsun!chx400!forty2!eichi Physics Institut
BITNET: K807817@CZHRZU1A University of Zurich