Дано MS SQL, в котором заводятся шаблоны сообщений на разных языках с помощью sp_addmessage.

Проблема в том, что клиент забекапил БД, провел апгрейд SQL сервера, разбекапил БД и все, сообщения все потерялись.
Задолбало. Можно эти шаблоны спустить на уровень БД или чем нибудь их заменить?

Здравствуйте, kgrach, Вы писали:

K>Дано MS SQL, в котором заводятся шаблоны сообщений на разных языках с помощью sp_addmessage.

K>Проблема в том, что клиент забекапил БД, провел апгрейд SQL сервера, разбекапил БД и все, сообщения все потерялись.
Что, и скриптов не осталось?

K>Задолбало. Можно эти шаблоны спустить на уровень БД или чем нибудь их заменить?
Можно транслировать их в приложении. Написать кучу кода для этого, натыкать обработчиков во всех возможных местах.
Но стоит ли?

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, kgrach, Вы писали:

K>>Дано MS SQL, в котором заводятся шаблоны сообщений на разных языках с помощью sp_addmessage.

K>>Проблема в том, что клиент забекапил БД, провел апгрейд SQL сервера, разбекапил БД и все, сообщения все потерялись.
W>Что, и скриптов не осталось?

Все скрипты на месте.

K>>Задолбало. Можно эти шаблоны спустить на уровень БД или чем нибудь их заменить?
W>Можно транслировать их в приложении. Написать кучу кода для этого, натыкать обработчиков во всех возможных местах.
W>Но стоит ли?

Ну вот и хочется всего лишь перетащить их на уровень БД.

Здравствуйте, kgrach, Вы писали:

K>Дано MS SQL, в котором заводятся шаблоны сообщений на разных языках с помощью sp_addmessage.
.

K>Проблема в том, что клиент забекапил БД, провел апгрейд SQL сервера, разбекапил БД и все, сообщения все потерялись.
K>Задолбало. Можно эти шаблоны спустить на уровень БД или чем нибудь их заменить?


Эти сообщения хранятся в master db. Нужно один раз написать скрипт экспорта-импорта этих сообщений, чтобы после апгрейда просто его запустить.
Альтернативно, можно просто создать табличку в своей базе с такой же структурой, все туда перенести, и потом код просто будет читать оттуда. Я не совсем понимаю, в чем сложность?

Здравствуйте, kgrach, Вы писали:

K>Проблема в том, что клиент забекапил БД, провел апгрейд SQL сервера, разбекапил БД и все, сообщения все потерялись.
K>Задолбало. Можно эти шаблоны спустить на уровень БД или чем нибудь их заменить?

Вариантов у вас немного, если оставаться в рамках T-SQL.

1. Изменить обслуживание БД, т.е. создать справочную таблицу, которая содержит все сообщения. В процедуру восстановления БД добавить пункт вызова ХП (запроса), которая создает по справочной таблице все сообщения на сервере.

2. Либо велосипедировать, если у вас SQL Server 2012+.
Например, инструкция THROW позволяет генерировать исключения с любым кодом от 50000 до 2147483647, без предварительного добавления записей в sys.messages Однако есть пара ограничений — первое, уровень серьезности ошибки всегда 16, второе она не поддерживает многоязыковость и стиль формата printf. Для решения второй проблемы вам необходимо будет создать всё ту же справочную таблицу со всеми языками и кодами в БД. И при генерации ошибки использовать FORMATMESSAGE, завернув это как-то красиво в функцию, например:

declare @err int = 55555
declare @msg nvarchar(2048)

select @msg = formatmessage(text, 'ПРОВЕРКА')
from sys.messages sm
join sys.syslanguages l on l.langid = @@langid and l.msglangid = sm.language_id
where sm.message_id = 21665;

throw @err, @msg, 1;

В запросе с sys.messages и sys.syslanguages вы используете свою справочную таблицу в БД, я использовал их только для демонстрации.

Здравствуйте, Milena, Вы писали:

M>Здравствуйте, kgrach, Вы писали:

M>Эти сообщения хранятся в master db. Нужно один раз написать скрипт экспорта-импорта этих сообщений, чтобы после апгрейда просто его запустить.
M>Альтернативно, можно просто создать табличку в своей базе с такой же структурой, все туда перенести, и потом код просто будет читать оттуда. Я не совсем понимаю, в чем сложность?

