[comp.sys.ibm.pc] dBASE IV features

awd@dbase.UUCP (Alastair Dallas) (06/16/89)

In article <109@dbase.UUCP> I wrote:
> If there's something you need to
> do and dBASE IV can't do it for you, I'd like to hear about it :-).

Tom Haapenen of the University of Waterloo wrote:
: Just some gripes about dBASE III+ that may or may not have been fixed...
: How about letting me trap function keys other than F1?

dBASE IV supports ON KEY LABEL PgUp, Ctrl-F8, etc.

: Or having consistent syntax for assigning to variables and fields?
: Or being able to nicely handle multiple files?

Not sure what you mean here--we deliberately make fields and variables
different to make it clear when you're changing data files or just RAM.

: Or having all indices automatically updated without having to open
: each one (and thus running into DOS's open file limits)?

Thanks for the setup.  One of the best features of dBASE IV is MDX, or
multiple index files that do just what you want.  You can have up to 47
indexes in a single file and that file can be associated with a DBF data
file and be automatically opened and updated.  We also get around DOS's
open file limits and let you open 99 files (memory permitting).

: <Example with something called 'Progress' omitted>
: Is this all possible in dBASE IV?  If so, I guess I better upgrade, since
: I've got this one application that turned into a massive hack in dBASE III+
: because of problems like those mentioned above.

I think you'll find that dBASE IV is worth a closer look.  There are dozens
of new commands and functions.  I think people read a claim like that in an
ad and gloss over it, but with a mature product line like dBASE, one new
command tends to be highly leveraged.  Here's some new commands/functions
off the top of my head:

	SCAN...ENDSCAN	 - performs a group of commands on a set of data
	LOOKUP()	 - finds a value in another table (typically to
			   validate data entry)
	CALCULATE	 - statistical/financial analysis of a set of data
			   (many calculations with a single pass thru the file)
	GOTO TOP IN Employee, ? EOF(3) - remote workarea access w/o SELECT
	and MENUs, POPUPs, ARRAYs, (of course)

: I hope you don't take this personally, but I'm quite frustrated with
: dBASE III+.
:
:					\tom haapanen

Under the circumstances, I quite understand.  :-)

/alastair/

Disclaimer: This is unofficial dBASE-boosting.  Ashton-Tate doesn't speak
for me, and I return the favor.

leonard@bucket.UUCP (Leonard Erickson) (06/19/89)

DBSETUP has what I consider a bug. If you try to use the "modify config.db"
to change color settings, it doesn't work. You have to go in and delete
the existing settings with an editor first. Worse yet, it appears that if
you try to change your mind (ie you've already done the ctrl-end and
decide to go back and change that setting) that doesn't work either.

The changes *do* show up on the screen but they aren't saved.
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Short

eichi@forty2.UUCP (Stefan Eichenberger) (06/20/89)

In article <114@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:
>In article <109@dbase.UUCP> I wrote:
>: Just some gripes about dBASE III+ that may or may not have been fixed...
>: How about letting me trap function keys other than F1?
>
>dBASE IV supports ON KEY LABEL PgUp, Ctrl-F8, etc.
Yes, but they don't solve the problem! Consider the following code:
    @ ..,.. get Field1 Valid Function1 (Field1) Picture 'XXXXXXXXXX'
    @ ..,.. get Field2 Valid Function2 (Field2) Picture 'XXXXXXXXXX'
    :
    :
    On Key Label F8 Do BackBack
    read
    On Key Label F8 
where the panel is intended to insert some sort of contract in a database
and BackBack is a procedure to open a panel for a opposite contract (Back to
Back), then you are lost! Pressing F8 does not terminate the read, but
merely INTERRUPT it! So, at that time, you are not sure about the values of
the variables Field1 and Field2. If you have not yet positioned the cursor
in Field2 befor pressing F8, Field1 has not been checked against Function1.
You could solve this by rechecking Field1 in BackBack. But worse, if the
user just entered the first three letters in the 10 character wide Field1 and
then pressed F8, he would be in the believe to have entered some new input.
Not so dBase IV: Field1 would still have the old value it had befor the user
entered anything. (I hardly know how to explain this behaviour to
programmers, but try to explain it to users of your program!)

