21.10.2005, 18:10 | #21 |
Moderator
|
Эх, похоже, рано радовался. Idшники-то меняются, но данные из полей слетают сразу после синхронизации. Мда...
3хзвенка.
__________________
Андрей. |
|
21.10.2005, 18:15 | #22 |
Участник
|
В двухзвенке - Ok. В трехзвенке - то, что вы описали.
__________________
Axapta v.3.0 sp5 kr2 |
|
21.10.2005, 18:19 | #23 |
Moderator
|
Да, все верно. С 3хзвенкой стормозил, привык к ней уже
В 2хзвенке все работает, причем как раз синхронизацию не надо делать. Поменял idшники в UtilIdElements, вышел/вошел - и все, данные на месте, и fieldId правильные. AndyD, спасибо.
__________________
Андрей. |
|
21.10.2005, 18:28 | #24 |
Модератор
|
Спасибо!
Перенес в "Полезное" С Уважением, Георгий |
|
21.10.2005, 22:44 | #25 |
Administrator
|
Цитата:
Сообщение от AndyD
Что имеется в виду? При синхронизиции, если изменился ID поля, оно удаляется, а затем создается заново. Соответственно при этом данные теряются
Цитата:
Сообщение от sukhanchik
Удалите из таблички SQLDictionary все записи, касающиеся данной таблички (фильтр по tabId), и нажмите Администрирование-Периодические операции-SQLАдминистрирование. Выберите нужную табличку(которую грохали в SQLDictionary) и нажмите кнопку Таблицы-Проверка/синхронизация. Табличка SQLDictionary воссоздастся с уже правильным fieldId (который соответствует АОТу), и все... Воспользутйесь принципом - что правильный тот fieldId, который в АОТе, а не в SQLDictionary.
PS Данные не пропадут. Сначала воссоздастся SQLDictionary, а затем пройдет синхронизация (по уже заведомо правильным Id-шникам)
__________________
Возможно сделать все. Вопрос времени |
|
21.10.2005, 22:57 | #26 |
Участник
|
Извините, но вы убрали фразу, на которую и был мой ответ -
Цитата:
Перестройка SQLDictionary в соответствии с новыми id-шниками ВСЕГДА сохраняет данные.
Не всегда, а в случае отсутствия в SQLDictionary информации по полю
__________________
Axapta v.3.0 sp5 kr2 |
|
|
За это сообщение автора поблагодарили: Logger (1). |
22.10.2005, 15:46 | #27 |
Administrator
|
Цитата:
Сообщение от AndyD
Не всегда, а в случае отсутствия в SQLDictionary информации по полю
__________________
Возможно сделать все. Вопрос времени |
|
20.05.2009, 17:52 | #28 |
Участник
|
Цитата:
Сообщение от AndyD
Вот тестовый джоб
X++: 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; } Слетает куча мест в приложении, которая ссылается на поле. Формы, мапы (sic!), EDT. Очень аккуратно надо менять, проверяя нет ли ссылок. |
|
21.05.2009, 08:38 | #29 |
Участник
|
Моё мнение, всё это какое-то шаманство.
Я обычно делаю перенос без Id-ков они сами создаются системой. dev->test->work. Ну и пусть они отличаються. Может я на dev 10 раз создавал и 10 раз удалял один и тот же объект. Главное я знаю на рабочей они правильные. Раз в какой-то период(месяц, две недели) надо просто попросить админа выровнять прилаги в обратном порядке. work->test->dev. И Id-ки станут везде хорошие. Заодно мож где-то мусор залежался, смоет.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему. |
|
21.05.2009, 09:50 | #30 |
Участник
|
Для распределенного создания IDшников есть ID сервер - см. доки по контролю версий
Последний раз редактировалось belugin; 21.05.2009 в 11:11. |
|
17.06.2009, 10:11 | #31 |
Moderator
|
****** Часть темы выделена в новую тему Обновление рабочего приложения: проектами или слоем? ******
__________________
Андрей. |
|