+2  A: 

You can't cascade delete through two branches, it is a limitation of the tool. But cascade delete is generally a bad thing to do to your poor innocent database anyway. Delete from the bottom table and move up. That way if you have 100000000000 records at the bottom you can do them in batches for performance. Cascade delete can cause performance problems.

HLGEM
I guess there won't be 100 Grecords in SSCE. By not defining the constraints in the database, you force the application to know where to cascade. As the database evolves, it might be prone to errors (leaving inconsistencies in the database) as more references are added.
pascal
+1  A: 

Assuming SSCE does not allow cascade delete along two paths, you could remove the cascade delete for UnavailableItem.StandId.

At least, it will still cascade when a Vendor, or an Item is deleted.

And if UnavailableItem still contains rows for deleted Stands, at least they could be filtered out when joining UnavailableItem with Stand, when building refilling orders...

pascal
I accepted HLGEM's answer as it did answer my question (that it's a limitation of the tool), but +1 and thank you for providing suggested workaround of the limitation!
Scott