Don't come along with some excuse that one couldn't do this in dBase III
clones either (you certainly can't in AT products :-)): Clipper Sommer 87:
    @ ..,.. get Field1 ...
    @ ..,.. get Field2 ...
    :
    :
    Key = DummyValue
    set key F8 to KeyHandler  && F8 is a variable containing the scan code of
                              && of Function Key F8. That's about the only
                              && thing AT does better!
    read
    set key F8 to
    if Key = F8 
      do BackBack
    endif

    Procedure KeyHandler
      Keyboard (PgDn)   && I did this a long time ago, the manual is far away,
                        && is 'Keyboard' the right function to insert PgDn
                        && into the Keyboard Buffer? I am not sure about
                        && the exact name, but it exists and that's certainly
                        && a possible solution to terminate the read
       Key = F8
    Return    && KeyHandler

>file and be automatically opened and updated.  We also get around DOS's
>open file limits and let you open 99 files (memory permitting).

What do you do with all these 99 files, if you are only allowed to have 
10 *.DBF files open at a time? (Haven't we had this discussion during
dBase II times: Two *.DBFs are not enough? Today, 10 are too few but
some people newer learn... Clipper opens 256 files under DOS 3.3, irrespective
of there type.

>: <Example with something called 'Progress' omitted>
>: Is this all possible in dBASE IV?  If so, I guess I better upgrade, since
>: I've got this one application that turned into a massive hack in dBASE III+
>: because of problems like those mentioned above.

You will have a huge amount of 'Insufficient Memory' Messages, especially
if you try to run a network application, with, say Nowell software loaded,
eating up som 80 to 100 kByte (Wouldn't AT say, that today everybody could
have a '386 and load the network above 640 kByte with Quarterdecks HiMem
coming along with QEMM 386? At a local exhibition, I asked about EMS support
for dBase IV. The answer of the Ashton Tate representative (which introduced
himself NOT beeing a technician):

   "EMS SUPPORT IS MENTIONED IN THE MANUAL, BUT THE PROGRAM IGNORES IT
    ONLY THE NEXT RELEASE..."

Not to mention all the bugs still present in dBase IV.
>
>I think you'll find that dBASE IV is worth a closer look.  There are dozens
>of new commands and functions.  I think people read a claim like that in an
>ad and gloss over it, but with a mature product line like dBASE, one new
>command tends to be highly leveraged.  Here's some new commands/functions
>off the top of my head:
> (List of some new commands deleted)

Ever compared this list with the 'new' (two year old) commands implemented
in Clipper? DBEDIT, MEMOEDIT, ...
Or look at Select ('FOO'). In dBase IV, it returns true, if the *.DBF in the
currently selected area is FOO. But how to find out, whether it's somewhere
else? Select Foo returns an error, if it's nowhere open, Use Foo, if it's
already open somewhere. Look at Clipper now: Select ('Foo') returns the
area number, where Foo is open, 0 if nowhere. 
  If Select ('Foo') <> 0
    select Foo
  else
    use foo
  endif
does the rest.
>>
>: I hope you don't take this personally, but I'm quite frustrated with
>: dBASE III+.
Me with dBase IV. Don't take this personally, alstair!
>:
>:					\tom haapanen
>
>Under the circumstances, I quite understand.  :-)
Do you?
>
>/alastair/


-- 
----------------------------------------------------------------------------
UUCP:      ...mcvax!cernvax!forty2!eichi         Stefan Eichenberger
BITNET:    K807817@CZHRZU1A                      University of Zurich
----------------------------------------------------------------------------