Question on DRI in Yukon

SQL/Server 2000 has the following restriction (excerpted from BOL):
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.
The restriction does not exist in Oracle (for example) and I have
encountered many real-life DB design situations where the ability to have
more than one path to a table would be very useful. For example, an m:n
linking table relating two tables that have a common parent table.
Is this restriction lifted in SQL/Server 2005?
Thanks for any input.
Mike A.
Yukon is still in beta under NDA. There should be a public beta released
very soon...
Brian
"Michael Abraham" <mabraham@.decisionarc.com> wrote in message
news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> SQL/Server 2000 has the following restriction (excerpted from BOL):
> 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.
> The restriction does not exist in Oracle (for example) and I have
> encountered many real-life DB design situations where the ability to have
> more than one path to a table would be very useful. For example, an m:n
> linking table relating two tables that have a common parent table.
> Is this restriction lifted in SQL/Server 2005?
> Thanks for any input.
> Mike A.
>
|||Thanks for the speedy response. I have seen a number of articles on T-SQL
enhancements in Yukon, but none of them were at a sufficiently detailed
level to address my question. I'll just wait (impatiently) for the public
beta.
Mike A.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:e3AxJ7bQEHA.3124@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> Yukon is still in beta under NDA. There should be a public beta released
> very soon...
> --
> Brian
> "Michael Abraham" <mabraham@.decisionarc.com> wrote in message
> news:epx2S4bQEHA.624@.TK2MSFTNGP11.phx.gbl...
> referential
have
>