Необходимость обновить запись файла, находясь в Form и не вы

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Ответить
Гость

Сообщение Гость »

Здравствуйте!
CW5.5H ШВС
У меня возникла необходимость сохранить изменения записи файла, находясь в ее form'е. У этого файла есть дочерние файлы, таблицы которых открываются в form основного файла, и когда пользователь вносит изменения в дочерние файлы, часть итогов должна сохраниться в полях основного файла, но если пользователь нажимает отмену, то эти итоги естественно туда не попадают. Можно, конечно ограничить его в плане нажатия на отмену в случае изменения дочерних файлов, а может есть способ поэлегантнее?

Написал: Ajra(8)
Гость

Сообщение Гость »

а может есть способ поэлегантнее?
я не знаю как это реализовано в ШВС, в ABC есть точка вставки не в форме, а в самом браузе ResetFromAsk - она отрабатывается, когда завершили ввод в форму, не важно с ОК или с Отмена. Т.е. уже после закрытия формы при возврате в брауз. В этом месте и можно произвести перерасчет. В ШВС я так полагаю тоже должно быть что либо подобное. Посмотри в sourse что происходит после закрытия формы и найди необходимую точку вставки.
Гость

Сообщение Гость »

Поэлегантнее - на ABC. В файл менеджере дочерного файла при всех апдейтах,
инсертах и делитах вызываешь процедуру пересчета итогов и организуешь
транзакцию с родительским файлом. Все. Если будешь пользоваться только
методами классов и забудешь про add/put/delete - проблем не будет. А в
шестерке для этого придумали "триггеры" и бизнесс-правила. В 5.5 это можно
попробовать сделать через "хуки" в файловых драйверах:

CALLBACK Register or unregister a FileCallBackInterface.

WBR, Nick Tsigouro. MailTo: Nick@arsis.ru
Написал: ClaList(2)
Гость

Сообщение Гость »

Спасибо, Nick!
Ну не смогла я в свое время перейти на ABC, страна требовала больше программ хороших и разных, вот и сижу на ШВС:D. А о шестерке могу пока только мечтать. Ладненько, буду вызывать и организовывать.:)
Написал: Ajra(8)
Гость

Сообщение Гость »

А почему так грустно? ШВС - отличный набор.

WBR, Nick Tsigouro
Написал: ClaList(2)
Гость

Сообщение Гость »

Да нет, не грустно, просто, иногда чего-то не хватает и чаще всего именно того, что уже есть в ABC, вот и приходиться множко думать:), а ШВС, действительно отличный набор. Да, еще спасибо за dbf файлы, все получилось просто отлично.
Написал: Ajra(8)
Гость

Сообщение Гость »

Или я чего не понимаю, или одно из двух! :))

Николай, ты так вообще "застращаешь" коллегу -
в ШВС все можно сделать так-же красиво и аккуратно
как и на ABC, и без всяких колбэков.

Алгоритм для КОНКРЕТНОГО случая:
!!! Следует иметь в виду (да и вообще - полезно знать),
что при входе в форму в режиме редактирования ТЕКУЩЕЕ
содержимое записи автоматом сохраняется в локальной
группе SAV::PRE:Record, где PRE - префикс редактируемого файла.
Если есть еще и MEMO-поле, то оно сохраняется в отдельной
строковой переменной типа SAV::PRE:Notes_Field.
Это - так сказать введение.

- предполагаем, что расчетная сумма по дочерним записям
подсчитываетя автоматически прямо в поле родительской записи,
например PRE:Child_Sum.
- в точке вставки "Конец процедуры до закрытия файлов" пишешь
что-то типа:

Код: Выделить всё

  IF (LocalRequest = ChangeRecord) AND (LocalResponse <> RequestCompleted)
! т.е. - если режим редактирования и выход из формы
!        по кнопке Cancel.
     IF (PRE:Child_Sum <> SAV::PRE:Record.Child_Sum)
! т.е. - сумма изменилась. Замечу, что если поле суммы
!        имеет тип REAL, то правильно будет так:
!        ROUND(...) <> ROUND(...)
        SAV::PRE:Record.Child_Sum = PRE:Child_Sum
        PRE:Record = SAV::PRE:Record
        PUT(PrimeFile)
     END
  END
