анализ ошибок SQLException в приложении ASP.NET (MVC)?

Question

Хотя проверка может предотвратить большинство ошибок SQL, существуют ситуации, которые просто невозможно предотвратить. Я могу думать о двух из них: уникальность некоторого столбца и неправильный внешний ключ: проверка не может быть эффективной, так как объект может быть создан или удален другими сторонами только после проверки и до вставки БД. Таким образом, есть (как минимум) две SQL ошибки, которые должны привести к сообщению о недопустимом вводе пользователем.

SQLException имеет свойство Number для типа ошибки, но я не знаю, как определить, какой столбец дублирован или какой внешний ключ неправильный, не пытаясь проанализировать фактический текст сообщения об ошибке, что происходит с быть локализованным.

Можно ли как-то идентифицировать ошибочный столбец, кроме анализа сообщения об ошибке (что означает, по крайней мере, строго выбрать язык для SQL Server и всегда использовать его)?

редактирование:

Я должен упомянуть, что я из RubyOnRails, где такой подход: давайте притворимся, что db не существует: никаких ограничений, никаких внешних ключей с применением db и т. Д. По мере приближения к ASP.NET MVC, я бы как избавиться от уклонов рельсов, и принять тот факт, что БД действительно существует.

Answer 1

Вы уверены, что эти две ситуации абсолютно невозможно предотвратить?

Вы можете избежать уникальных исключений SQL-исключений при вставке, используя столбец первичного ключа Identity (сгенерированный базой данных). SQL Server гарантирует, что значение является уникальным.

То же самое касается вставки связанных строк в таблицы, связанные внешним ключом. Сначала вставьте строку в каждую ссылочную таблицу, а затем вставьте строку в основную таблицу. Используйте IDENTITY_INSERT, чтобы получить значение каждого автоматически сгенерированного первичного ключа и использовать его в качестве внешнего ключа в основной таблице.

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