Базу данных MSSQL рисую в дизайнере VS2010, использую LINQ.
При создании связи по внешнему ключу не понятно как задать правило на удаление/изменение родительской записи.
Пробовал вручную редактировать dbml файл, добавляя в тег <Association/> атрибуты:
Редактирование отражается на файле, содержащем сущностные классы и DataContext, однако при вызове метода DataContext.CreateDatabase() сгенерированные запросы не содержат директив Пройдя обратным путем, создав на сервере БД, содержащую таблицу с соответствующими связями, при помощи того же дизайнера и ServerExplorer'а в VS2010 получил dbml файл, никаких отличий от того, что было сделано вручную, найти не смог.

Подскажите, пожалуйста,
1)есть ли способ задать правила на удаление/изменение записи кроме как через dbml файл?
2)чего не хватает в описанной схеме, почему запрос, генерируемый DataContext.CreateDatabase(), не содержит указанных директив?

Почему нет? Отчего не может потребоваться удалить строку таблицы (или, скажем, потеряться необходимость хранения строки) даже независимо от того имеется ли на неё ссылка по внешнему ключу?

И все же меня не так поняли, я, видимо, некорректно выразился...родителя не требуется убивать при удалении потомка...требуется при необходимости удаления родителя каскадно удалять всех потомков, самый тривиальный вариант использования каскадного удаления записей, не более...
Проблема в том, что БД генерится при помощи Linq2SQL и ON DELETE CASCADE не попадает в генерируемые SQL запросы, хотя в dbml файле соответствующие атрибуты выставлены

HorghПри создании связи по внешнему ключу не понятно как задать правило на удаление/изменение родительской записи
Имелось в виду правило, которое должно выполняться при удалении\изменении родительской записи (не потомков), а следовательно - определяет, что должно происходить с потомками при удалении этого самого родителя.
Ежу ж ведь понятно, что если дочернюю запись удаляют, родителю вообще по барабану...
buredСуть каскадности в удалении осиротевших детей
...в самую точку, это и нужно, но не получается!
Все должно при вызове CreateDatabase автоматически создаваться, стало быть я не верно dbml файл составил, а что не верно абсолютно не ясно...атрибуты DeleteRule и DeleteOnNull ставил и потомку, и родителю, и одновременно обоим...один фиг LINQ генерит SQL-запрос, в котором нет ON DELETE CASCADE...хотя в файл *.designer.cs эти атрибуты проставляются

О какой схеме Вы говорите?
Схема и генерируется на основе dbml файла...Любое изменение на графической форме схемы БД фактически редактируют dbml-файл...графический дизайнер ни что иное, как средство редактирования оного, да и служит для отражение структуры БД на сущностные файлы, которые фактически также генерируются на основе dbml файла...
Если речь шла о схеме БД в дизайнере, то мне не удалось найти вообще никаких средств задания подобных правил, только напрямую отредактировать dbml файл, однако ожидаемого результата не оказалось.
Вы не могли бы подсказать, где можно эти правила задавать?

Огромное спасибо за ссылку!!!!!
Все ж мало я гуглю)))
Ща изучим!

Безусловно интересные соображения по поводу, что в общем случае каскадное удаление может оказаться слишком сложным для реализации, поэтому такая фитча и отсутствует...
Frans BoumaI'm not sure why Linq to Sql gives up here, but in general in o/r mappers: cascading deletes aren't really going to work. Sure there are cases where they do work, but in general they don't because with 2 or more paths from entity E1 to entity E2 in the model, it's already not possible to have E2 instances deleted when E1 is deleted in most cases. SqlServer for example will also give up in some situations in this case.
Как я понимаю следующее:
авторLINQ to SQL does not provide a cascade delete feature. Your database must be setup to do this on its own.
1)LINQ to SQL не предоставляет средства каскадного удаления. Ваша СУБД должна быть настроена на каскадное удаление вручную.
авторThe 'DeleteRule' property in the mapping is only used during a CreateDatabase call to tell the database to do cascade delete for this relationship, and to warn LINQ to SQL that cascading could happen.
2)Свойство 'DeleteRule' используется только при выполнении метода CreateDatabase, чтобы сообщить СУБД о том, что по этой связи необходимо выполнять каскадное удаление, а также предупредить Linq2SQL об этом.

Не понятно, как СУБД уведомляется, если в результате CreateDatabase CASCADE на этой связи не выставляется, а остается NO ACTION

P.S.: по всей видимости, проще положится на себя и удалить все имеющиеся дочерние строки вручную...хотя, скажем если Linq этого и не умеет, то из БД при помощи, например, хранимой процедуры можно вызвать автоматическое каскадное удаление, поэтому флаг CASCADE должен как-то выставляться)))

bured, я Вас все равно не понимаю...
Понятно, что в самой СУБД на нужной связи должно CASCADE стоять, но важно, чтобы это не вручную делать, а чтобы при выполнении DataContext.CreateDatabase() данный флаг проставлялся...я ещё понимаю, если б в LINQ вообще это отсутствовало, но ведь есть, а не работает...
buredЧтобы накатить апдейт на внешний ключ, его надо грохнуть и создать с нужной опцией.
БД, в том числе и связи по внешнему ключу генерируются при помощи DataContext.CreateDatabase() на основе имеющегося dbml файла, все запросы SQL генерируются LINQ автоматически...и уж если в dbml файле указано, что удаление должно быть каскадным, то логично ожидать, что сгенерированный LINQ запрос будет содержать что-то в подобное:
Но вот только фраза "ON DELETE CASCADE" почему то отсутствует...эта самая "нужная опция" должна автоматически генерится!
Вот и вопрос: должна ли??? Или все-таки LINQ этого ни хрена не поддерживает, поэтому при генерации БД при помощи CreateDatabase нужно вручную в БД заливать не только тригеры, хранимые и пользовательские процедуры, но и при необходимости правила удаления\изменения по связям....

Направление какое:
1)БД генерится при помощи LINQ
2)или dbml схема генерится на основе БД (при помощи SQLMetal или дизайнера VS)
???

Огромное спасибо!!!!!!!!!!!
Интересно, что это сообщение от 2008 года...сегодня framework 4.0 уже, а до сих пор ничего не исправлено..., хотя, может, и есть какие-нибудь исправления..

Я замечание по ссылке прочитал, там ж написано, что файл designer.cs перегенеривается каждый раз при построении проекта, то есть его править каждый раз придется..?

Ещё раз спасибо!))
Да уж атрибут класса не переопределишь..partial класс штука удобная, но не на столько)) Методы частичными они сделали, а вот атрибуты..))
Скорее всего? так же остановимся на варианте, где каскадное удаление происходит минуя L2S, да и генерировать соответствующие правила в БД тоже придется дополнительными запросами помимо CreateDatabase....

С другой стороны, к своему позору, EntityFramework нужно тоже только изучать, а задачку уже взялись решать на L2S, и времени на изучение ещё чего-то нового уже нету. Прочитав вот эту статейку http://habrahabr.ru/linker/go/37390/, создалось впечатление, что EntityFramework скорее подходит для нашего подхода в разделении уровней доступа к данным и сущностей предметной области. Однако ж пока L2S...))