Не могли бы Вы более подробно описать те действия, которые Вы предприняли для уменьшения размера граф. базы, чтобы нам знать как решать такую проблему в будущем... Спасибо.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Нам пришлось создать специальный вариант РПД именно под эту операцию. Распространять его мы не можем. Вам необходимо в дальнейшем более внимательно следить за тем, как Вы формируете свободные ФО "Переходы по экранам".
Posted by Wizard(Леденёв Андрей) (Участник № / Member № 109) on :
Опишите,пожалуйста, ситуацию - в чем была ошибка с переходами по экранам. Чтобы и другие пользователи её не сделали...Спасибо
Posted by Droshnev (Участник № / Member № 132) on :
Уважаемые сотрудники тех поддержки, ответьте пожалуйста подробно на вопрос.
У нас возникла подобная ситуация. Пример: 1) Текущий размер графической части узла = 13Мб 2) Делаем экспорт графической базы узла в файл.
Сразу вопрос разработчикам: Как сделать экспорт отдельно взятого экрана? (не Ctrl+A&CtrlC&Ctrl+V)
3) Удаляем для примера любой из экранов(1 из 15) 4) Тут же делаем импорт этого файла 5) Появляется удаленный экран 6) Сохраняем проект 7) Получаем размер графической части узла(файл *.dbg) = 27Мб 8) И так далее ~40Мб, 53Мб.....
Вопросы: 1) Почему так происходит?(Подробно если можно) 2) Как сделать экспорт отдельно взятого экрана? 3) Как очистить уже испорченый проект? 3а) Можно ли это сделать своими силами, не высылая вам проект? Если нет, то почему? 4) Как понимать вашу фразу "Вам необходимо в дальнейшем более внимательно следить за тем, как Вы формируете свободные ФО "Переходы по экранам" " Что вы под этим подразумеваете?
У нас часто происходит параллельная работа двух(трех)сотрудников с графической частью одной базы. Посему проблема импорта/экспорта экранов очень актуальна.
Ждем от вас ответа.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Данная ошибка была в очень ранних релизах ТМ, примерно в 5.051 и в 5.06. Затем она была исправлена. Заключалась она в том, что при импорте\экспорте начинало удваиваться количество свободных ФО "Переходы по экранам", что приводило к увеличению размера файла графической базы с каждой процедурой импорта. На данный момент в последних релизах эта ошибка исправлена. 2) Для экспорта отдельно взятого окна его необходимо выбрать в списке окон и по правой кнопке мыши произвести экспорт в файл. 3) Своими силами очистить уже ипорченный проект - нельзя. Смотрите объяснение выше. 4) Дело в том, что данная ошибка появлялась в случае, когда в списке ФО перехода по экранам присутсвовали ссылки на несуществующие экраны.
Posted by Droshnev (Участник № / Member № 132) on :
1) То есть в релизе 5.11 этой ошибки быть не должно? Но у нас именно релиз 5.11 и эта ошибка судя по всему присутствует? 2) После этой операции получается файл по размеру равный файлу проекта(Node1.dbg)и если потом выйти из РПД и этот "экспортированный экран" переименовать в файл проекта(Node1.dbg) и загрузить РПД, то все откроется нормально Отсюда мы делаем вывод, ЧТО ЭКСПОРТИРУЕТСЯ НЕ ТОЛЬКО ЭКРАН, А ЦЕЛИКОМ ВЕСЬ УЗЕЛ!!! 3) Как и в каком виде(составе)его Вам прислать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Нет - ошибка появлялась в проекте только в ранних релизах (т.е. сделать ее можно было только в ранних релизах), а уже как ее следствие - рост размера файлов - будет наблюдаться в любом релизе, даже в 5.12. Это обусловлено тем, что нарушается структура граф. базы, но РПД не может воспринять ее как ошибку, потому как для него это просто большое количество ФО в одной базе и ничего более. 2) Вот в этом ошибка и проявляется - нарушенные ФО начинают цеплять за собой всю графику проекта, и при последующем импорте графическая база удваивается в объеме. 3) Желательно архив всего проекта (только не самораспаковывающийся!). Необходимы: файл *.ctm и одноименная директория (все ее содержимое).
Posted by Droshnev (Участник № / Member № 132) on :
Проект Вам отправлен с ящика dim24@mail.ru на ящик forum@adastra.ru, файл:Droshnev(Orenburg).rar
Posted by AdAstra Technical Support (Участник № / Member № 4) on :