Если сумма (суммы) подсчитываются в локальной переменной,
например LOC:Child_Sum, то:

Код: Выделить всё

  ...
     IF (LOC:Child_Sum <> SAV::PRE:Record.Child_Sum)
        PRE:Record = SAV::PRE:Record
        PRE:Child_Sum = LOC:Child_Sum
        PUT(PrimeFile)
     END
  ...

Т.е. вышеприведенный код обновит в родительской записи
ТОЛЬКО поле суммы. Сработает это ТОЛЬКО если эта сумма
изменилась и выход из формы произошел по Cancel.
Если выход нормальный, через Ok, то обновление будет
произведено уже стандартным кодом шаблона.

Вот и все, и без лишних наворотов и сложностей!

Да, и еще!
По этой теме были советы делать что-то подобное уже
после возврата из формы в каталог. Имхо - этого
делать не стоит! Потому что, имхо, это НЕПРАВИЛЬНО!
ВЕСЬ код обработки записи должен быть сгруппирован
прямо в форме, БЕЗ выноса части функционала во вне.
Только так можно обеспечить правильную и стабильную
работу формы В ЛЮБОМ контексте! Вообще, советую
воспринимать формы и подобные им процедуры как
некое подобие "черного ящика", когда ВЕСЬ функционал
находится внутри и НЕ зависит от внешних условий
вызова. За исключением входных данных, естественно!

Удачи!

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com

Библиотека DynaLib
http://dynalib.narod.ru

(Добавление)
Николай, ты так вообще "застращаешь" коллегу -
в ШВС все можно сделать так-же красиво и аккуратно
как и на ABC, и без всяких колбэков.
Скорее всего ты прав. Просто я а на легасях не писал уже несколько лет. А на
ШВС вообше не пришлось.
[...]
- в точке вставки "Конец процедуры до закрытия файлов" пишешь
что-то типа:

IF (LocalRequest = ChangeRecord) AND (LocalResponse <> RequestCompleted)
А пару миллисекунд назад Чубайс повернул рубильник/пионер вставил гвоздик в
розетку, и дочки обновились, а папа не успел. Поменяешь пробки - запускай
пересчет итогов по всей базе. Да даже просто кто-то на соседней станции
открыл эту запись и удивился, а чего это там концы с концами не сходятся...
Такие вещи нужно делать во временных файлах/очередях и выливать в базу одной
транзакцией, либо корректиовать родителя на каждом изменении потомка. Опять
же, в одной транзакции.

WBR, Nick Tsigouro
Написал: ClaList(2)
Гость

Сообщение Гость »

Здравствуйте, Nick!
Такие вещи нужно делать во временных файлах/очередях и выливать в базу одной транзакцией, либо корректиовать родителя на каждом изменении потомка.
Опять же, в одной транзакции.
Для случая с накладными мне нравится такой подход. Накладная имеет поле
статуса, одно из состояний которого - "утверждена". Утвержденные документы
править запрещается, пока отметка не снята. Утвержденные документы попадают
в финансовые отчеты, а не утвержденные резервируют товар. Итоговые значения
в шапке документа сохраняются только при утверждении. Для неутвержденых
документов рассчитваются в рантайме. Если учесть, что количество
неутвержденных документов невелико, то больших задержек быть не должно.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Написал: ClaList(2)
Гость

Сообщение Гость »

Здравствуйте!
Про рубильник с пионером очень понравилось. На самом деле, я, как и сказал Николай, после всех add/put/delete делала пересчет всех итогов, которые попадают в поля родительского файла, а потом делала транзакцию с родительским файлом , потому, как "пионер с чайником" очень актуален для нас. Просто оставались сомнения не слишком ли много всяких пересчетов и транзакций.
Спасибо.
Написал: Ajra(8)
Гость

Сообщение Гость »

