johnl@ima.UUCP (10/17/85)
To: info-ibmpc at CCA/*USC-ISIB.ARPA, net.micro.pc
--------
Here is a fairly long message describing my experience with the new Paradox
data base. I have been playing with Paradox for the past few days and have
mixed feelings about it. On the one hand, there are a lot of things that
Paradox makes it very easy to do, much easier than other micro databases
that I have dealt with. On the other hand, there are things that seem a lot
harder than they should be, and some strange warts. I'll describe Paradox
first, then go into a few comments. Please keep in mind that these are my
personal opinions and not those of my employer or any other organization.
Paradox might be described as a combination of a Query-by-Example relational
data base, a what you see is more or less what you get form and report
language, and an Algol-like application language.
The query and definition language is a more or less direct ripoff of Zloof's
Query by Example, which is no insult because QBE is pretty neat. (I ripped
it off myself while doing work for my thesis.) The data base is a true, no
cheating, relational one. Each data base file is a table of records. There
are no links between records stored in the data base. Indices for items can
be defined but have no effect on operations other than speed. You phrase a
query by going into an "ask" menu which gets you a template of the table(s)
you're interested in, you fill in the fields that you want it to look up,
mark the fields that you want it to retrieve, and say DO_IT! (the F2 key)
and it goes and finds the records that match what you asked for. You can
retrieve records from more than one table by introducing sample items that
have to match in records retrieved in the two tables, i.e. a relational
join, as it selects stuff.
Once you are looking at records in a table, either via a query or because
you asked to look directly at the table, you have your choice of looking at
a table in the standard format, or of defining "forms" which lay out the
data in a record any way you want. Forms are defined by painting them on
the screen, both the areas where the data goes and plain text for
formatting. Virtual fields (calculated on the fly from fields in the record)
can be displayed, and there are zillions of format options for each field.
Both the table and the forms can be "live" and you can enter and edit data
through both. Many forms can be defined for any table, which is quite handy
so you can have detailed forms, summary forms, censored forms for just
showing a subset of the information and so on.
The report language resembles the form language in that you paint your
report on the screen more or less as you want to see it. The report
language has a flexible scheme of nested boxes, e.g. record boxes within
page boxes within group boxes within a box for the whole report. This gives
a lot of flexibility and I found I could whip up nice looking reports in no
time. Painting the text on the screen lets you get the fields lined up
right the first time, unlike more conventional report languages. Report
definition is flexible enough that you can do form letters ("yes, Mr.
LEVINE, won't your neighbors in CAMBRIDGE be envious when they see your new
Cadillac...") and they have lots of examples in the manuals.
The application language PAL is a very complete Algol-like language with
procedures, loops, variables, and arrays, and all the built-in functions you
could want for arithmetic, string munging, environment control (e.g. is the
printer turned on) and table manipulation. It is also a macro language that
can stuff keystrokes at the Paradox engine. I found the Algol-like part and
the macro part to be poorly integrated, but that's probably unavoidable in
anything that tries to be both, and it's certainly better than the way you
embed QBE calls in PL/I. By the use of forms you can easily set up data
entry and presentation screens and get canned applications going quickly.
PAL gives you complete control over the screen and it is straightforward to
write closed applications where the user never sees Paradox. They include a
sample project accounting application which demonstrates PAL well.
So far, so good. But there are some things that seem very hard, which is a
shame. Perhaps I am just suffering from lack of imagination, and I invite
people to point out what I've missed, but here are some of the things which
I had trouble doing. The worst, I think, is producing a report of a subset
of a table. Each report format is associated with a table, and when you ask
for the report, it prints the whole table. If you set up a query to select
a subset of the records, that's fine but the records are retrieved into a
separate temporary table called "answer" and there seems to be no way to
report from the answer table using a report format already defined for
another table. I'm sure I can fudge it in PAL somehow, but it's not obvious
how. There are also some formatting operations that you seem totally unable
to do in a report. I have a large table imported from a dbase file
(importing works like a charm, by the way) with some string fields that are
longer than a printed line. Paradox is happy to produce multiple pages to
be glued together side by side to report these long fields, but I could see
no way to break up a field and report it on several lines on a page. There
is a substring function in PAL, but you don't seem to be able to use it in a
report definition. I could write a PAL script that copied my table into a
new one, substringing the large fields into several smaller ones, but that
seems like a lot of work, especially since my file is already 900K and I'm
not eager to recopy it just to print it. (Such a large file is, of course,
a list of bugs reported in another program.) The 900K file was only 500K in
dbase, by the way, I think because dbase trims trailing blanks from text
fields better than Paradox does. There are other similar complaints about
defining and using forms, but you get the idea -- some things that seem (to
me) to be very common things to do seem unexpectedly difficult. Perhaps if
I used dbase more I'd be grateful that anything at all is easy.
Finally, Paradox seems to have lots of little bugs. For example, there is a
configuration option to avoid snow on your color screen, but you get snow
anyway. At least once, it got some internal error and dumped me back to
DOS, without losing any data, though. Sometimes when it sorts my large
file, or when I change the schema a little (changing one field from floating
numeric to short integer) I end up with a mystery record at the front of
the table which I have to delete. I don't have enough experience yet to tell
whether any of these bugs cause trouble when doing real work -- so far I
haven't done a lot of real work, but what I have done has worked fine.
So in sum, it is very easy to define, enter, and query your tables. It is
easy to make nice looking forms and reports, so long as you want to print a
report of a whole table at a time. It's certainly worth a look. I think I
would try it if I had work to do for which a single-user database was
appropriate (I really need a multi-user network data base for my work.)
John Levine, ima!johnl or Levine@YALE.ARPA
--------