SQL Serverは、カスケードパスの単純なカウントを行い、サイクルが実際に存在するかどうかを判断しようとするのではなく、最悪の事態を想定し、参照アクション（CASCADE）の作成を拒否します。参照アクションなしで制約を作成できます。デザインを変更できない場合（または変更すると問題が発生する場合）、最後の手段としてトリガーの使用を検討する必要があります。
カスケードパスを解決するFWIWは複雑な問題です。他のSQL製品は単に問題を無視し、サイクルを作成できるようにします。その場合、おそらく設計者の無知のために、最後に値を上書きするかどうかを確認するための競争になります（たとえば、ACE / Jetがこれを行います）。一部のSQL製品が単純なケースを解決しようとすることを理解しています。事実は残っていますが、SQL Serverは試行すらしません。複数のパスを禁止することで非常に安全に機能し、少なくともそのように指示します。
Microsoft自身が、FK制約の代わりにトリガーを使用することを推奨しています。