CALLBACK Register or unregister a FileCallBackInterface.
Хм... Сам-то пользуешься или только советуешь? Помнится,
я проводил эксперименты и публиковал результаты. Для тех,
кто задает такой вопрос по ШВС, я бы не рекомендовал. Настоятельно.
Остальные сами способны провести эксперименты и отказаться
от использования данного механизма.
Или я чего не понимаю, или одно из двух!:))
Отож :gigi:
[вырезан алгоритм, к торому мне добавить нечего]
Да, и еще!
По этой теме были советы делать что-то подобное уже
после возврата из формы в каталог. Имхо - этого
делать не стоит! Потому что, имхо, это НЕПРАВИЛЬНО!
IMHO, хранить суммы (динамические) в родителе вообще
НЕПРАВИЛЬНО. Почему?
1. При сетевой работе больше риск возникновения ошибки
"Запись изменена с другой станции".
2. Накапливаются ошибки в БД.
3. Ускорение в обработке родителей сводится на нет п.2.

Как раз сейчас приступаю к разгребанию именно этих граблей.
Есть схема Дом-Квартира. В домах хранились суммы площадей
по квартирам. В общем-то, правильно хранились. Ряд отчетов
строился по суммам из домов.
Появились квартирые с признаком "не учитывать в суммах".
Естественно, что я забыл исправить обновление сумм в домах...
Потом вспомнил... А часть сумм - неправильная. Да и на самом
деле ситуация сложнее, т.к. задача живет далеко не первый день
и перестраивается с нарушением большинства правил, о которых
я рассказываю студентам... :):):)

Как бы я сделал сейчас?
1. Никаких сумм в родителях.
2. Фильтр для всех однотипных броузов и отчетов - единая функция.
3. Аналогично и с сумматорами-вычислителями.
4. Для ускорения обработки - автоматически генерируемый
файл сумм.

Ускорение от сумм в родителях мнимое. Тот, кого интересуют
цифры на уровне дедов и прадедов, уже не торопится. Ему не
составить труда запустить процедуру построения промежуточных
итогов и сходить на перекур. Потом быстренько построить по
этим итогам десяток отчетов. Оперативность требуется на уровне
отец-сын. А это всего-то до полусотни записей в обработке. И
их гораздо проще посчитать на лету, чем мутить с суммами... Да и
в подобных выходных формах, как правило, печатаются все дети.
Тем более, что подсчет сумм по детям в форме генерит сумашедший
трафик - необходимо дернуть всех детей на любое действие с
детьми.

Вот сижу и думаю... Переписать обработку в трех отчетах или написать
одну процедуру проверки сумм в домах? :):):)

PS: Пока я еще не встречал такой вещи, которая была бы мне
нужна для работы (не для понтов) и которой бы не было в ШВС
и бесплатных шаблонах, но которая была бы в АВС.

С уважением,
Владимир Смелик vovs@bigfoot.com
Написал: ClaList(2)
Гость

Сообщение Гость »

Соглашусь с Владимиром, не надо было толкать итоги в поля родительского файла. Но эта программа была написана 4 года назад, думать о плохом не хотелось:), и естественно, случилось то, что описано выше - ошибки в базе данных. Прога здоровая, переписывать пришлось бы очень много, там практически все отчеты основаны на этих итогах, плюс некоторые дочки пользуются итогами других дочек в одной форме родителя, вот и встал риторический вопрос, как бы это все контролировать, чтобы ошибочек поменьше. Или уж переписать?:D
Написал: Ajra(8)
Гость

Сообщение Гость »

Все зависит от того, как часто строятся отчеты, которые
используют эти итоги. Если не очень часто, то можно
дописать модуль проверки-коррекции, который следует
запускать перед построением отчетов. Другое дело, если
эти итоговые суммы используются постоянно.
Хотя, и здесь можно обойтись только модулем проверки-коррекции.
Ошибки появляются не каждый день и обычно сразу заметны.
Как заметил оператор такую ошибку - сообщил админу - админ
запустил проверку-коррекцию.

А переписывать - только если ошибки совсем уж замучили.

=============================
С уважением, Олег А. Руденко

(Добавление)
Хм... Сам-то пользуешься или только советуешь?
Чем я пользуюсь я отписал в предшествующем посте. Я советовал не
пользоваться а попробовать ;-) Кстати ABC в 5.5 их активно используют. См.
ABFile.clw. Так, что можно сказать, что пользуюсь ;-)
IMHO, хранить суммы (динамические) в родителе вообще
НЕПРАВИЛЬНО.
Я бы не был столь категоричен. Мне трудно представить себе
высокопроизводительную банковскую систему, которая обойдется без хранения
текущих остатков на счетах.
1. При сетевой работе больше риск возникновения ошибки
"Запись изменена с другой станции".
Остатки ручками _никогда_ не редактируются. Это все равно, что печатать
деньги, или красть их из сейфа. Это не банковская операция :)
2. Накапливаются ошибки в БД.
;-)
3. Ускорение в обработке родителей сводится на нет п.2.
Остатки хранятся как раз для ускорения обработки детей. Напр. для выяснения
имеется ли на счете необходимая сумма при оформлении платежа.
[...]
PS: Пока я еще не встречал такой вещи, которая была бы мне
нужна для работы (не для понтов) и которой бы не было в ШВС
и бесплатных шаблонах, но которая была бы в АВС
.
В 6-ке появились "триггера" и "бизнесс-правила". Что-то я не припомню, где
это еще есть, даже за плату. По делу, мне случилось попользоваться
возможностями ABC, которых нет а легаси, не знаю, как на счет ШВС. Я имею
ввиду возможность наследовать классы файл-менеджера и переопределять его
методы Insert/Delete для поддержания целостности базы. Т.е. примерно то, о
чем я писал. Как минимум, пришлось бы курочить шаблоны и добавлять свои
точки вставки.

WBR, Nick Tsigouro

(Добавление)
а потом делала транзакцию с родительским файлом , потому, как
"пионер с чайником" очень актуален для нас.
Вспомнилась байка про AS400. В одной конторе было замечено, что машина
каждое утро перезагружается. Бригада системных аналитиков нашла причину.
Машина стояла в предбаннике у секретарши, там была всего одна розетка, а
придя на работу секретарша сначала готовила себе термос кофе. ;-)

WBR, Nick Tsigouro
Написал: ClaList(2)
Гость

Сообщение Гость »

:lol:
Написал: Ajra(8)
Гость

Сообщение Гость »

Чем я пользуюсь я отписал в предшествующем посте. Я советовал не
пользоваться а попробовать ;-) Кстати ABC в 5.5 их активно используют. См.
ABFile.clw. Так, что можно сказать, что пользуюсь ;-)
Хм... Ну, буду иметь еще один аргумент против АВС :):):)
Я бы не был столь категоричен. Мне трудно представить себе
высокопроизводительную банковскую систему, которая обойдется без хранения текущих остатков на счетах.
Я останусь в этом месте категоричным. Почему-то мне кажется,
что в банковской системе добавление записи и ее проведение
разнесены в пространстве и времени. Проводка никак не в форме
происходит. И именно нажатие на кнопку "Провести счет" начинается
транзакция и рассчет всех промежуточных итогов и сумм с их
сохранением. После выполнения проводки редактирование
записи с "детями" запрещено.
1. При сетевой работе больше риск возникновения ошибки
"Запись изменена с другой станции".

Остатки ручками _никогда_ не редактируются. Это все равно, что печатать деньги, или красть их из сейфа. Это не банковская операция :)
Эээ.... Мммм... А при чем здесь "ручками"? Вот реальная ситуация:

Машины А и Б работают с одной базой.
А открыла форму, добавила пару детей и ушла курить. Форма открыта.
Б (пока А курит) открыла форму для той же записи, удалила пару детей,
добавила десяток детей и пяток детей отредактировала. Нажала Ок.
А вернулась и нажала Ок. Что получится?
2. Накапливаются ошибки в БД.

;-)
Не смешно. В одном месте заносятся данные, в другом печатаются
выходные документы через N дней (лет?) после занесения. Визуальный
контроль возможен только при анализе порядка суммы. А вот оценить,
что в Итого нет одной-двух позиций очень сложно... И часть документов
гарантированно будет выдана с неверными суммами.
3. Ускорение в обработке родителей сводится на нет п.2.

