Erik Vistica writes:

>One possible (probably not the best) way to implement the feature is to
>intercept all DBGET and DBPUT calls (some 3rd party and home grown tools
>do this now) for those programs that need the extra data validation.

It should be assumed that *all* programs need the extra data validation
except in very limited circumstances.

>Some programs can be trusted (ha ha) so you wouldn't want the speed
>penalty all the time.

With good design, the speed penalty can be made pretty negligible for
many data types. I think the design should require PM to turn off the
validation: if the data base designer saw fit to include data editing
rules, they should be enforced for *all* user programs. There can be a
global or per-dataset flag that says whether there are *any* read or
write procedures associated with the dataset. This would cut out the list
processing overhead in those cases. Of course, if the validation
information is stored in the root file together with other item
information, the extra flag wouldn't be needed.

Besides, is it more important to have right answers eventually, or wrong
answers quickly?

>When DBPUT is called, you intercept, then based on the 'list' parameter,
>for each field in the list, do a look-up in some 'field configuration
>table' to determine if there is a write() function registered and if so,
>call it. This write() function will contain all the specific business
>rules for this field. If the data for all fields pass muster, then you
>can finally call the real DBPUT.

The information as to which fields have write() procedures or their
equivalent can be cached along with the list information to speed up
subsequent calls. It's not clear what the read() procedure might be used
for, but it could be provided for completeness. There would obviously be
a performance cost to this.

Incidentally, from a practical point of view I don't see much difference
between an arbitrary read()/write() function and a pseudo-function that's
specified with the field configuration language aieeeee (I assume that's
an acronym but I don't know the meaning). An arbitrary function gives
more flexibility, but a higher implementation complexity and also the
requirement to handle exceptions.

>As I am a functional-SQL-illiterate, for all I know this may be one of
>the purposes of stored-procedures.

Yes, this is one thing for which stored procedures can be used.

>Jim Brust wrote:
>>
>>...   Seems to me that data editing and
>> validation should be left to data entry programs.

That assumes that there's ONE data entry program. If there's more than
one, which one's business rules prevail? The data base is a logical place
to store an extended data description and have it enforced. There is a
limit to the complexity of the checks that can be done from within the
database, but that's better than none at all.

-- Bruce

--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
btoback AT optc.com                |     -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.