2Denniz, 2GreenSunrise
Проблемы связей между объектами не существует!
Порядок создания объектов примерно следующий - возможно не полный, желающие могут расширить
1) types
2) defaults
3) bind defaults to types
4) tables
5) views
6) references keys
7) triggers
procedures
9) load data into tables

пытаться создавать деревья по sysdepends я бы не советовал
т.к. связи между таблицами там не отражаются - это делается в sysreferences: fkeyid, rkeyid соответственно id,
а кроме того таблица похоже оставлена в версиях после седьмой только для совместимости и реальной картины зависимостей объектов в БД вообще не отражает.
посмотреть на это очень просто -
выполняем скрипт:
CREATE TABLE tab1 (a int)
GO
CREATE PROC proc1 AS SELECT * FROM tab1
и в sysdepends попадет зависимость процедуры proc1 от таблицы tab1
а если так:
CREATE PROC proc2 AS SELECT * FROM tab2
GO
CREATE TABLE tab2 (a int)
то в sysdepends не попадет зависимость процедуры proc2 от таблицы tab2
вот такие пироги ;(


анализировать sysreferences на предмет связей между таблицами я тоже не советую,
потому что это могут быть не "деревья" а "кольца"
пример:


CREATE TABLE a( a int not null primary key,
b int null)
GO
CREATE TABLE b( b int not null primary key,
a int null)
GO
ALTER TABLE a
ADD CONSTRAINT FK_a_b FOREIGN KEY (b) REFERENCES b(b)
GO
ALTER TABLE b
ADD CONSTRAINT FK_b_a FOREIGN KEY (a) REFERENCES a(a)
GO

select * from sysreferences where fkeyid in (select id from sysobjects where name in ('a', 'b'))

и все равно придется создавать ссылки между таблицами отдельно от самих таблиц
хотя задача анализа "деревьев" сама по себе очень интересна, и только ради либви к искусству стоит ею хотябы раз в жизни позаниматься ))

2Pandre
посыпаю голову пеплом, действительно данные надо лить до ссылок
и с представлениями ты меня уел
действительно их надо заливать в строго определенном порядке... но это очень грустно т.к.
как я уже говорил sysdepends верить нельзя:

create view view1 as select 1 as num
GO
create view view2 as select * from view1
GO
drop view view1
GO
create view view1 as select 'text' as text

в sysdepends записи нет
таким образом остается только идти по syscomments, а это тоже не всегда возможно
только если коды не криптованы
т.о. с view задача в общем виде не решается must die!!!

2GreenSunrise
Извини, но ты не прав
речь шла изначально про 7-ку поэтому функции не рассматривались, а создавать их надо просто до всех таблиц...
проблем с созданием типов объектов вперемешку (одна таблица, одна процедура, две функции, другая таблица) нет,
как ты сам заметил '...приведет только к warning'у "нельзя добавить в sysdepends",...'
но вот как раз c функциями в качестве полей таблиц так не прокатит ;(

а вот со связями между view как замечено Pandre действительно проблема... особенно если это view на linked сервера

2Pandre
Идея про прогон скриптов несколько раз мне понравилась
У меня в это время тоже решение вызрело - в конце концов заливку объектов можно (и нужно в нашем случае) делать через exec и анализировать результат, если обломилось, повторить позже (только не весь скрипт, а только ту часть что обломилать) и так до полной победы

2GreenSunrise
Если честно я уже не закладываюсь на sysdepends в силу описанных мною ранее причин:
в процессе экслуатации системы кто-нибудь "очень умный" может дробнуть и вновь создать любой объект и прощай sysdepends а с такими "умными" нам постоянно приходится сталкиваться,
поэтому я не ситаю что при заливке данных следует содержать sysdepends в порядке.
С другой стороны я не претендую на всезнание
Про хинт SCHEMABINDING услышал от тебя первый раз - это может сильно поколебать мою позицию по данному вопросу ;(
мой books on-line сказал что оно появилось только в 2000 - а я все больше пока 7-й занимаюсь ;(

про заливку данных все просто, если ты ее делаешь после построения foreign keys то выполнять ее надо в строго даданной последовательности - сначала родитель потом дети - а в общем случае это не возможно (см. мой пример выше про циклические завязки между таблицами) хотя конечно никто не мешает тебе создавать все ссылки, потом отключать их у всех объектов, заливать все данные, потом опять их включать (лично я так и делал иногда) но при этом, если не ошибаюсь, при включении их обратно проверки целостности БД сервер не производит ;( надо самому об этом позаботиться

Вопрос для Гуру!

Можно ли считать объективной информацию из таблицы sysdepends?

Как видно из текста системных процедур sp_MSdependencies и sp_depends эта таблица там активно используется, но при этом "неправильный" порядок создания связанных объектов в БД не создает записей в таблице sysdepends (см. мои примеры выше в этом топике).
Есть ли другой спрособ, кроме использования sysdepends выяснить иерархию объектов в БД?