Остатки хранятся как раз для ускорения обработки детей. Напр. для
выяснения имеется ли на счете необходимая сумма при оформлении платежа.
On fly? Ты списываешь сразу с родителя? Или же ты справочно
сравниваешь с базой промежуточных итогов? Скорее всего, ответ
на этапе работы с записью ребенка типа такого: "Вам может не хватить
денег на счете".
В 6-ке появились "триггера" и "бизнесс-правила". Что-то я не припомню, где это еще есть, даже за плату.
Эт хорошо. Вот только когда та 6-ка еще заработает... :)
По делу, мне случилось попользоваться
возможностями ABC, которых нет а легаси, не знаю, как на счет ШВС. Я имею ввиду возможность наследовать классы файл-менеджера и переопределять его методы Insert/Delete для поддержания целостности базы. Т.е. примерно то, о чем я писал. Как минимум, пришлось бы курочить шаблоны и добавлять свои точки вставки.
Ну да, согласен. Я ведь и с callback экспериментировал как раз из-за
этого... А потом не помню - как, но выкрутился :)

С уважением,
В.Смелик
Написал: ClaList(2)
Гость

Сообщение Гость »

Я останусь в этом месте категоричным.
Тогда приведи пример такой банковской системы.
Я напомню исходный тезис с которым я не согласен:
После выполнения проводки редактирование
записи с "детями" запрещено.
Оно вообще всегда запрещено. Только через исполнение платежных документов.
Более того, есть системы, где эта таблица недоступна никому, кроме серверных
программ.
Эээ.... Мммм... А при чем здесь "ручками"? Вот реальная ситуация:
Я же не говрю, что это не может быть никогда. Я говорю, что есть задачи, в
которых этого не может быть и, соответственно,.проблем с этим нет.
Не смешно. В одном месте заносятся данные, в другом печатаются
выходные документы через N дней (лет?) после занесения. Визуальный
контроль возможен только при анализе порядка суммы. А вот оценить,
что в Итого нет одной-двух позиций очень сложно... И часть документов
гарантированно будет выдана с неверными суммами.
Это действительно не смешно, а очень смешно. Как же по твоему работают
банки? В одном месте (в банке плательщика) заносятся данные и рождаются
документы, а в другом месте (в банке получателя) "через N дней" печатаются
выходные документы и изменяются счета. Визуальный контроль может провести
только комплексная ревизия УБЭП или налоговиков.
On fly?
Разумеется. Банковская транзакция еще много чего может сделать. Например,
при выдаче наличных проверить наличие необходимой суммы в кассе. Стандартная
банковская транзакция по которой оценивают производительность банковских
серверов и систем содержит около десятка запросов к базе.
Ты списываешь сразу с родителя? Или же ты справочно
сравниваешь с базой промежуточных итогов? Скорее всего, ответ
на этапе работы с записью ребенка типа такого: "Вам может не хватить
денег на счете".
Да нет. Либо деньги есть и тогда платежка принимается, либо их нет, и тогда
ее максимум можно выставить на инкассо.
Ну да, согласен. Я ведь и с callback экспериментировал как раз из-за
этого... А потом не помню - как, но выкрутился :)
И все-же:
Хм... Ну, буду иметь еще один аргумент против АВС :):):)
? :):):)

WBR, Nick Tsigouro
Оно вообще всегда запрещено. Только через исполнение платежных документов.
Более того, есть системы, где эта таблица недоступна никому, кроме
серверных
программ.
Вот на этом и остановимся. Похоже, мы с тобой разошлись в
терминах. Я имел ввиду именно динамические суммы, т.е. те,
которые рассчитываются во время заполнения формы отец-сын
и хранятся в самом отце. Плюс дополнительное условие: отец
может одновременно попасть под редактирование с нескольких
клиентов. Ты же, на сколько я понял, говоришь о системе, где
используются длинные транзакции. Шаблоны же длинные транзакции
без специального изощренного программирования не поддерживают.
Т.к. для них нужен захват на уровне записи.

