Обработка ошибок SQL Server: исключения и контракт между клиентом и базой данных

Мы команда разработчиков баз данных SQL Server. Нашими клиентами являются смешанные пакеты веб-служб на C # / ASP.NET, C # и Java, служб Java / Unix и некоторых Excel.

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

Некоторым разработчикам наших клиентов не нравятся исключения SQL. Они понимают их на своих языках, но не понимают, что SQL ограничен в том, как мы можем сообщать о проблемах.

Я имею в виду не просто ошибки SQL, такие как попытка вставить «bob» в столбец int.

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

У них нет никаких конкретных альтернатив: они упоминали, что мы должны выводить параметры, но мы предполагаем, что исключение означает «обработка остановлена / откатана».

Как люди здесь обрабатывают контракт между клиентом и базой данных? Или вообще, или где есть разделение между обезьянами кода БД и клиента.

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

мы используем SQL Server 2005 TRY / CATCH исключительномы регистрируем все ошибки уже после отката в таблицу исключениймы обеспокоены тем, что некоторые из наших клиентов не будут проверять выходные параметры и будут считать, что все в порядке. Нам нужны ошибки, отмеченные для поддержки, чтобы посмотреть.все является исключением ... ожидается, что клиенты будут выполнять некоторый анализ сообщений, чтобы отделить информацию от ошибок. Чтобы отделить наши исключения от ядра БД и ошибок вызовов, они должны использовать номер ошибки (у нас, конечно, 50 000)

Ответы на вопрос(4)

Ваш ответ на вопрос