Перенос организационной структуры между приложениями

Здравствуйте.

При переносе данных таблицы SysAdminUnit(Объект администрирования) из одно приложение в другое (приложения идентичны) возникает ошибка:
"The transaction ended in the trigger. The batch has been aborted. @Terrasoft.Core, SysAdminUnitSchema.Exception.InvalidRootType"

Подскажите пожалуйста в может быть проблема и как правильно переносить орг. структуру.

Нравится

12 комментариев

Здравствуйте!

Попробуйте отключить триггер TRSysAdminUnitRoot (пакет Base) и затем попробовать переместить данные.

Только перед этим протестируйте или сделаейте копию БД/приложения.

"Мотков Илья" написал:

Здравствуйте!

Попробуйте отключить триггер TRSysAdminUnitRoot (пакет Base) и затем попробовать переместить данные.

Только перед этим протестируйте или сделаейте копию БД/приложения.

Спасибо, после отключения триггера, обновление данных завершилось успешно.

Спасибо за решение.

А подскажите, пожалуйста, как включение и выключение триггера добавить в пакет, чтобы не выполнять эти скрипты каждый раз вручную?

Отключать триггер, наверное можно "Before saving package", а вот когда включать?

И второй вопрос - почему импорт SysAdminUnit выполняется так долго (50 минут, хотя в данных всего около 20 ролей и 10 пользователей)? Может быть, можно ещё что-то отключить и выполнить единоразово после всего импорта?
 

2020-10-29 17:19:06,697 [5] INFO NT AUTHORITY\SYSTEM InstallZipPackage LogInfo - Lookup values "States_Provinces" from package "Exactly.Data" installed
2020-10-29 18:05:40,163 [5] INFO NT AUTHORITY\SYSTEM InstallZipPackage LogInfo - Lookup values "SysAdminUnit" from package "Exactly.Data" installed

 

Ну, наверно, если отключать на «Before», то включать на «After». Такой вариант тоже есть:

А что может так сильно тормозить этот импорт?

 

Всё, что угодно, например, ещё какие-то триггеры, которые не отключили (и, возможно, отключать и не стоит). Попробуйте посмотреть в SQL-профайлере на отрабатывающие запросы.

 

Тщательно протестировали. Триггер не отключается перед установкой почему-то на Before...

Ясно. Выходит, сначала идёт AfterPackage и уже затем AfterSchemaData.

Но при этом иногда стала появляться такая ошибка из того же триггера:
 @Terrasoft.Core,SysAdminUnitSchema.Exception.RootAlreadyExists

То есть, кажется, он успевает включиться до того, как данные начинают импортироваться (пробовали и After package saved, и After Schema data saved.

 

Если убрать включение триггера, то всё проходит без ошибок. Но кто тогда будет включать триггер?

Судя по RootAlreadyExists, ругается на какую-то конкретную запись, которую считает корневой. Всё ли правильно в залитом? А если в скрипте перед включением триггера задержку вставить?

Да, сначала даже подумал, что в пакете какие-то записи с пустым ParentRoleId. Но посмотрел - нет таких.
Возможно, что при импорте данных что-то дёргает уже существующие All employees, и потому срабатывает триггер.

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

Но после импорта SysAdminUnit и SysUserInRole хорошо бы запустить процедуру tsp_ActualizeAdminUnitInRole. Но пока тоже не совсем понятно, куда её воткнуть...

	IF (TG_OP = 'INSERT' OR TG_OP = 'UPDATE') AND TG_WHEN = 'AFTER' THEN
		IF (NEW."ParentRoleId" IS NULL AND NEW."SysAdminUnitTypeValue" < 4) THEN 
 
			IF (NEW."SysAdminUnitTypeValue" > 0) THEN
				RAISE '@Terrasoft.Core,SysAdminUnitSchema.Exception.InvalidRootType';
				ROLLBACK;
			END IF;
 
			SELECT COUNT("Id") INTO RecordsCount FROM "SysAdminUnit"
				WHERE "ParentRoleId" IS NULL
					AND "SysAdminUnitTypeValue" < 4
					AND "SysAdminUnit"."Id" <> NEW."Id";
 
			IF (RecordsCount > 1) THEN
				RAISE '@Terrasoft.Core,SysAdminUnitSchema.Exception.RootAlreadyExists';
				ROLLBACK;
			END IF;
 
		END IF;
	END IF;

 

Если импорт выполняется долго по непонятной причине, попробуйте смотреть в профайлере, что за запросы долго работают.

 

Если есть тестовый стенд, где без каких-либо доработок, просто при добавлении данных такая долгая заливка воспроизводится, можете написать в поддержку для её анализа.

 

Вероятно, ту функцию актуализации, которую хотите запустить, нужно тоже на одном из «After...».

 

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

 

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

Показать все комментарии