Изменение идентификаторов(id) полей

[Dron AKA andy]

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

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

Пока я смог накопать только то, что простое программное изменение id поля в таблицах UtilIdElements и SQLDictionary приводит следующему: id в репозитарии меняется, но поле теряет все свои свойства, в том числе и тип.

Поэтому вопрос к общественности: решаема ли такая задача?

[sukhanchik]

А не надо заменять fieldId. Правильный fieldId хранится у вас в приложении. А вот подстроить под это дело базу - можно легко. Удалите из таблички SQLDictionary все записи, касающиеся данной таблички (фильтр по tabId), и нажмите Администрирование-Периодические операции-SQLАдминистрирование. Выберите нужную табличку(которую грохали в SQLDictionary) и нажмите кнопку Таблицы-Проверка/синхронизация. Табличка SQLDictionary воссоздастся с уже правильным fieldId (который соответствует АОТу), и все... Воспользутйесь принципом - что правильный тот fieldId, который в АОТе, а не в SQLDictionary.
PS Данные не пропадут. Сначала воссоздастся SQLDictionary, а затем пройдет синхронизация (по уже заведомо правильным Id-шникам)

[Dron AKA andy]

То, что SQLDictionary восстановится по АОТ - это хорошо. Но в моем случае есть 2 АОТ, в которых таблица имеет разные fieldId для одних и тех же полей. И надо добиться одинаковой структуры. Т.е. fieldId менять тем или иным способом.

[glibs]

Посмотрите поиск. Если у вас 3.0, то поможет экспорт-импорт с сохранением идентификатторов объектов.

[Dron AKA andy]

Процитирую сам себя:

Цитата:

Сообщение от Dron AKA andy

Экспорт-импорт со значениями идентификаторов не исправляет id существующих полей.

И это работает именно так.

[glibs]

Вы экспортировали в файл, меняли в текстовом редакторе, ID и импортировали обратно? Остался старый?

[Dron AKA andy]

Именно.

[AndyD]

Цитата:

Пока я смог накопать только то, что простое программное изменение id поля в таблицах UtilIdElements и SQLDictionary приводит следующему: id в репозитарии меняется, но поле теряет все свои свойства, в том числе и тип.

Пороверил - все Ok. Ничего не слетело, синхронизация - нормально, данные - нормально.

[Dron AKA andy]

Экспериментирую повторно. То слетают, то не слетают. Попробуйте использовать несколько полей разных типов и менять id в произвольном порядке.

[itfs]

Цитата:

Сообщение от Dron AKA andy

Возникло непонятное расхождение между fieldId в одной из таблиц на рабочей и тестовой базах.

Почему непоняное? Вполне логичное расхождение если объект симпортировать "без переноса идентификаторов" ему идентификатор будет заново сгенерен системой.

Цитата:

Сообщение от Dron AKA andy

форма, основанная на этой таблице, показала какую-то ерунду

Ни разу не сталкивался, хотя первые пол года практики именно так и переносил проекты. И перекомпиляция не помогла?
Если 2 AOT разные, причем, не по делу - выкиньте один из них, оставшийся разнесите на обе системы. После синхронизации все будет одинаковое.

С уважением, itfs.

[kvan]

Цитата:

Сообщение от itfs

Если 2 AOT разные, причем, не по делу - выкиньте один из них, оставшийся разнесите на обе системы.

Серьезное заявление!
Помниться на одном проекте один человек сделал именно так ...
В результатет были потеряны 2 моих разработки, которые я отказался делать заново и они так и не были никогда сделаны ...

[Dron AKA andy]

Цитата:

Сообщение от itfs

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

Если вы сможете повторить изменение id полей так, что об этом будет знать только сама таблица (а на формах чтоб остались ссылки по старым FieldId), то увидите. Говорю же, это был очень странный слет idшников.

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

[AndyD]

Цитата:

Сообщение от Dron AKA andy

Экспериментирую повторно. То слетают, то не слетают. Попробуйте использовать несколько полей разных типов и менять id в произвольном порядке.

Вот тестовый джоб

static void Job37(Args _args)
{
    UtilIdElements      ue_Table;
    UtilIdElements      ue_Fields;
    SQLDictionary       SQLDict;
    ;
    select firstonly ue_Table
    where ue_Table.recordType == UtilElementType::Table && ue_Table.name == "Table13";

    ttsbegin;
    if (ue_Table)
        while select forupdate ue_Fields
            order by id desc
            where ue_Fields.recordType == UtilElementType::TableField &&
                ue_Fields.ParentId == ue_Table.id 
        {
            select forupdate firstonly SQLDict
            where SQLDict.TabId == ue_Table.id && SQLDict.FieldId == ue_Fields.id;

            ue_Fields.id += 13;
            ue_Fields.update();
            if (SQLDict)
            {
                SQLDict.FieldId = ue_Fields.id;
                SQLDict.Update();
            }
        }
    ttscommit;
}

Пробовал менять сортировку, шаг изменения, менял по одному и по несколько полей разных типов

[itfs]

Цитата:

Сообщение от kvan

Серьезное заявление!
Помниться на одном проекте один человек сделал именно так ...
В результатет были потеряны 2 моих разработки, которые я отказался делать заново и они так и не были никогда сделаны ...

А что "Source Save" средствами вы не пользуетесь? При работе в Аксапте, по моему мнению, это необходимо. Меня, к слову, накрывают раз в две-три недели, и ничего ...

2 Dron AKA andy: понятно, в глюки я верю ... просто не увидел проблемы в том, что id разные.

С уважением, itfs.

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

[sukhanchik]

Цитата:

Сообщение от Dron AKA andy

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

Перестройка SQLDictionary в соответствии с новыми id-шниками ВСЕГДА сохраняет данные. Ну а в Аксапте всегда так - когда есть проблема - то возможное ее решение может оказаться не таким, о котором думаешь ... Так и здесь. Нет необходимости просто так менять id полей. Но сделать так, чтобы данные не потерялись - можно.

Классический пример - перенос таблицы с уже вбитыми в нее данными в другой слой (LedgerTrans )

[AndyD]

Цитата:

Перестройка SQLDictionary в соответствии с новыми id-шниками ВСЕГДА сохраняет данные

Что имеется в виду? При синхронизиции, если изменился ID поля, оно удаляется, а затем создается заново. Соответственно при этом данные теряются

[Dron AKA andy]

В общем, вроде нашел решение.
Вот джоб, которым тестировал:

static void Tutorial_ChangeFieldId(Args _args)
{
	UtilIdElements uie;
	SQLDictionary dict;
	;
	ttsbegin;
	select forupdate uie
		where uie.name == "Field2" &&
			 uie.parentId == tableNum(Tutorial_ChangeFieldId);
	if (!uie)
		warning("Запись в UtilIdElements не найдена");
	else
	{
		uie.id = 50005;
		uie.update();
	}
//	appl.dbSynchronize(tableNum(Tutorial_ChangeFieldId), false);
//	select forUpdate dict
//		where dict.tabId == tableNum(Tutorial_ChangeFieldId) && dict.fieldId == fieldNum(Tutorial_ChangeFieldId, Field2);
//	if (!uie)
//		warning("Запись в SQLDictionary не найдена");
//	else
//	{
//		dict.fieldId = 50005;
//		dict.update();
//	}
	ttscommit;
}

После его запуска у меня становится имя поля UNKNOWN и теряются свойства (делаю "Восстановить" сразу после запуска).
НО: если тупо после этого сделать синхронизацию таблицы - о чудо, все восстановилось! Id поменялся, данные в таблице остались. Абсолютно интуитивно непонятный механизм - смотрим на какую-то фигню (UNKNOWN), после синхронизации получаем конфетку

То, что закомментировал, оказалось ненужным. Программная синхронизация таблицы не помогает, нужно почему-то обязательно через АОТ делать. Так что решение таково: программно изменяем IDшники полей в UtilIdElements и делаем синхронизацию таблицы. Вуаля!
Спасибо всем, принявшим участие в эксперименте.

[AndyD]

Я не делал "Восстановить", а закрывал и открывал в Axapta'у

[Dron AKA andy]

Вот прямо только что запустил джоб и сразу вышел/вошел - не прокатило. UNKNOWN. После этого синхронизировал, затем восстановил - все прошло.
AXAPTA, кстати, тоже SP3 CU1.

[AndyD]

Двух/трехзвенка?