Если же реализован захват записи, то больших проблем нет.
Помнится, в листе был алгоритм организации длинных транзакций.
Это действительно не смешно, а очень смешно. Как же по твоему работают
банки? В одном месте (в банке плательщика) заносятся данные и рождаются
документы, а в другом месте (в банке получателя) "через N дней" печатаются
выходные документы и изменяются счета. Визуальный контроль может провести
только комплексная ревизия УБЭП или налоговиков.
Дык. Опять же здесь работают транзакционные протоколы,
механизмы акцептования и контроля выполнения этих транзакций.
> ? :):):)
В ШВС я callback на файловые операции не встречал.

С уважением,
В.Смелик

(Добавление)

Здавствуйте!
По делу, мне случилось попользоваться
возможностями ABC, которых нет а легаси, не знаю, как на счет ШВС. Я
имею
ввиду возможность наследовать классы файл-менеджера и переопределять его
методы Insert/Delete для поддержания целостности базы. Т.е. примерно то,
о
чем я писал. Как минимум, пришлось бы курочить шаблоны и добавлять свои
точки вставки.
Nick, мне кажется ты того, сгущаешь :-). Слово "курочить" как-то режет глаз.
Одна строка для точки вставки и распределенный шаблон. Если придерживаться
определенных соглашений при проектировании БД, то и кода совсем немного.

С уважением,
Вячеслав Черников support@finsoft.ryazan.ru

(Добавление)

О чем речь - исправить, как пару байтов переслать. Геморрой начинается когда
выходит апгрейд шаблонов и все эти бесчисленные внедрения в 1-2 строки нужно
перетащить в новую версию. Ну, а если говорить про последние версии, то
апгрейд просто не встанет на правленные шаблоны. Вот за что я полюбил ABC,
это еще и за то, что мне ни разу не пришлось править шаблоны. На все что мне
нужно хватило виртуальных методов и собственных шаблонных довесков.

WBR, Nick Tsigouro

(Добавление)
Вот за что я полюбил ABC,
это еще и за то, что мне ни разу не пришлось править шаблоны. На все что
мне
нужно хватило виртуальных методов и собственных шаблонных довесков.
Ну дык ты сам недавно уверял, что _шаблоны должны быть свои_. Я даже поверил
:).
Да и нет там бесчисленных внедрений в 1-2 строки. Пока нашел в ШВС только
два места, где реально нужны были дополнительные точки вставки.

С уважением,
Вячеслав Черников

(Добавление)

И ШВС творчески под себя переработал? Молодец !!! ;-))))))
Да и нет там бесчисленных внедрений в 1-2 строки. Пока нашел в ШВС только
два места, где реально нужны были дополнительные точки вставки.
Я вообще-то стандартные легаси больше имел ввиду.

WBR, Nick Tsigouro

(Добавление)
Вот на этом и остановимся. Похоже, мы с тобой разошлись в
терминах.
Похоже.
Я имел ввиду именно динамические суммы, т.е. те,
которые рассчитываются во время заполнения формы отец-сын
и хранятся в самом отце. Плюс дополнительное условие: отец
может одновременно попасть под редактирование с нескольких
клиентов. Ты же, на сколько я понял, говоришь о системе, где
используются длинные транзакции.
Я говорю о системе в которой во имя производительности есть избыточность в
данных и соотв. есть задача подержания информационной целостности (II). А
транзакции - это инструмент решения этой задачи. В том, что ты
рассматриваешь тоже есть избыточность, и вопрос в том, как обеспечить II при
наличии такого звена, как человек. Решений м.б. много и задача решаемая.
Шаблоны же длинные транзакции
без специального изощренного программирования не поддерживают.
Шаблоны II вообще не поддерживают. Тут либо ручки, либо свои шаблоны.
В ШВС я callback на файловые операции не встречал.
Так не было этого оператора, когда ядро ШВС создавалось. Я думаю, что и
интерфейсов ты там не найдешь ;-)

WBR, Nick Tsigouro
Написал: ClaList(2)
Ответить