Correct, if you have both a trigger and a FK, the trigger will not fire if you get a FK violation. In this case, you would create only a trigger.

Roman


>Ok,
>
>But, if you change a PK, that is related to other tables, isn't the trigger fired after the update there by violating the FK rules on the child table causing the update to fail? I know you use to have to use triggers for cascades so there must be some way around this.
>
>Thanks for the info,
>BOb
>
>
>>The ANSI SQL-92 standard defines a rule that you can't have two paths to the same row in the referencing table resulting from an action in the parent table.
>>
>>This is from BOL:
>>
>>The series of cascading referential actions triggered by a single DELETE or UPDATE must form a tree containing no circular references. No table can appear more than once in the list of all cascading referential actions that result from the DELETE or UPDATE. The tree of cascading referential actions must not have more than one path to any given table. Any branch of the tree is terminated when it encounters a table for which NO ACTION has been specified or is the default.
>>
>>Looks like you'll have to use triggers, at least on the second column.
>>
>>Roman
>>
>>
>>>Can anyone point to the reason you can't do a cascade delete when there are two FK's to the same field in a table?
>>>
>>>For example...
>>>
>>>city has a pk of city_pk
>>>
>>>
>>>And employee has two fk,s
>>>
>>>homecityfk and workcityfk ... both relate to city_pk. I can create the FK constraints, but when I tell it to cascade key updates to more than one FK I am told it 'might be cylic' which it doesn't seem like it will.
>>>
>>>does anyone know a work around (other than a trigger) for this situation, or can point me to a BOL topic on why you can't do this?
>>>
>>>Thanks,
>>>BOb