Необходимость обновить запись файла, находясь в Form и не вы
Модератор: Дед Пахом
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Здравствуйте!
CW5.5H ШВС
У меня возникла необходимость сохранить изменения записи файла, находясь в ее form'е. У этого файла есть дочерние файлы, таблицы которых открываются в form основного файла, и когда пользователь вносит изменения в дочерние файлы, часть итогов должна сохраниться в полях основного файла, но если пользователь нажимает отмену, то эти итоги естественно туда не попадают. Можно, конечно ограничить его в плане нажатия на отмену в случае изменения дочерних файлов, а может есть способ поэлегантнее?
Написал: Ajra(8)
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)
инсертах и делитах вызываешь процедуру пересчета итогов и организуешь
транзакцию с родительским файлом. Все. Если будешь пользоваться только
методами классов и забудешь про add/put/delete - проблем не будет. А в
шестерке для этого придумали "триггеры" и бизнесс-правила. В 5.5 это можно
попробовать сделать через "хуки" в файловых драйверах:
CALLBACK Register or unregister a FileCallBackInterface.
WBR, Nick Tsigouro. MailTo: Nick@arsis.ru
Написал: ClaList(2)
Или я чего не понимаю, или одно из двух! )
Николай, ты так вообще "застращаешь" коллегу -
в ШВС все можно сделать так-же красиво и аккуратно
как и на ABC, и без всяких колбэков.
Алгоритм для КОНКРЕТНОГО случая:
!!! Следует иметь в виду (да и вообще - полезно знать),
что при входе в форму в режиме редактирования ТЕКУЩЕЕ
содержимое записи автоматом сохраняется в локальной
группе SAV::PRE:Record, где PRE - префикс редактируемого файла.
Если есть еще и MEMO-поле, то оно сохраняется в отдельной
строковой переменной типа SAV::PRE:Notes_Field.
Это - так сказать введение.
- предполагаем, что расчетная сумма по дочерним записям
подсчитываетя автоматически прямо в поле родительской записи,
например PRE:Child_Sum.
- в точке вставки "Конец процедуры до закрытия файлов" пишешь
что-то типа:
Если сумма (суммы) подсчитываются в локальной переменной,
например LOC:Child_Sum, то:
Т.е. вышеприведенный код обновит в родительской записи
ТОЛЬКО поле суммы. Сработает это ТОЛЬКО если эта сумма
изменилась и выход из формы произошел по Cancel.
Если выход нормальный, через Ok, то обновление будет
произведено уже стандартным кодом шаблона.
Вот и все, и без лишних наворотов и сложностей!
Да, и еще!
По этой теме были советы делать что-то подобное уже
после возврата из формы в каталог. Имхо - этого
делать не стоит! Потому что, имхо, это НЕПРАВИЛЬНО!
ВЕСЬ код обработки записи должен быть сгруппирован
прямо в форме, БЕЗ выноса части функционала во вне.
Только так можно обеспечить правильную и стабильную
работу формы В ЛЮБОМ контексте! Вообще, советую
воспринимать формы и подобные им процедуры как
некое подобие "черного ящика", когда ВЕСЬ функционал
находится внутри и НЕ зависит от внешних условий
вызова. За исключением входных данных, естественно!
Удачи!
=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
(Добавление)
ШВС вообше не пришлось.
розетку, и дочки обновились, а папа не успел. Поменяешь пробки - запускай
пересчет итогов по всей базе. Да даже просто кто-то на соседней станции
открыл эту запись и удивился, а чего это там концы с концами не сходятся...
Такие вещи нужно делать во временных файлах/очередях и выливать в базу одной
транзакцией, либо корректиовать родителя на каждом изменении потомка. Опять
же, в одной транзакции.
WBR, Nick Tsigouro
Написал: ClaList(2)
Николай, ты так вообще "застращаешь" коллегу -
в ШВС все можно сделать так-же красиво и аккуратно
как и на 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)
Для случая с накладными мне нравится такой подход. Накладная имеет полеТакие вещи нужно делать во временных файлах/очередях и выливать в базу одной транзакцией, либо корректиовать родителя на каждом изменении потомка.
Опять же, в одной транзакции.
статуса, одно из состояний которого - "утверждена". Утвержденные документы
править запрещается, пока отметка не снята. Утвержденные документы попадают
в финансовые отчеты, а не утвержденные резервируют товар. Итоговые значения
в шапке документа сохраняются только при утверждении. Для неутвержденых
документов рассчитваются в рантайме. Если учесть, что количество
неутвержденных документов невелико, то больших задержек быть не должно.
С уважением,
Вячеслав Черников support@finsoft.ryazan.ru
Написал: ClaList(2)
Здравствуйте!
Про рубильник с пионером очень понравилось. На самом деле, я, как и сказал Николай, после всех add/put/delete делала пересчет всех итогов, которые попадают в поля родительского файла, а потом делала транзакцию с родительским файлом , потому, как "пионер с чайником" очень актуален для нас. Просто оставались сомнения не слишком ли много всяких пересчетов и транзакций.
Спасибо.
Написал: Ajra(8)
Про рубильник с пионером очень понравилось. На самом деле, я, как и сказал Николай, после всех 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)
Написал: Ajra(8)
Все зависит от того, как часто строятся отчеты, которые
используют эти итоги. Если не очень часто, то можно
дописать модуль проверки-коррекции, который следует
запускать перед построением отчетов. Другое дело, если
эти итоговые суммы используются постоянно.
Хотя, и здесь можно обойтись только модулем проверки-коррекции.
Ошибки появляются не каждый день и обычно сразу заметны.
Как заметил оператор такую ошибку - сообщил админу - админ
запустил проверку-коррекцию.
А переписывать - только если ошибки совсем уж замучили.
=============================
С уважением, Олег А. Руденко
(Добавление)
пользоваться а попробовать Кстати ABC в 5.5 их активно используют. См.
ABFile.clw. Так, что можно сказать, что пользуюсь
высокопроизводительную банковскую систему, которая обойдется без хранения
текущих остатков на счетах.
деньги, или красть их из сейфа. Это не банковская операция
имеется ли на счете необходимая сумма при оформлении платежа.
это еще есть, даже за плату. По делу, мне случилось попользоваться
возможностями ABC, которых нет а легаси, не знаю, как на счет ШВС. Я имею
ввиду возможность наследовать классы файл-менеджера и переопределять его
методы Insert/Delete для поддержания целостности базы. Т.е. примерно то, о
чем я писал. Как минимум, пришлось бы курочить шаблоны и добавлять свои
точки вставки.
WBR, Nick Tsigouro
(Добавление)
каждое утро перезагружается. Бригада системных аналитиков нашла причину.
Машина стояла в предбаннике у секретарши, там была всего одна розетка, а
придя на работу секретарша сначала готовила себе термос кофе.
WBR, Nick Tsigouro
Написал: ClaList(2)
используют эти итоги. Если не очень часто, то можно
дописать модуль проверки-коррекции, который следует
запускать перед построением отчетов. Другое дело, если
эти итоговые суммы используются постоянно.
Хотя, и здесь можно обойтись только модулем проверки-коррекции.
Ошибки появляются не каждый день и обычно сразу заметны.
Как заметил оператор такую ошибку - сообщил админу - админ
запустил проверку-коррекцию.
А переписывать - только если ошибки совсем уж замучили.
=============================
С уважением, Олег А. Руденко
(Добавление)
Чем я пользуюсь я отписал в предшествующем посте. Я советовал неХм... Сам-то пользуешься или только советуешь?
пользоваться а попробовать Кстати ABC в 5.5 их активно используют. См.
ABFile.clw. Так, что можно сказать, что пользуюсь
Я бы не был столь категоричен. Мне трудно представить себеIMHO, хранить суммы (динамические) в родителе вообще
НЕПРАВИЛЬНО.
высокопроизводительную банковскую систему, которая обойдется без хранения
текущих остатков на счетах.
Остатки ручками _никогда_ не редактируются. Это все равно, что печатать1. При сетевой работе больше риск возникновения ошибки
"Запись изменена с другой станции".
деньги, или красть их из сейфа. Это не банковская операция
2. Накапливаются ошибки в БД.
Остатки хранятся как раз для ускорения обработки детей. Напр. для выяснения3. Ускорение в обработке родителей сводится на нет п.2.
имеется ли на счете необходимая сумма при оформлении платежа.
В 6-ке появились "триггера" и "бизнесс-правила". Что-то я не припомню, где[...]
PS: Пока я еще не встречал такой вещи, которая была бы мне
нужна для работы (не для понтов) и которой бы не было в ШВС
и бесплатных шаблонах, но которая была бы в АВС.
это еще есть, даже за плату. По делу, мне случилось попользоваться
возможностями ABC, которых нет а легаси, не знаю, как на счет ШВС. Я имею
ввиду возможность наследовать классы файл-менеджера и переопределять его
методы Insert/Delete для поддержания целостности базы. Т.е. примерно то, о
чем я писал. Как минимум, пришлось бы курочить шаблоны и добавлять свои
точки вставки.
WBR, Nick Tsigouro
(Добавление)
Вспомнилась байка про AS400. В одной конторе было замечено, что машинаа потом делала транзакцию с родительским файлом , потому, как
"пионер с чайником" очень актуален для нас.
каждое утро перезагружается. Бригада системных аналитиков нашла причину.
Машина стояла в предбаннике у секретарши, там была всего одна розетка, а
придя на работу секретарша сначала готовила себе термос кофе.
WBR, Nick Tsigouro
Написал: ClaList(2)
Хм... Ну, буду иметь еще один аргумент против АВС :):)Чем я пользуюсь я отписал в предшествующем посте. Я советовал не
пользоваться а попробовать Кстати ABC в 5.5 их активно используют. См.
ABFile.clw. Так, что можно сказать, что пользуюсь
Я останусь в этом месте категоричным. Почему-то мне кажется,Я бы не был столь категоричен. Мне трудно представить себе
высокопроизводительную банковскую систему, которая обойдется без хранения текущих остатков на счетах.
что в банковской системе добавление записи и ее проведение
разнесены в пространстве и времени. Проводка никак не в форме
происходит. И именно нажатие на кнопку "Провести счет" начинается
транзакция и рассчет всех промежуточных итогов и сумм с их
сохранением. После выполнения проводки редактирование
записи с "детями" запрещено.
Эээ.... Мммм... А при чем здесь "ручками"? Вот реальная ситуация:1. При сетевой работе больше риск возникновения ошибки
"Запись изменена с другой станции".
Остатки ручками _никогда_ не редактируются. Это все равно, что печатать деньги, или красть их из сейфа. Это не банковская операция
Машины А и Б работают с одной базой.
А открыла форму, добавила пару детей и ушла курить. Форма открыта.
Б (пока А курит) открыла форму для той же записи, удалила пару детей,
добавила десяток детей и пяток детей отредактировала. Нажала Ок.
А вернулась и нажала Ок. Что получится?
Не смешно. В одном месте заносятся данные, в другом печатаются2. Накапливаются ошибки в БД.
выходные документы через N дней (лет?) после занесения. Визуальный
контроль возможен только при анализе порядка суммы. А вот оценить,
что в Итого нет одной-двух позиций очень сложно... И часть документов
гарантированно будет выдана с неверными суммами.
On fly? Ты списываешь сразу с родителя? Или же ты справочно3. Ускорение в обработке родителей сводится на нет п.2.
Остатки хранятся как раз для ускорения обработки детей. Напр. для
выяснения имеется ли на счете необходимая сумма при оформлении платежа.
сравниваешь с базой промежуточных итогов? Скорее всего, ответ
на этапе работы с записью ребенка типа такого: "Вам может не хватить
денег на счете".
Эт хорошо. Вот только когда та 6-ка еще заработает...В 6-ке появились "триггера" и "бизнесс-правила". Что-то я не припомню, где это еще есть, даже за плату.
Ну да, согласен. Я ведь и с callback экспериментировал как раз из-заПо делу, мне случилось попользоваться
возможностями ABC, которых нет а легаси, не знаю, как на счет ШВС. Я имею ввиду возможность наследовать классы файл-менеджера и переопределять его методы Insert/Delete для поддержания целостности базы. Т.е. примерно то, о чем я писал. Как минимум, пришлось бы курочить шаблоны и добавлять свои точки вставки.
этого... А потом не помню - как, но выкрутился
С уважением,
В.Смелик
Написал: ClaList(2)
Тогда приведи пример такой банковской системы.Я останусь в этом месте категоричным.
Я напомню исходный тезис с которым я не согласен:
Оно вообще всегда запрещено. Только через исполнение платежных документов.После выполнения проводки редактирование
записи с "детями" запрещено.
Более того, есть системы, где эта таблица недоступна никому, кроме серверных
программ.
Я же не говрю, что это не может быть никогда. Я говорю, что есть задачи, вЭээ.... Мммм... А при чем здесь "ручками"? Вот реальная ситуация:
которых этого не может быть и, соответственно,.проблем с этим нет.
Это действительно не смешно, а очень смешно. Как же по твоему работаютНе смешно. В одном месте заносятся данные, в другом печатаются
выходные документы через N дней (лет?) после занесения. Визуальный
контроль возможен только при анализе порядка суммы. А вот оценить,
что в Итого нет одной-двух позиций очень сложно... И часть документов
гарантированно будет выдана с неверными суммами.
банки? В одном месте (в банке плательщика) заносятся данные и рождаются
документы, а в другом месте (в банке получателя) "через N дней" печатаются
выходные документы и изменяются счета. Визуальный контроль может провести
только комплексная ревизия УБЭП или налоговиков.
Разумеется. Банковская транзакция еще много чего может сделать. Например,On fly?
при выдаче наличных проверить наличие необходимой суммы в кассе. Стандартная
банковская транзакция по которой оценивают производительность банковских
серверов и систем содержит около десятка запросов к базе.
Да нет. Либо деньги есть и тогда платежка принимается, либо их нет, и тогдаТы списываешь сразу с родителя? Или же ты справочно
сравниваешь с базой промежуточных итогов? Скорее всего, ответ
на этапе работы с записью ребенка типа такого: "Вам может не хватить
денег на счете".
ее максимум можно выставить на инкассо.
И все-же:Ну да, согласен. Я ведь и с callback экспериментировал как раз из-за
этого... А потом не помню - как, но выкрутился
? :):)Хм... Ну, буду иметь еще один аргумент против АВС :):)
WBR, Nick Tsigouro
Вот на этом и остановимся. Похоже, мы с тобой разошлись вОно вообще всегда запрещено. Только через исполнение платежных документов.
Более того, есть системы, где эта таблица недоступна никому, кроме
серверных
программ.
терминах. Я имел ввиду именно динамические суммы, т.е. те,
которые рассчитываются во время заполнения формы отец-сын
и хранятся в самом отце. Плюс дополнительное условие: отец
может одновременно попасть под редактирование с нескольких
клиентов. Ты же, на сколько я понял, говоришь о системе, где
используются длинные транзакции. Шаблоны же длинные транзакции
без специального изощренного программирования не поддерживают.
Т.к. для них нужен захват на уровне записи.
Если же реализован захват записи, то больших проблем нет.
Помнится, в листе был алгоритм организации длинных транзакций.
Дык. Опять же здесь работают транзакционные протоколы,Это действительно не смешно, а очень смешно. Как же по твоему работают
банки? В одном месте (в банке плательщика) заносятся данные и рождаются
документы, а в другом месте (в банке получателя) "через N дней" печатаются
выходные документы и изменяются счета. Визуальный контроль может провести
только комплексная ревизия УБЭП или налоговиков.
механизмы акцептования и контроля выполнения этих транзакций.
В ШВС я callback на файловые операции не встречал.> ? :):)
С уважением,
В.Смелик
(Добавление)
Здавствуйте!
Nick, мне кажется ты того, сгущаешь . Слово "курочить" как-то режет глаз.По делу, мне случилось попользоваться
возможностями ABC, которых нет а легаси, не знаю, как на счет ШВС. Я
имею
ввиду возможность наследовать классы файл-менеджера и переопределять его
методы Insert/Delete для поддержания целостности базы. Т.е. примерно то,
о
чем я писал. Как минимум, пришлось бы курочить шаблоны и добавлять свои
точки вставки.
Одна строка для точки вставки и распределенный шаблон. Если придерживаться
определенных соглашений при проектировании БД, то и кода совсем немного.
С уважением,
Вячеслав Черников 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)