На форме F0 две подчиненные табличные формы F1 и F2.
F1 связана с F0, а F2 с F1 посредством свободного контрола на F0, значение которого равно ключу F1 и определяет условие выборки F2.

При изменении значения параметра в строке F1 значение F1.Subtotal (по строке) должно пересчитаться и замениться.
При изменении значения параметра в любой строке F2 значение F1.Subtotal (по строке) также должно пересчитаться и измениться, поскольку значение каждой строки F2 косвенно влияет на сумму в родительской записи F1.
Косвенное влияние можно определить как сумму факторов цены по всем строкам F2. Для вычисления суммы факторов помещаю в footer f2 поле sumFactors (=sum(costFactor)). А по sum(f1.SubTotal) потом считается f0.total, но до этого я еще не дошел.

Пытаюсь реализовать пересчет через функцию, которую помещаю в свободный модуль.
Что-то вроде (сильно облегченный вариант):


Вызываю эту функцию и из afterupdate f1.Quantity (Me.SubTotal = NewSubTot()), и из afterupdate f2.costFactor (Me.Parent!f1.Form!SubTotal = NewSubTot()).

Ну, вобщем, плохо работает. Т.е. совсем не работает. Подозреваю, что к моменту пересчета не успевают пересчитываться то ли сумма sumFactors, то ли еще что, то ли Dirty не вовремя. То ли я синтаксис не разумею. Переписывал пути доступа по-всякому - получал ошибки всегда, все время разные.
Может, у кого-то есть готовый рецепт, как такую конструкцию реализовать, чтобы она всегда работала? Access 2000.

?

Ну может, все-таки ?

2Geo

Прощаю и понимаю. ;-)) Действительно, беда моя в том, что я даже не смог четко сформулировать мой вопрос. При этом точно знаю, что хочу получить, и даже знаю, как это сделать в FoxPro, например.

Попробую представить ситуацию более "в лицах". (Это еще не вопрос. Это чтоб было понятнее, о чем речь.)

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

Форма F0 - это данные о "шапке" заказа. Совсем обычное дело. Номер заказа. Кто заказывает. Когда хочет получить выполненный заказ.
F1 - это строки заказа. Тоже пока все понятно. В заказе может быть много работ. Количество возможных типов работ ограничено (пусть только 2 типа: "Печать" и "Переплет"). Тип работы выбирается из списка. У работы данного типа есть обязательные характеристики (которые присущи всем работам) - это, например, количество копий и формат бумаги.
А вот в F2 начинается интересное. это некая специфика, связанная со строками. Пусть заказчик заказал печать как первую работу и переплет как вторую. Для печати важно 1.качество бумаги и 2.будет печать цветной или черно-белой. Для переплета все это неважно, зато важно 1.вид сшивателя (будем ли мы сшивать пружинкой или же гребенкой).
Задача была поставлена таким образом, чтобы всякие дополнительные параметры настраивались на лету, гибко, именно поэтому они перенесены мной в отдельную форму. Эти параметры в конечном итоге определяют цену за одну копию (факторы цены настраиваются, когда я описываю сервисы).

Пусть таблицы-источники данных для этих трех форм для простоты также называются T0, T1 и T2.

Итак, я завожу первую строку заказа в T1. "Печать." После того, как я это сделал (в afterupdate на поле "тип работы"), я добавляю в таблицу T2 две строчки: "Качество бумаги = (по умолчанию) обычное", "Цвет = (по умолчанию) черно/белый". При этом в T1 у меня (по умолчанию) количество копий ставится =1, а размер бумаги ="A4".
Потом я в произвольном порядке меняю параметры по умолчанию как в строке T1, так и в строках T2, которые связаны со строкой T1.

Теперь - (и это все еще не вопрос ;-)) - как это сделано.

T1 содержит поля
SubJobID (PK)
JobID (FK) - ссылается на T0
ServiceID (FK) - ссылается на справочник типов работ
AppPSizeID (FK) - ссылается на справочник допустимых для данного типа работы размеров бумаги
Quantity - количество копий
SubTotal - это то значение (денормализация), которое определяет стоимость работы в заказе с учетом всех ценовых факторов, которые на нее оказывают влияние.

T2 содержит поля
SubJobPVID (PK)
SubJobID (FK) - ссылается на T1
AppTypeID (FK) - ссылается на справочник допустимых для данного типа работ типов дополнительных параметров
AppPropID (FK) - ссылается на справочник допустимых для данного типа работ значений дополнительных параметров
CostFactor - это и есть тот фактор цены, который оказывает влияние на SubTotal (тоже денормализация, на самом деле этот фактор закреплен за значением AppPropID в соответствующем справочнике, но ведь там он со временем может изменяться ;-)).

Теперь перейдем к формам.


Ну а теперь, собственно, вопрос.
F1.subTotal должен пересчитываться и при изменении F1.Quantity, и F1.PaperSize, и при изменении F2.Value (например, в строчке "Цвет" Value меняется с "Ч/Б" на "Цв.", или в строчке "КачБумаги" с "Супер" на "Норм.").

Я хочу формулу расчета SubTotal держать только в одном месте и пишу функцию, подобную той, что привел в первом посте.
И проблемы возникают - а моих знаний акцесса недостаточно, чтобы их даже сформулировать. То T2 теряет связь с T1 (потом восстанавливает), то "у такого объекта нет такого свойства". Подозреваю еще, что access делает расчет вычисляемых полей не в том порядке, который я ожидаю от него. :((
(Например, я только позавчера узнал о роли Dirty - если не сделать Dirty=False в T1, то в T2 нельзя будет добавить записи при создании новой работы ;-))) ).

Поэтому вопрос более общий: вот бы кто из знатоков рассказал, как бы лично он подошел к проблеме расчета t1.subTotal в описанном случае. И что бы он сделал обязательно, а чего бы делать не стал... Или подсказал бы, как такие вещи можно (нужно) отлаживать.

Или даже так: а есть ли в Accessе Select x into varX ? (тогда всю мою бредятину я бы реализовал через запросы и не парился бы ;-))))