Подскажите пожалуйста еще, у меня на форме контейнере есть еще и третья подчиненная форма, записи в которой отбираются исходя из первых двух. Критерии на картинке. При обработке события по текущей записи поля IDZAK, TypeID, iKF сохраняются в соответствующих полях формы контейнера и использование их в дальнейшем для задания критериев отбора не представляет проблемы. Однако что касается поля iKOD ...
По замыслу форма cldRequestContent_Buh показывает детализацию содержания конкретного документа из cldRequest_Buh. А вот в третьей форме идет подсчет суммарного количества выписанных материалов/запчастей и сравнение их с нормативом. Хочу сделать так что бы каждая отображаемая запись в ней соответствовала соседней в cldRequestContent_Buh.

То есть получится запрос типа


Как достать вот эти данные (перечень iKOD) высвечиваемые в данный момент, из рекордсоурса формы cldRequestContent_Buh? (собственно все iKOD содержащиеся в рекордсоурсе).

П-ЛМодифицируйте источник правой нижней формы так, чтобы туда вошли те параметры, которые определяют iKOD левой формы (сделать их невидимыми). И тогда для нее подойдет то же условие фильтрации, что и для левой нижней формы. Ведь по смыслу содержание и левой и правой нижней формы у вас определяются текущей строкой верхней мастер-формы.



Тут есть проблемка :(
Я вообще эту всю возню затеял что бы уйти от того монстрообразного запроса, если помните таковой. Ну и параллельно интерфейс сменить. От запроса уйти удалось, все несколько проще стало. Однако добавить к полям 3-ей формы определяющее поле то же что и для второй субформы - iRequest пока толком не получается. Запрос тоже весьма тяжелый получается, действует очень медленно, да и выдает ... несколько больше чем должен бы. Раз в десять. Понятно что где то ошибка в запросе, но легче он от того не становится, скорее еще сложнее и медленнее станет если дополнительные join ы делать.

Хотя там все равно где то у меня ошибка в логике. Чувствую что что-то не так, но понять что и где пока не понимаю. Третья субформа (правая нижняя) по сути есть производное первых двух. Точнее сам запрос является производным от первых двух таблиц (плюс норматив). В этом запросе производится суммирование по критериям (IDZAK, TypeID, iKF) если добавить туда iRequest то смысл теряется, производится суммирование в пределах одного документа, а это мне совсем не надо. В то же время добавить iRequest позднее ... получается масло маслянное, да еще и тормоза дикие ... собственно вернулся к началу сообщения.

П-Л,

Ну а как? Ну вот смотрите, тут все построение достаточно просто. Имеется две таблицы:
tblRequest_Buh - документы на списание материалов/запчастей ("требование"), с полями (указываю только существенные):
IDZAK - номер заказа (конкретный агрегат, машина на ремонт которой производится списание)
TypeID - ИД типа агрегата (по типу совместно с ИД элемента производится поиск нужной записи в нормативе)
iKF - ИД цеха который производит списание материалов/запчастей.
iRequest - PK документа
Поля с датой документа и пр. опускаю, так как сейчас не существенно.

Вторая таблица:
tblRequestContent_Buh - как видно из названия состав документа - перечень материалов/запчастей выписываемых конкретным требованием.
iRequest - FK ссылка на первую таблицу.
iRequestContent - PK
iKOD - ИД запчасти/материала
CNT - количество списываемого материала/запчасти.


Так как один и тот же материал/запчасть может быть выписан на ремонт изделия не однократно в течение ремонта, а мне нужно знать сколько было списано всего, и сравнивать это с нормативным количеством делаем запрос:
qrySumZeh - суммарное количество материалов списанных на ремонт изделия конкретным цехом.


Вот они те самые три поля. Я не могу запихать в запрос ИД iRequest - иначе суммирование будет не по изделиям и цехам, а в пределах одного документа :(

Затем уже в форме выводим таблицу tblRequest_Buh - для выбора конкретных документов которые проверяю по работе т.е. физически (приносят в рулонах бумаги распечатанные)
таблицу tblRequestContent_Buh - для проверки построчно что и сколько конкретно выписывали.
и запрос qrySumZeh для проверки того сколько вообще было списано материалов/запчастей в ходе ремонта данного изделия.

Пример несколько упрощенный, что бы не перегружать деталями. Но все что имеет значение в рамках этой задачи здесь есть. За рамками остались таблицы нормативов (норматив включается в запрос qrySumZeh - что бы тут же и сравнить). А так же запрос qrySumIzd аналогичный первому, но выводящий сколько было списано материалов/запчастей вообще (всеми цехами) на ремонт изделия.

Ну и как в этот запрос qrySumZeh, являющийся основой третьей формы включить ключевое поле iRequest?

Изерлонер
Ну и как в этот запрос qrySumZeh, являющийся основой третьей формы включить ключевое поле iRequest?

Я его пытался включить запросом:



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

П-Л,

П-Л,

ну... светлое будущее не за горами. Разномастные имена полей – наследие внешней базы, ну и некоторых моих первоначальных попыток что то сделать.
Внешняя база практически полностью переработана. Создана ответная система таблиц с «нормальными» обозначениями полей (правда таки не очень понятными было поле NUM стало iNum, как бы промежуточный вариант), составные ключи исключены, везде ключ автосчетчик. Так что работа идёт по тихоньку. .. красоту наводить это конечно хорошо, но ведь ещё и работа есть, и эта база мне прежде всего для работы и нужна. Так что приходиться идти на компромиссы :(
поля IDZAK, iKF, iKOD, TypeID являются FK на соответствующие сущности. ... Ну не выкладывать же мне сюда всю базу в самом деле :( это только к ещё большей путанице приведёт.

Изерлонер,

половину полей внешней базы я даже находясь здесь и имея возможность изучить ... вообще не понимаю что это такое и зачем. Тупо переношу в свою базу в ответные сущности по принципу ... ну а вдруг там полезная информация, которая мне ещё пригодится.

ИзерлонерПНу не выкладывать же мне сюда всю базу в самом деле

ответная переработанная схема внешней БД если это поможет :(.
Предвосхищая вопрос «х/з» это «хрен знает». Перенесенное поле значение которого мне пока не известно, но по сути для меня значения не имеет.

IDZAK, TypeID входят в tblRequest_Buh на следующем этапе. По сути в рекордсорсе не таблица, а запрос qryRequest_ Buh.

Сделал я то чего добивался. субФормочки обновляются, таблички отфильтровываются и запихиваются в рекордсоурс. Все выглядит страшненько пока конечно, но работает.
Вопрос: вот есть рядом две подчиненных формы, записи в них соответствуют друг другу и установлены друг на против друга, одна субФорма является продолжением второй.
Возможно ли, в случае если записей довольно много и в форму это все не вмещается, при прокрутке записей (мышкой, бегунком ли) синхронно прокручивать записи в двух (трех) субформах? Где копать?