Re: FOREIGN KEYs ... I think ...

> Now, what I want to do is add a FOREIGN KEY (again, I think) that when
> incident_summary.status is changed (either closed, or reopened), the
> associated records in incident_comments are changed to the same state ...

As the other responders mentioned, from the schema you described, it
doesn't look like you really need two separate tables. However, if you
do, foreign keys aren't what you're looking for to solve your problem.

That's not what foreign keys do. The only thing a foreign key provides is
a guarantee that if any records in B (the referencing table) still
reference a record in table A (the referenced table) then you cannot
delete that referenced record.

As far as the actual data in table B being modified to match table A,
that's something completely unrelated to foreign key integrity. That is
something I would recommend maintaining at the application level. Or, if
you're a trigger guy, do it in a trigger.

John