Смотрите, есть триггеры на таблицах, которые при удалении записи проверяют, что на нее не ссылаются записи из других таблиц. (Дизайн такой)

Если в процессе проверки выясняется, что ссылается имеется, триггер вызывает
RAISERROR с кодом сообщения (которые более 50000) и аргументами.

Далее запросы к БД делает прикладное ПО.
ПО при обработке ошибок смотрит, если код ошибки больше 50000, то это сообщение специально отправляется пользователю, чтобы он сразу понимал, в чем дело.
Если код ошибки меньше 50000 то отправляется маловразумительное сообщение "Ошибка".

Из-за переездов БД на другие экземпляры SQL сервера эти сообщения теряются.
В этом случае при удалении записи, на которую есть ссылка, код ошибки меняется на 18 тыс че-то там и клиент получает "Ошибка" и не понимает почему.
И чисто клиентская проблема превращается проблему поддержки, разработчиков
Начинается заказ логов их анализ, отправка скриптов с этими сообщениями.
И это не разовая ситуация, а регулярно повторяющаяся.

Хочется, получить функциональность RAISERROR, но только, чтобы сообщения жили в БД.

Здравствуйте, Olaf, Вы писали:

O>Здравствуйте, kgrach, Вы писали:

K>>Проблема в том, что клиент забекапил БД, провел апгрейд SQL сервера, разбекапил БД и все, сообщения все потерялись.
K>>Задолбало. Можно эти шаблоны спустить на уровень БД или чем нибудь их заменить?

O>Вариантов у вас немного, если оставаться в рамках T-SQL.

O>1. Изменить обслуживание БД, т.е. создать справочную таблицу, которая содержит все сообщения. В процедуру восстановления БД добавить пункт вызова ХП (запроса), которая создает по справочной таблице все сообщения на сервере.

Нет такого регламента. Каждый клиент, как умеет так и разворачивает БД и как правило нас даже об этом не уведомляют.
Само ПО тоже не в состоянии накатить эти сообщения т.к. для sp_addmessage требуются админские роли у учетной записи, а некоторые клиенты принципиально отказываются выдавать такие роли учетным записям.
ПО конечно может проверить, что сообщения отсутствуют и проинформировать, но это все полумеры.

А может быть есть какой-то механизм на SQL Server, который автоматом запускается после рестора бекапа и позволяет выполнить клиентский SQL код?


O>2. Либо велосипедировать, если у вас SQL Server 2012+.
O>Например, инструкция THROW позволяет генерировать исключения с любым кодом от 50000 до 2147483647, без предварительного добавления записей в sys.messages Однако есть пара ограничений — первое, уровень серьезности ошибки всегда 16, второе она не поддерживает многоязыковость и стиль формата printf. Для решения второй проблемы вам необходимо будет создать всё ту же справочную таблицу со всеми языками и кодами в БД. И при генерации ошибки использовать FORMATMESSAGE, завернув это как-то красиво в функцию, например:
O>

O>declare @err int = 55555
O>declare @msg nvarchar(2048)

O>select @msg = formatmessage(text, 'ПРОВЕРКА')
O>from sys.messages sm
O>join sys.syslanguages l on l.langid = @@langid and l.msglangid = sm.language_id
O>where sm.message_id = 21665;

O>throw @err, @msg, 1;
O>

O>В запросе с sys.messages и sys.syslanguages вы используете свою справочную таблицу в БД, я использовал их только для демонстрации.

Про это тоже думал, но не у всех клиентов развернут SQL 2012 и выше.

Здравствуйте, kgrach, Вы писали:

K>Нет такого регламента. Каждый клиент, как умеет так и разворачивает БД и как правило нас даже об этом не уведомляют.

Пытаетесь административную проблему решить тех. средствами?

K>А может быть есть какой-то механизм на SQL Server, который автоматом запускается после рестора бекапа и позволяет выполнить клиентский SQL код?

Триггер на логон, ругающийся "вы не до конца установили/восстановили БД. Запустите то-то и то-то".

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

M>>Здравствуйте, kgrach, Вы писали:

K>Хочется, получить функциональность RAISERROR, но только, чтобы сообщения жили в БД.

Оказывается, если вызвать RAISERROR без кода сообщения то код ошибки будет 50000 и механизм обработки в ПО можно не менять.
Далее в триггере вместо RAISERROR вызывается ХП, которая уже живет в БД форматирует сообщение и вызывает RAISERROR с сообщением.
Все