2. При применения пакета разницы возникает лог:
[color=red]Лицензия для модуля 'Custom' не найдена,
Лицензия для модуля 'Common' не найдена.
... ... ...[/color]

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

В полях [Пользователь] и [Пароль] (окна применения пакета) необходимо ввести sa (или имя пользователя являющимся стандартным системным администратором под Вашу СУБД) и его пароль.

Лицензию на этого пользователя заказывать не нужно.
После выполнение обновления Вы сможете подключиться к конфигурации под пользователем sa.

P.S. Проблема наблюдается при обновления конфигурации, начиная с версии 3.1.1. на MS SQL Server 2005 Express.

3. Если при пересохранении таблиц возникают следующие ошибки:

[color=red](E) Invalid object name 'dbo.tbl_TableName'. «Call Stack»
(E) Could not create constraint. See previous errors. Foreign key 'ForeignKeyName' references invalid table 'dbo.tbl_TableName'. «Call Stack»[/color]

[color=red](E) Error to save service: tbl_TableName'
Original message: При сохранении объекта 'Solutions\Details\Groups\tbl_TableName' в базу данных, возникла ошибка: Invalid object name 'dbo.tbl_TableName'[/color]

1. Удалить все внешние ключи;
Для этого в конфигурации необходимо создать следующий скрипт (и подключить scr_db):

// scr_DeleteAllForeignKeys
 
function Main() {
	Log.Write(1, 'Start.');
	var Service;
	var SelectQuery = Services.GetNewItemByUSI('sq_Service');
	ApplySelectQueryFilter(SelectQuery, 'ServiceTypeCode', 'Table', true);
	var Dataset = SelectQuery.Open();
	var i = 0;
	var Code;
	Dataset.GotoFirst();
	while (!Dataset.IsEOF) { 
		Code = Dataset.ValAsStr('Code'); 
		i++;               		
		try {
			Service = Services.GetSingleItemByUSI(Code);
			Service.Relations.Clear();
			Services.SaveItem(Service, 1);
			Log.Write(1, i + '. Service ' + Code + ' saved.');
		} catch(e) {
			Log.Write(2, i + '. Error to save service: ' + Code +
				' Original message: ' + e.message);
		} 
		System.ProcessMessages();
		Dataset.GotoNext();
	}
	Dataset.Close();
	Log.Write(1, 'Finish.');
}

2. Пересохранить таблицы;
3. Загрузить сервисы таблиц из коробочной конфигурации;
4. Пересохранить таблицы.

Таблицы не сохранившиеся автоматически необходимо сохранять вручную.

4. [color=red]The statement has been terminated. Cannot insert duplicate key row in object 'dbo.tbl_Service' with unique index 'UIServiceCode'[/color]
[color=red]Выполнение данной инструкции было прервано. Невозможно вставить повторяющуюся ключевую строку в объект "dbo.tbl_Service" с уникальным индексом "UIServiceCode"[/color]

Данная проблема может появиться при выполнении обновления с 3.3.0 на 3.3.1.

Дело в том, что при применении пакета разницы проверяется на уникальность как ID сервиса, так и его code.

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

Для решения этой проблемы необходимо выполнить скрипт "Generation.5.Repair IDs.sql" (во вложении прилагаю архив с этим скриптом).

В скрипте «Generation.5.Repair IDs.sql» необходимо внести следующие изменения:
-- [_33140_SD_Rus] заменить на название коробочной (пустой) БД версии 3.3.1.
-- [_33024_SD_Rus] заменить на название Вашей БД версии 3.3.0.

Результатом выполнения скрипта будет блок sql, который необходимо заменить в основном sql-файле (файл называется MSSQL.sql и находится в папке SQL).

Необходимо открыть его на изменение и в блоке: "UpdateServiceID" заменить имеющийся блок на сформированный.

Дополнительно хочу заметить, что если после выполнения «применителя» не будут открываться и изменяться сервисы: sq_* или wnd_*, то их необходимо заменить на сервисы из коробочной версии.

5. После выполнения обновления в некоторых разделах не отображаются статические и динамические группы.

Изначально рекомендуется убедиться, что группы перенеслись.
Для этого необходимо выбрать корневую группу и вызвав контекстное меню нажать на пункт "Отобразить группы всех пользователей".

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

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

'The statement has been terminated. Cannot insert duplicate key row in object 'dbo.tbl_Service' with unique index 'UIServiceCode'

"Присяжнюк Владимир" написал:Generation.5.Repair IDs.sql

create table #tmpCodes (
        Code nvarchar(250))
 
на
 
create table #tmpCodes (
        Code nvarchar(250) collate Cyrillic_General_CI_AS)

где Cyrillic_General_CI_AS - кодировка используемая в базе продуктов Terrasoft
так как временная таблица иначе создастся в кодировке сравнения по умолчанию заданной
на сервере.

Большое спасибо за решение третьей ошибки! Помогло!
Только сам по себе скрипт не отработал, добавила одну строчку:

Service.Relations.Clear();

в существующий скрипт пересохранения таблиц - scr_ResaveTables.
Таким образом пользовалась данным скриптом в двух вариантах:
- удаление всех внешних ключей;
- пересохранение таблиц.

По поводу ошибки №3:

т.е. решение в том, что нужно удалить Relations у всех таблиц? Так если они там заведены значит они там нужны, не так ли? Да и зачем трогать ВСЕ таблицы, когда нужно исправить только одну?

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

А в общем: Спасибо!

--
www.it-sfera.com.ua

"Виталий Ковалишин aka samael" написал:Спасибо!

Спасибо, за спасибо! :wink:
На самом деле я не ожидал, что кто-то так оперативно ответит.
Записка то еще не закончена, случайно "Сохранить" нажал.

Народ не дремлет! :wink:
Поосторожней с кнопкой "Сохранить"!

--
www.it-sfera.com.ua

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

"Underscore a.k.a. _" написал:Еще при написании конфигурации желательно учитывать возможность обновления. Стараться делать как можно меньше изменений. Например лучше добавить поле, чем переименовывать существующее. В идеале изменения в сервисах должны где-то отмечаться. Новые функции в скриптах как-то отделять. Изменения в скриптах комментировать.

Это было бы очень хорошим тоном написания своей конфигурации.
Подобные решения весьма приятно поддерживать и комфортно обновлять.

Павел!

Могу посоветовал решение попроще.

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

А вот если сделать так:
- сохранить сервисы tbl_Contact и tbl_Account;
- перенести данные;
- загрузить сохраненные сервисы;
Какова вероятность, что сервисы встанут корректно и без проблем?
Если такое попробовать провернуть на большем наборе сущностей чем 2 таблици?

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

А как они могут нарушить целостность, если они ее не нарушают в базе-источнике? Ведь мы просто сгенерируем два скрипта вида "insert into tbl_Account ..." и "insert into tbl_Contact" со всеми значениями полей.
Вопрос к тому не могут на корректный перенос повлиять может какие-нибудь триггеры?

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

Ах да, точно...
Но создание связей вручную, так же чревато этой проблемой...

Конечно же