Галактика в вопросах и ответах

При печати акта на услуги в модуле "Управление сбытом" стандартными отчетами выдает сообщение

"Несовпадение контрольной суммы присоединенной формы "AKTS_04" из ресурса "\\Tsrv04\gal810t1\exe\L_SoprDoc.res" и формы прототипа "AKTS" ! Необходима перекомпиляция присоединенной формы "AKTS_04"

" Как убрать эту ошибку...????

А какая у вас версия ресурса \\Tsrv04\gal810t1\exe\L_SoprDoc.res? (см. Сводный отчет о системе)

Компонент "l_soprdoc" 'сопроводительные документы'
Установлено: версия "8.10.96.0"
Зарегистрировано: версия "8.10.70.0"

А что выдает отчет "Сервис / Информация / О конфликтах в формах" какой диагноз выдается там на этот прототип AKTS и форму AKTS_04?

А что выдает отчет "Сервис / Информация / О конфликтах в формах" какой диагноз выдается там на этот прототип AKTS и форму AKTS_04?

Что-то не нахожу такого отчета.... Есть такие - "О разработчиках", "О версии", "О лицензии", "О рабочей станции", "О компонентах".

Руслан писал(а): Как убрать эту ошибку...????

Когда программистов ТОП-Софта будут лишать премий или еще как то наказывать ( лишать пива на корпоративах и отсаживать за отдельный стол с надписью "мы меняем формы прототипы")
за то, что они меняют формы-прототипы _в рамках версии_ по многу раз и у всех пользователей многих стран после этого "творчества" наблюдается такое сообщение, вот тогда "ошибка исчезнет сама собой"...

Поймите дорогие мои разработчики в дружественной Беларусии - если вы изменили форму прототип - это автоматом повлечет за собой слом десятков и сотен отчетов ПО ВСЕЙ СТРАНЕ которые базируются на вашей форме.
Т.е. вы сэкономили 10 минут(2-3 часа в особо тяжелых случаях когда нужны данные которых нет в форме) своего рабочего времени
путем этого изменения, но потенциально создали проблему которая волной прокатилась по стране и накрыла все отделы АСУ на предприятиях которые сопровождают и поддерживают галку в исправном состоянии. А им и так то не сладко и есть чем заняться...

А ведь можно проблему "ой в форме прототипе нет нужного поля/полей, чё делать то?" решать таким образом чтобы никому не доставлять неудобств. Начиная с этапа проектирования формы прототипа (что уже поздно в вашем/нашем случае) и заканчивая использованием запросов к базе в программных циклах внутри присоединенных LINKFORM не затрагивая форм прототипов вообще.

По теме:
мне в этих случаях помогает команда:
findstr "^\." моя_форма.frm
findstr "^\." форма_из_галактики_измененная.frm
выводит только управляющие структуры.
Надо их сравнить и добавить в моя_форма.frm ту структуру которая появилась форма_из_галактики_измененная.frm
Скорее всего добавили какой нибудь никому нафиг не нужный:
.IF
или
.{
.}

1. Посмотрите все таки откуда вызывается ваша форма - в списке отчетов, закладка настройка.
Если это ваша форма
2. Такие ошибки должны быть видны еще на этапе компиляции - см vip_res.log
3. Часто в форме должно быть но вроде не в этом прототипе.
Насчет изменения прототипа при каждом чихе согласен. Достаточно чтобы туда выводились
нужные переменные, позволяющие полностью отразить структуру данных - типа nrec документа и спецификации.
Остальное разработчик может как и мы добавить через create view.
А так получается огромный поток с кучей никому не нужной информацией, что отрицательно сказывается на быстродействии
конкретного отчета и системы в целом. А разработчики к сожалению часто на задумываются о снижениии трафика в принципе,
что приводит потом к претензиям в к галактике по быстродействию. Уже не раз сталкивался, что один неведомый процесс
может деражать всю систему несколько минут.

Дело оказалось в нашем ресурсе - alter на интерфейс AKTUSLB.... Интерфейсы AKTUSL и AKTUSLB имеют общую форму-прототип AKTS... При компиляции эти ресы скомпилились без ошибок, но при подключении начали конфликтовать

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

хотя, поддержу Игоря... более того - они ещё очень часто правят названия поле, и если пользователи используют CNF скрипты, ох как тяжело потом искать новые названия и исправлять

Руслан писал(а):Дело оказалось в нашем ресурсе - alter на интерфейс AKTUSLB.... Интерфейсы AKTUSL и AKTUSLB имеют общую форму-прототип AKTS... При компиляции эти ресы скомпилились без ошибок, но при подключении начали конфликтовать

Получается вы в свой ресурс скомпилировали не только присоединенную форму но и измененную базовую. Я правильно понял?

Жаль что у вас старая версия. Отчет о котом я говорил по идее должен диагностировать подобный конфликт.

edward_K писал(а): Уже не раз сталкивался, что один неведомый процесс может деражать всю систему несколько минут.

Эдвард, хочу обратить ваше внимание на то, что причины возникновения подобных неведомых долговременных процессов теперь лего можно вычислить с помощью протокольных модулей. Эти модули с точностью до микросекунд фиксируют время и записывают в лог все опрараторы программы, вызовы функций и событий, запросы к БД. С помошью программ SmartInspect Console и SmartTime по протоколу можно легко найти причину каждого такого замедления вплоть до номера строки кода.

Сами модули и инструкци по сбору данных можете взять здесь: ftp://ftp.galaktika.ru/pub/support/temp ... Protocols/

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

Это все хорошо и наверняка полезно. Но это для тестирования конкретного фейса и пользователя
Но я говорю о том что неизвестно кто и неизвестно в каком интерфейсе. Узнать кто иногда профайлер сервера помогает, а вот для узнавания где приходится прибегать к пыткам пользователя. Было б хорошо если б галактика сама умела записывать куда нибудь простой больше заданного времени куда то Как это обычно бывает. Все работают, потом бац - 5 минут ничего не шеволится, в это время у какого то зверя вычитывается весь TTNDOC(1 гиг всего лишь). Проблему решили, но на ее локализцацию ушло полгода. Да и к теме это не относится.

Проблему TTNDOC именно эти протоколы помогли диагностировать за 2 дня