Subject Re: Table level
From Mervyn Bick <invalid@invalid.invald>
Date Sat, 29 Sep 2018 18:13:03 +0200
Newsgroups dbase.getting-started

On 2018-09-29 2:03 PM, Ken Mayer wrote:

> Akshat's suggestion is correct, but there's a simpler solution:
>
> set autonullfields off
>
> Set this in your startup code for your application, and for new records:
>
> logical fields will default to false
> dates and character fields will simply be empty
> numbers will be zero

Setting autonullfields off takes care of future records appended to the
tables.  It doesn't get rid of any null values which have already been
saved.  Unless one takes care of both one would still need to deal with
nulls in one's code.

Akshat posted a program which purports to take care of nulls in existing
records.  I'm afraid it doesn't. :-(

This program may well have been based on code I originally posted but
the program as it stands will only replace nulls in character and
logical fields.

q.rowset.fields[n].type returns full words as follows

CHARACTER
NUMERIC
MEMO
LOGICAL
DATE
FLOAT
OLE
BINARY
LONG
DATETIME
DOUBLE
AUTOINC

An AUTOINC field can never hold a null value and dBASE never assigns
null to new Memo, OLE and Binary fields so there is no need to test for
them.

DATE, DATETIME and DOUBLE all start with D so one can't just use the
first character to determine the field_type.  The same applies to
LOGICAL and LONG.  Because full words are returned for the type, the
test q.rowset.fields[n].type $ "FN" will NEVER return true.

Akshat, I'm afraid it's back to the drawing board.

Mervyn.