Re: In defense of the lowly MR -- MIDRANGE-L

Hi Jim,

I have a number of disagreements with this approach.  You've thrown the bait
out, now I think I'll bite.   :)

<snip>

>Example:  You have a master file with several auxilary files of
>information, let's say a customer master file with a unique keyed
>logical by customer number and a notes file with a unique key logical by
>customer number, date and entry number.
>
>While editing notes, you choose to delete a note.  As a standard course
>of action we mark the entry for deletion so we can provide an undelete
>function.
>
>While editing the customer master file we also just mark the master for
>deletion.  We do not mark all dependant children files records for
>deletion.  That gets done later.  This way we can undelete the customer
>master without having to undelete the dependants, not knowing which were
>intentionally deleted as above.

<snip>

The computing public has come to expect real-time databases, and by not
deleting children records you run the risk of serving your users dirty data.
If user A deletes the master for which user B has a child record on screen,
user B may never know of the change because user A was not required to lock
all dependent records in order to delete. This is just one reason orphan
records are unacceptable.  Another reason is that if a user queries a
dependent file to get hash totals, orphan records will show in the total
even though the parent was deleted.

And I don't know that being able to undelete a parent without knowing which
children were deleted with it is such a good idea.  Better to have a last
changed date/time/user stamp on the record so that you can perform a manual
"rollback" of all records whose last change date matches the parent.

>
>This is a function of a periodic housekeeping program which uses the
>customer master keyed logical as the IP file, and the customer notes
>keyed logical as the IS file and a shared access path duplicate of the
>notes keyed logical as a UF file.

Again, you're not serving up a real time database.  That's getting less and
less acceptable to savvy computer users.


>We do it this way because if we ran the notes file as US we would be
>locking each an every record that we came accross, not good.

No need to lock a record that you're not prepared to change immently.  As
long as you don't lock on every read, locks are nothing to be afraid of.


But what it really comes down to is that MR is a kluge that was required
when RPG worked over primitive databases.  Now through the use of RDB's with
better views, joins, triggers, and stored procedures, there's no reason to
do in RPG what the database was designed to do.  If it's the job of the
database to do, leave RPG out of it.

jte

*************************************************
* John Earl     Gig Harbor, Washington  U.S.    *
* Email:        johnearl@blarg.net              *
*************************************************

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *