× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Just because I do an update in my RPG program using RLA operations like
CHAIN, READ, UPDAT and that genre doesn't mean I have any better
protection for bad data.

That being said, let's take another look at data protection. There's two
camps on this.

First there's the camp that says put no checks in the data itself; all
checks should be done with programming only. I've seen software packages
like this. Taken to the extreme that
- Put no primary, unique keys on files. The only thing stopping two item
master records with the same key is programming.
- Allow character data in numeric fields. If someone wants to put a
numeric field into a data structure and overlay that with character data
and have that written out to the database that's their prerogative. They
may have a business need to store a custom character field into a numeric
field they never use.
- If the only 'active' record codes are 'A' and 'D' then handle that with
programming. Never use a check constraint.
- If the on hand of an item goes negative, allow it. Don't stop it with a
check constraint. Don't even handle notification of that with a trigger.
If the user wants to know about it they can rely strictly upon our
interfaces, or they can write a program that checks at a certain interval
(probably long after all heck has broken loose).
- Never journal. Never use commitment control. If the user wants to do a
save-while-active and is comfortable with having an inventory transaction
written to the detail file but the balance not updated to the header file
yet then that's ok. Who cares as long as their purchase and maintenance
checks clear? We'll blame the out of balance condition on their
operations. If we journal, and the user didn't purchase the "HA journal
performance" option of SS1, then that's a performance hit and we sure
don't want our application looking like a dog.

Then there's the camp that uses every database utility that's out there.
After all, triggers and referential constraints have been around for 15-20
years - starting out way back on AS/400's. It's not bleeding edge stuff.
- All files should have a unique key. Even a log file.
- Make full use of referential constraints.
- Make full use of check constraints.
- Make use of triggers.
- Ensure that your applications can take advantage of these items. For
example, if you put a new constraint on a file, and an update fails, make
sure your application handles that and doesn't hurl (like assuming a write
operation that fails can only mean a duplicate record).
- Journal everything. Program for commitment control.

There will always be interfaces that need to be done outside of standard
package stuff. Examples include:
- mergers
- acquisitions
- Software package migrations
- New types of batch/interactive feeds: EDI, shop floor data feeds, time
clocks, etc.


Rob Berendt

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.