Дублирование FlowField

[Nataly]

У меня такая ситуация, что поля FlowField стандартной таблицы необходимо использовать при вычислении поля FlowField в другой (моей) таблице. Это естественно не позволяется. Была мысль создать в этой стандартной таблице дублирующие поля, только с типом Normal, вот только не понятно в каком триггере надо написать копирование в них значений из FlowField.
Подскажите как обойти такую проблему

[Глазков]

Обычно это решается тем, что и новые flowfieldы считаются по тем же исходным данным, что и старые. Например, баланс по клиенту считаетс по detailed client ledger, а не по client ledger.
То как Вы хотите решать эту задачу на мой взгляд непродуктивно (а может, и невозможно)

[Nataly]

Но разве в CalcFormula можно использовать более одной функции, и вообще какое-либо сложное выражение?

[Глазков]

Неужели понадобилось что-то сложнее Sum или Lookup? :-)

Правильно ли я понимаю схему данных:
MasterTable <-->> Entries <->> SubEntries
где <->> = связь один ко многим?
Если да, то, на самом деле, не хватать может только полей в SubEntries по которым необходимо фильтровать информацию для получения flowfield в MasterTable.
Т.е., например в Entries есть дата, а в Subentries она не повторяется (типа привет сторонникам нормализации -- ссылка по номеру на Entries и хватит :-)). Решать эту проблему в Attain надо введеним недостающих полей в SubEntries. Особенно, если это неизменяемая таблица -- тогда и тригера не придется писать на изменение Entries.

[Nataly]

В общем и целом все так. Но ведь Вы тоже предлагаете добавить поля. И это не очень рационально. К тому же мало просто их добавить, надо обеспечить заполнение полей. В моем случае это выливается в правку весьма непростых процедур учета документов и т.п.

--------------
Спасибо, что откликнулись

[Глазков]

Ну да, поля все равно добавлять.
В пользу предлагаемого мной решения говорит то, что так сделано в Navision везде, а так, как предлагете Вы -- нигде, или м.б. почти нигде.
Подозреваю, что Вашим способом тригер надо вешать на insert/delete/modify записи. При этом необходим все равно будет смотреть процедуры учета, чтобы убедиться что записи добавляются с вызовом тригера. При том, если когда-нибудь кто-то напишет маенький отчетик по исправлению данных в Subentry Вам придется написать свой маленький отчетик по исправлению последствий первого маленького отчетика.

А вообще-то я не программист -- так что здоровый скепсис по поводу этого совета может быть не лишним

[Nataly]

Да, вообще то Вы правы ... навешивание тригера на insert/delete/modify записи совсем не интересно. Но и залезание в стандартные процедуры мне совсем не улыбается. Я все-таки пошла по своему пути, а копирование данных их FloeField в дублирующие поля произвожу непосредственно перед использованием нужных мне данных. Это конечно не очень то рационально, но для программиста наиболее просто.

Спасибо за дискуссию. В споре рождается если не истина, то хотя бы неплохие решения точно.

[nov]

Присоединюсь к мнению господина Глазкова: в Navision нет возможности создавать
FlowField на базе других FlowField(тут вы правы) - наверное это плохо... Но если
этого нет - то не надо это изобретать! Самое худшее, что можно придумать - это
создать свои поля и заполнять их каким-либо(хм!) образом из FlowField. Самый правильный путь увы один - стройте свои поля как FlowField на базе детальных
таблиц, добавляйте поля, ключи что угодно - это правильный механизм.

С уважением,