A note about list/@/*...

Denys writes:
> 1- List processing is fastest when it is reusing the prior list.
> 2- Numeric list processing is faster than Alphabetic list processing.
> 3- Numeric lists are prone to breakage is an item is deleted or inserted in
> the schema.
> 4- Numeric and alphabetic lists are immune to additions or movement of
> fields within a dataset.

Number 4 (expressed by many people in the last day, although in
different words) is technically correct, but may be functionally wrong.

When you add a field to a dataset, the enumerated list and subsequent
uses of the "*" list are "safe" only in that they won't cause buffer
overruns like a "@" list might.   ... thus the "technically correct".

What about my "functionally wrong" claim?

Does this mean, however, that the data being added or updated (or read
and acted on) is correct?  It depends.  You're gambling that the
DB administrator, when he/she added the new field(s), was correct in
assuming that the application (program *AND* database) would work
correctly absent the knowledge of the new field.

If the new field is, for example, an employee birthdate, and the
"add new employee" application isn't updated to know about the field,
then by definition any entries added (via DBPUT) will have empty
values for the birthdate.  Perhaps the new application, WHO_IS_OLDER_TODAY,
which generates "happy birthday" email messages to employees, will be
written to properly handle empty values, and the other new application
ADD_BIRTHDATE_INFO_AS_DISCOVERED will be used forever.

OTOH, what if the new field is a govenment or business mandated field
that *has* to have correct values?  If the DB Administrator overlooks
an application that updates/adds data to the dataset, then entires could
be generated with incorrect (missing) data.

As Steve Cooper preached, decades ago (wow!), the correct method is to
have the application open the database, use DBINFO to determine the
structure of the datasets, and then (perhaps) REFUSE TO RUN if the
structure changed.  (Perhaps the refusal is the default, but overridable
via a JCW or control flag somewhere.)

Note that this checking protects you from changed item types and changed
item sizes, as well as new or missing items!

The initial DBGET/DBPUT would use the enumerated list, and then be
changed to the "*" list ... preserving safety and speed.

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html