Проблема с кодировкой при вставке в поле Lookup data

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

Не смог повторить это поведение - с Google Translate все корректно копируется. Может быть все зависит от версии - проверял на 7.6.0.

Верю что норм на 7.6.0, гуд реклама:)
Интересует 3.3.2.1

Такое ощущение что не даёт сохранить текст на армянском в ANSI

Для линейки 3.Х полноценная поддержка Unicode появилась в 3.4.0. При необходимости с 3.3.2 можно обновится до 3.4.0, перезаказать лицензии (платно).

Здорово.
А патч реально какой-то получить для адекватной работы с этим полем?

Нет, согласно статье по ссылке, там полностью обновили ядро.

Ну т.е. я если правильно понял, то также, согласно статье, мы можем без проблем быстро обновить ядро и работать без проблем?

Для начала можно проверить на демоверсии, решает ли 3.4.0 Вашу изначальную потребность.

После обновления бинарников с 3.3.2.1 на 3.4.0.178, есть ошибка открытия конфигурации при входе scr_TaskUtils объект System уже создан.
Конфигурация у нас нетиповая, какие можете дать рекомендации?
Обновить хотим только ядро для поддержки юникода.

Можете использовать отладку и понять, в каком именно месте скрипта scr_TaskUtils возникает проблема. В зависимости от этого и смотреть, это сбой в стандартной логике или в доработках.

Благодарю. Где могу посмотреть порядок открытия конфигурации (в плане загрузки скриптов)?

Чтобы посмотреть и отредактировать скрипты, нужно вместо TSClient.exe запустить TSAdmin.exe, в дереве справа найти нужный скрипт (вручную или поиском).

Посмотрите по коду scr_TaskUtils, как там используется System. У меня встречаются только System.MessageDialog и System.Now. Может, у Вас есть ещё что-то.

Ещё, после запуска на 3.4 при добавлении лота в заказ вылезает ошибка "Для поля "CreatedByName" нет поля в источнике данных. Что это может быть? Дебаггер отправил на метод Scr_DB AppendRecordInDataset(Dataset, FieldNames, FieldValues, DontDisableEvents), но там также ничего не менялось, может в 3.4 этот метод отличается?
Мой:

function AppendRecordInDataset(Dataset, FieldNames, FieldValues, DontDisableEvents) {
	if (FieldNames.length != FieldValues.length) {
		throw DifferentElementCountInNameAndValueArrays;
	}		
	if (!DontDisableEvents) { 
		Dataset.DisableEvents();
	}
	try {
		Dataset.Append();
		Dataset.ValAsGUID('ID') = Connector.GenGUID();
		var Field;          
		for (var i = 0; i < FieldNames.length; i++) {
			Field = Dataset.DataFields(FieldNames[i]); 
			if (Field){
				Dataset.Values(FieldNames[i]) = FieldValues[i];
			}			
		}
		Dataset.Post();
	}
	finally {			 		
		if (!DontDisableEvents) { 	
			Dataset.EnableEvents();	
		}
	}
}		

Бред или нет, но проблема только в одном датасете, он после Append и постинга в себя он ругается на то что для поля для отображения нет поля в источнике данных. Если отдельно взять и вместо справочного поля создать два текстовых - один для ИД, второй для Name, то всё нормально. Как может такое быть, что один конкретный датасет, после перехода только ядра на версию 3.4 перестал себя вести прилично? Не понимаю...Сервис датасета прикладываю.

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

• CreatedByID
• CreatedByName

Такие сообщение появляются только в том случае, когда поле не участвует в запросе, т.е. его отключили. Отключили в сервисе запроса или с помощью одной из функции DisableAllColumns или EnableColumns(с параметром false)

Уже делал.
Удивительно, но проблема только с одним датасетом и только после перехода на новое ядро.
Кэш чистил.
Проблема осталась.

Ещё попробуйте пересохранить сервисы, связанные с этой таблицей: tbl, sq, ds. Что-то в них измените, потом верните как было и нажмите сохранение.