Subject: | |
From: | |
Reply To: | |
Date: | Fri, 5 Dec 1997 19:11:49 EST |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|