Заранее извиняюсь, если подобный вопрос уже задавался, просто я его пока не нашел

Делаю следующие шаги
1) в PD создаю таблицу Table1, в ней колонку created, в ней значение по умолчанию getdate()
2) генерирую полученную таблицу в базу - сгенерированный скрипт:

create table Table1 (created datetime null default getdate())
go

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

И хрен бы сним, но если проделать апдейт модели из базы, то ограничение уже появится в PD.

И вот тут возникает проблема, в следующий раз при апдейте базы из модели, пересоздавая таблицу(например при вешании Primary key на тот же столбец created) уже будет сгенерирован скрипт

create table dbo.Table1 (created datetime not null constraint DF__Table1__created__503BEA1C default getdate(), constraint PK_TABLE1 primary key (created)
)
on "PRIMARY"
go

Т.е. будет создаваться ограничение уже созданное в базе!! и появляется ошибка!

У меня в базе множество таблиц и множество ограничений, как избежать подобной ошибки! Может можно как-нибудь вообще отключить в PD репликацию ограничений из базы? Только вот я пока не нашел где это сделать.

P.S. сорри за такой объемный вопрос, просто хотел как можно понятнее объяснить ситуацию

Роман Дынникblest
Т.е. будет создаваться ограничение уже созданное в базе!! и появляется ошибка!

В свойствах столбца created, есть закладка microsoft, там - поле default constraint name.
установите жёсткое имя констрейнта, тогда оно не будет автоматически генериться сервером. а будет браться то, которое вы задали.

Понятно, что жестко там можно забить все что угодно, только это не выход из проблемы. Если назвать ограничение по умолчанию x1, то например при добавлении primary key в таблицу будет сгенерирован такой скрипт:

execute sp_rename Table1, tmp_Table1
go

create table dbo.Table1 (
created datetime not null constraint x1 default getdate(),
constraint PK_TABLE1 primary key (created)
)
on "PRIMARY"
go

Т.е. при пересоздании таблицы он будет опять же создавать ограничение с именем уже созданным!

Роман Дынникblest
Понятно, что жестко там можно забить все что угодно, только это не выход из проблемы. Если назвать ограничение по умолчанию x1, то например при добавлении primary key в таблицу будет сгенерирован такой скрипт:

created datetime not null constraint x1 default getdate(),
constraint PK_TABLE1 primary key (created)
)
on "PRIMARY"
go

Т.е. при пересоздании таблицы он будет опять же создавать ограничение с именем уже созданным!
с каким именем уже созданным? x1 или PK_TABLE1?
Нужен alter скрипт и чтобы он учитывал при сравнении с БД, что ограничение default getdate() уже существует? Тогда следует задать в default constraint name имя, которое лежит в базе или сгенерить скрипт на удаление этого default constraint и далее придерживаться жестких наименований в констрейнтах во избежании подобных ситуаций.

Жирный я выделил то, что было важно. Т.е. в модели было ограничение x1 и в базе было ограничение x1 и при пересоздании таблицы он его же создавал.

Вопрос как раз вот в том и есть: Как сгенерить скрипт на удаление этого default constraint ?

Или если быть точнее нужно вот это:
Нужен alter скрипт и чтобы он учитывал при сравнении с БД, что ограничение default getdate() уже существует!

Роман Дынникblest,
в TSQL нет конструкции позволяющей добавить ограничение для конкретного столбца таблицы вне определения таблицы. Т.е. нет подобного псевдо-синтаксиса:
alter table [tablename]
aleter column [columnname]
add constarint [constname] ...
Отсюда и проблемы.
Нужно удалять предыдущий столбец и создавать новый с ограничением.
Отдельно ограничение столбцу на TSQL добавить нельзя.

Любой TSQL код добавляемый при генерации можно написать на закладке Script.
Например, там могло бы быть:
alter table [tablename] drop constraint [constname]

Ну понятно, что alter table должно присутствовать. Но вот, например, SSMS при добавлении удалении поля по умолчанию генерирует следующие скрипты:

ALTER TABLE dbo.Table1 ADD CONSTRAINT DF_Table1_created DEFAULT (getdate()) FOR created

ALTER TABLE dbo.Table1 DROP CONSTRAINT DF_Table1_created

В идеале хотелось бы, чтобы и PD генерировал такие же скрипты, а не пересоздавал таблицы вместо этого. Но впринципе можно было обойтись, чтобы он при импорте из базы во вкладку Microsoft ничего не добавлял, только я не знаю можно ли это настроить

Роман Дынникblest,
рекомендую не использовать обновление БД напрямую из PD, а использовать патчи, которые проверяются глазами и отчасти дописываются руками, а то что генерит PD при modify database можно использовать только как черновой вариант для патча. патчи складывайте куда нибудь в svn или vss или в том же PD в какие-нибудь artifacts.

Ну я впринципе понял уже, что напрямую без проверки из PD апдейтить базу неразумно. А что за пачти такие можно использовать? Я думал достаточно проверки и выполнения измененного мной скрипта, сгенерированного PD.

Роман ДынникblestНу я впринципе понял уже, что напрямую без проверки из PD апдейтить базу неразумно. А что за пачти такие можно использовать? Я думал достаточно проверки и выполнения измененного мной скрипта, сгенерированного PD.
скрипты(патчи) необходимо систематизированно хранить.
нужно это по следующим причинам:
- если база версии XX поднимается из бекапа, а для корректной работы приложения требуется версия базы YY, то накатываются скрипты от XX до YY.
- в Unit-тестах и различных этапах Continues Integration (CI), чтобы привести базу в первоначальное состояние перед тестами, она либо поднимается из бекапа (так иногда удобней), либо создается из скрипта + патчи до версии YY.

p/s/
соответственно, для автоматизации установки патчей, база должна иметь таблицу, где хранится номер версии.

А заполнять эту таблицу вручную что ли? Так может проще генерируемые скрипты просто сохранять в отдельную папку и сортировать по дате создания? Как раз можно после восстановления бекапа накатить все скрипты, у которых дата создания больше, чем дата создания бекапа.
Вот кстати вопрос: можно ли настроить, чтобы при апдейте базы из модели значение в File Name во вкладке General автоматически генерировалось? Например было стандартное название + айдишник(или дата)