У меня есть таблица с четырьмя полями: 1)шифр (внешний ключ), 2)семестр, 3)сумма, 4)дата.
То есть ни одного первичного ключа нет.
Если вставить абсолютно идентичные записи, то ни одну из них нельзя удалить, при попытке удаления (удаляю из Management Studio) получаю сообщение:

Произошла ошибка при попытке удалить строку <номер удаляемой строки>.
Источник ошибки:Microsoft.VisualStudio.DataTools.
Сообщение об ошибке:Значения строки обновлены или удалены, либо не делают строку уникальной, либо они изменяют несколько строк (строк:<количество строк>).

Исправьте ошибки и попробуйте удалить снова бла-бла-бла-бла-бла-бла.

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

Но мне просто интересно, почему возникает такая ошибка? Что за механизм такой?

p.s. Я немного пояндексил, говорят, что, мол, это на стороне клиента. Однако, конкретно в этом случае, я в этом сильно сомневаюсь, и, ощущение, что ошибка возникает на стороне сервера. 

Тебе же вполне вменяемо сообщают:

Ты удаляешь одну запись, их две, СУБД не сможет решить, какая именно удаляется, Студия это понимает и посылает тебя нафиг. И она права.

добавь лучше первичный ключ.
Процедурой ты этих проблем не решишь.

1)Почему не решу?
2)Вот скажем добавил первичный ключ, когда вставляется строка с уже существующим первичным ключом, то получаю сообщение от SqlServer, что нельзя вставить строку. Я хочу выдавать пользователю мной сформированное сообщение. Как это сделать лучше всего?
Сейчас я для этого использую хранимку с проверкой IsExists() и на стороне клиента делаю MessageBox.Show().

Потому что записей - две. Они абсолютно идентичны. Различить их невозможно.


А просто анализ кода возврата, без всяких там IfExist - некошерно? слишком просто смотрится?

две сессии  одновременно пытаются вставить две одинаковые строки:

первая сессия проверила isExists, проверка выполнилась успешно
первая сессия добавила строку
вторая сессия проверила isExists, проверка выполнилась успешно
вторая сессия добавила строку
первая сессия фиксировалась
вторая сессия фиксировалась.

ты имеешь две строки.


Это сообщение отредактировал(а) Zloxa - 29.9.2009, 12:50

У меня если кто-то обращается к данным, то только он может изменять их. Все остальные блокируются.
К сожалению у меня тут через отдельно разработанный класс вызовы хранимок происходят и обрабатывать код ошибок не могу. Или не везде могу.

Мне такой подход напоминает анекдот про чукчу, который купил камаз. Все бы, говорит, хорошо, только вот собаки быстро устают. ;)

В чем, собственно, заключается проблема, которая перед Вами стоит? Я чтото перестал понимать.

Проблема такая.
Пример: Есть таблица с полями id (ключ, с автоматическим инкрементом), fullName (имя факультета), shortName(короткое имя факультета).
Есть форма на которой отображаются все факультеты. Есть кнопка "Добавить". Если человек добавляет, то надо проверить есть ли факультет с таким названием, и соответственно, либо добавить, либо сказать, что такой уже есть.
Есть кнопка "Update" вызывается другая форма, тут человек может изменить короткое название или длинное.
Тут просто так запускать IsExists() нельзя, потому-что если человек просто изменил короткое название, то IsExists() сработает и не даст ему это сделать.

Пока решил так:



То есть при апдэйте я проверяю изменял ли он полное название, если нет, то сразу можно сделать апдэйт, а если изменял,
то запустить сначала IsExists(), и если такое присутствует, то отказать.


А что, вроде нормально работает, может немножко вычурно, но всё вроде довольно логично.
То есть пока, как-бы проблема решена.

Вопрос: А что плохого, в том, чтобы запрещать клиентам одновременно вносить изменения в одно и то же место?
(Я уровень блокировки транзакции просто установлю).
Какие-то явные минусы?

Это почему? Может, он намерен изменить именно короткое название другой записи, и её длинное название он указывает. Правда это так, к слову, и допускаться не должно, ибо не та запись.
Но вообще вся твоя проблема - именно оттого, что ты не желаешь использовать для идентификации ключевое поле ID. Именно оно должно отвечать за привязку наименований к другим таблицам. И дублирование тут вовсе не помеха. Мало ли что названия совпадают? факультеты-то разные... А для регистрации изменения наименований следует предусмотреть журнал. Он мгновенно покажет виновного в бардаке. После чего к нему применяются меры отнюдь не программного характера. Тем более что изменение названия факультета - вещь весьма редкая.

Что такое уровень блокировки транзакции?

Видимо Вы имете в виду уровень изоляции транзакции.
Для того чтобы обеспечить уникальность поля, вам придется для всех модифицирующих сессий выставлять уровень изоляции Serializable и обязательно проверять IsExists в той же транзакции, в которой проводите модификацию.  В этом случае, если две сессии попытаются таки установить одинаковое значение, одна из них отвалится по дедлоку/*т.е. анализировать ответ сервера таки все равно придется*/. В виду того что поле FullName у вас не индексировано, добавившая или изменившая запись сессия, до завершения транзакции блокирует все сессии, которые пытаются отобратья по FullName, даже если отбор идет по другому значению. Когда мы выносим управление транзакциями на клиента, надо помнить, что клиент может вдруг неожиданно внештатно отвалиться. В этом случае серверу придется некоторое время держать открытыми его транзакции, блокируя при том других пользователей.

Как бы не самый ровный путь, не правда ли?
А все для чего? Для того чтобы вынести контроль целостности данных на сторону приложения.
А все от чего? От того, что Вы, по каким то не понятным мне соображениям избегаете анализа ответа сервера.

кстати, я чтото не вижу, чтобы вы открывали и фиксировали транзакцию. У Вас IsExists и AddFaculty работают в разных транзакциях? Тогда грош цена этой проверке. В то время когда сработает AddFaculty состояние базы уже может поменяться.

Задача которая перед вами стоит - тривиальна. Именно от того, мне вспоминается анекдот про чукчу. 
Решение сводится к наложению ограничения уникальности на FullName.
И на клиенте не нужны ни какие IsExists. Достаточно лишь выполнить операцию и проверить ответ сервера.
И на клиенте не нужны ни какие какие управления транзакциями.
И в результате вы получаете на много более масштабируемое решение, которое будет на несколько порядков меньше тупить, в случае прироста пользовательской нагрузки.

Это сообщение отредактировал(а) Zloxa - 30.9.2009, 13:21

Хорошо. Я посмотрю, смогу ли я обработать в catch там где надо код ответа сервера. Просто тут по коду есть проблемы...