Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On 20/09/2010 12:44 PM, Brian wrote:
> On Sep 20, 12:42 pm, paul c<toledobythe..._at_oohay.ac> wrote:
...
>> All the original post shows is that it is possible to paint oneself into
>> a corner with rigid preconceptions. The supervisor doesn't need to
>> muddle two different situations/relation values in one database
>> transaction. He could just as easily amend the 'first' work order in
>> one transaction and amend the 'second' one in another transaction, or he
>> could be provided with an interface to do that. Nothing in the given
>> schema relates or 'pairs' the two work order numbers. There might well
>> be an application requirement that needs to be stated, for the
>> supervisor to make such corrections. In fact, given the stated
>> requirements such as they are, there would be nothing illogical in the
>> supervisor amending the 'second' one first and the 'first' one second or
>> a different supervisor amending one or the other.
>
> This is completely incoherent. To what exactly are you referring when
> you say that he could easily amend the 'first' work order in one
> transaction and amend the 'second' one in another. Are you saying
> that some constraints should be enforced by the application? That's
> what it sounds like you're saying.

Mutual, I don't know how one could conclude that one transaction to undo a mistake and another to make the correct entry have anything to do with application constraints. I wish somebody here would tell me just which of the stated constraint(s) prevent that. Received on Mon Sep 20 2010 - 23:45:57 CEST