HP3000-L Archives

December 1997, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
WirtAtmar <[log in to unmask]>
Reply To:
WirtAtmar <[log in to unmask]>
Date:
Fri, 5 Dec 1997 19:11:49 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
Glenn Cole wrote me privately:

> > The
>  > problem with CIU is that people have found a few strange corner cases
> where a
>  > very few "gurus" have long ago programmed up situations where CIU = ON
> would
>  > break their code -- and most importantly, in the process, corrupt their
>  > databases.
>
>  Do you have any examples of this (particularly the latter instance)?

I'll break all the bonds of netiquette and respond to his question publicly.

The "corruption" isn't physical, in the sense of bits and bytes, but logical.
One scenario that I've heard is that people have written a specific purpose
update routine consisting first of a DBUPDATE attempt. If that fails, they
then set an error flag. The normal condition occurs when the error flag is set
-- because these people are using DBUPDATE as a measure to determine whether
they are attempting to update some sacred field; if that proves to be true,
they back out (actually nothing has happened to this point) and update a
wholly different dataset. When CIUPDATE is ON, their error flag condition
never occurs (because the process completes normally), thus they're putting
their data in the "wrong" place.

Because of this very odd bit of trickery, using DBUPDATE in a manner for which
it was never intended, a whole bunch of people are being denied the ease and
utility of CIUPDATE.

Wirt Atmar

ATOM RSS1 RSS2