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

P.S. Я, глядя на код, рекомендовал бы обратить внимание на следующие вещи:
1. Убрать тексты с RAISERROR и зарегистрировать ошибки через CREATE MESSAGE c нужными параметрами в тексте.
2. В CASE добавить еще ELSE и генерить ошибку "Неизвестная операция" - дополнительная проверка работы клиентской части.
3. Очень задуматься над тем, что GUID в качестве ключей это ужасно неэффективная вещь, которая станет тормозить уже даже на нескольких тысячах записей и пока не поздно перевести все на GLOBAL AUTOINCREMENT. Обьясняю - индексы по GUID строятся ужасно в силу его природы, я лично имею реальный опыт, где в принципе то небольшая базка на GUID-ах просто тормозила, перевели на инкременты и база сейчас уже ого го и никаких тормозов.

Евгений_СТ1. Если я правильно понял смысл замены RAISERROR на CREATE MESSAGE, то строка MESSAGE создаётся как глобальный объект и может принимать параметры %1. То есть замена делается просто ради экономии и уменьшения скрипта?
Это позволяет сделать централизованное хранение ошибок, если нужно, с многоязыковой поддержкой. Не нужно текст одной и той же ошибки клонировать по скриптам, легко изменять текст ошибки, и т.д.

Евгений_СТНо тут возникает другая проблема. Если у меня в таблице есть два или больше поля с условиями NOT NULL и <>'', то при добавлении записи возникнет ошибка - а как тогда я определю, на каком именно поле нарушено ограничение целостности? Это нужно для того, чтобы на клиенте установить фокус на ошибочном поле ввода.
Вот здесь как раз самое лучшее не извращаться над сервером, а проверять такие условия прямо на клиенте, ДО посылки сохранения изменений на сервере. Тогда и будет легко определить ошибку, и фокус поставить куда нужно и главное не напрягать сервер и сеть тем, что можно быстро локально проверить.

Евгений_СТ3. ГУИД'ы использовались для обеспечения репликации. GLOBAL AUTOINCREMENT - судя по БОЛу, тоже предназначен для репликации. Но ведь при добавлении записей на основной и удалённой БД записи будут всё равно иметь одинаковые значения ключа? Или это разрешается только через указание диапазона ключевых значений для каждой удалённой БД?
Упс, срочно читать BOL про Global Autoincrement :) В том то и дело, что он именно и сделан как раз для репликаций, то есть когда он указывается на таблицу, ему дается диапазон действия (например ставим 1000000). Для каждой БД в репликации выставляем в опции Global_Database_id ее номер. Например для консолидированной ставим 0. Значит разрез инкремента id в таблице будет от 1 до 1000000. Ставим для удаленной 1, значит она работает в разрезе от 1000001 до 2000000, и т.д. Причем когда на консолидированную или удаленную БД вставляются записи из других БД, то они не сбивают последнее показание счетчика, так как не попадают в диапазон его действия на текущей БД. Вывод - однозначно отказываться от GUID, иначе проблем поимеете на свою голову просто огромное кол-во и со скоростью и с сопровождением и с размером БД и еще страшно представить каких.

Рыжий КотASCRUS, так какие проблемы могут быть, если первичный ключ фиксированной длины будет длиннее на 30 байт?
Ну во первых, чем короче размер поля таблицы, тем компактнее индекс. Надо думать, на PK будут ссылаться FK, которые могут еще и в составные PK входить. Там 30 байт, здесь 30 байт и схлопотали compressed или hash-индекс. Далее - чем меньше ширина записи, тем больше их поместиться на страницу, а значит и осядет в кэше. Далее - GUID генериться без какой либо последовательности, а значит при вставках новых записей на индексах это будет выглядеть не самым оптимальным образом. Снижается скорость вставки и поиска по индексам. Поэтому лично мое мнение - GUID может быть нужен действительно для присвоения уникального в мировых масштабах идентификатора, но плохой кандидат на роль замены инкрементов как синтетический ключ, хотя конечно выглядит удобным с точки зрения репликаций.

Гм, я привел пример из личного опыта - была рабочая БД с неплохим обьемом таблиц и данных, завязанная на GUID. Перевели GUID на инкременты, существенно сократился прирост файлов БД и даже на глаз увеличилась скорость выполнения долгоиграющих запросов, особенно по аналитике. Отсюда и мои личные выводы.

Рыжий Кота примерный размер БД в МБ не подскажете? и кол-во строк в самой большой табличке?
Давно это было :) Тогда БД помнится где то весила 15 гб, в наиболее тяжелых таблицах было в среднем 1-5 миллионов записей. Ключи были сделаны не как char, а как нативный домен (то есть фактически как binary(16)).

Ну во первых тип unsigned integer дает уже не 2, а 4 миллиарда и думаю с инкрементом никто не расстроится, что все значения беззнаковые.
Во вторых основные средства разработки клиентского ПО, поддерживают таки unsigned bigint.
В третьих даже если мы примем такие расчеты, то стоит еще учитывать, что в ASA есть событие переполнения счетчика и возможность изменить на новый свободный глобальный код БД - так что подошел разрез в какой либо таблице к концу, вызывалось событие, считали максимальный номер БД по своей табличке, участвующей в репликации, поменяли свой узел на новый номер и установили его в GLOBALDATABASE_ID. Все - счетчики БД едут в новых разрезах, новые записи без проблем вставляются.

Так что - абсолютно не вижу проблем с глобальными инкрементами.