James,

Apparently updating a join logical does not seem that absurd to many
others. IBM does not usually pour time and talent into something that no
one wants.

Let's dissect how a instead of trigger might work. It could analyze what
fields you were really trying to update and do so. Now, trying to write a
generic utility might be rather complex. Not only would you have to get
the update proposed to the trigger, (which I haven't look at the
parameters of the trigger to see how hard that would be - other triggers
are a snap), but then you'd also have to retrieve the layout of the join
logical. Then an intelligent decision could be made as to whether or not
that update was feasible. Like, if the person defined the view as a left
outer join, do you refuse the update if the secondary row is not there?
Or, if they used either ifnull or coalesce do you update it, but don't
update it if they didn't and null values are returned? Like

create view merged as (
select old.key, old.data as olddata,
new.data as newdata
from old left outer join new using (key)

update merged set olddata=newdata

should that act differently than

create view merged as (
select old.key, old.data as olddata,
ifnull(new.data,' ') as newdata
from old left outer join new using (key)

update merged set olddata=newdata

Then, what if the update was:

update merged set olddata=ifnull(newdata,' ')


Rob Berendt

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2019 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].