X-no-Archive:yes
Stand has managed to confuse me, he knows it's easy to do and he persisted
in doing so.

I originally said:
> 4- Numeric and alphabetic lists are immune to additions or movement of
fields within a dataset.

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

Then he explained:
>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".

I cannot image how a buffer overrun could be generated if you use a numeric
of alphabetic lists.  Actually, I can think of two ways:  If the DB guy
decides to insert a new item in the items definition in the schema and
makes this item larger than the one right after it.  (But the other items
it the numeric list might point to correspondingly smaller items.) To guard
against this, is exactly why I would use the alpha name of the item during
the construction of the numeric list.  So really the only ways to break
this technique is if the DB guy decides to make an item used in the list
bigger or if he renames a used item.  But then in the latter case, the
program should terminate during this construction because DBINFO does not
find the item.

Bottom line if the DB guy changes an existing item already in use without
taking the appropriate actions, then perhaps some other form of
communication is required, like maybe a two by four.

Kind regards,

Denys. . .

Denys Beauchemin
HICOMP America, Inc.
(800) 323-8863  (281) 288-7438         Fax: (281) 355-6879
denys at hicomp.com                             www.hicomp.com


-----Original Message-----
From:   Stan Sieler [SMTP:[log in to unmask]]
Sent:   Wednesday, 02 December, 1998 11:59 AM
To:     [log in to unmask]
Cc:     [log in to unmask]
Subject:        Re: [HP3000-L] Turbo Image List Processing

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