Обычные формы. Отборы построителя на форме для множества раздельных запросов #596850

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

Повторю для особо непонятливыхъ - все запросы в коде отдельно! так нужно!

Подсовывать построителю нужный текст?

Ну а проблема в чем? Под каждый запрос делаешь построитель запроса. Во всех построителях задаешь одинаковые псевдонимы полей для отбора. Отбор, наиболее часто используемого построителя, суешь на форму. Для остальных перед получением зпроса отбор очищаешь и заполняешь по отбору основного построителя. При этом общедоступным должен быть только основной построитель. Остальные можно даже пересоздавать по месту вызова...

все запросы сделать через построитель запросов. отбор копировать

мда уж. много кода.. А вот только что еще у меня пришла идея что не все так просто. ПОясню. Сейчас еще круче стала задача (сам придумал) что в этом глобальном отборе будет еще не только отбор по номенклатуре, а например с учетом остатков. Т.е. сейчас пишу отбор по которому юзер сможет отбирать еще номенклатуру которая есть на остатках. И уже по отборам этого запроса будут фильтроваться остальные. Поясню. Загрузка из экселя. Пользователи хотят чтобы программа загружала не весь прайс лист который может быть на сотни тысяч строк товаров, а например только определенные папки (например они из всего прайса продают только часть товара). Плюс еще вот я подумал что полезно будет еще ставить фильтр по загрузке отбирать только ту которая например есть на остатках. или наоборот нет на остатках. Или вообще например загружать только продаваемую номенклатуру. Мысль понятна? Короче в связи со всем этим сейчас решил все таки отдельный запрос сделать для глобального фильтра. Все остальные запросы - поисковые. В случае задания глобального фильтра, синхронизация и загрузка будет происходить только по полученной номенклатуре глоабльного фильтра. ноухау.

Все жто для максимальной оптимизации загрузки прайса поставщика и работы только с нужным товаром.

вижу решение только в выполнении первого запроса. выгрузки товаров в ТЗ и наложении на это ТЗ уже во всех остальных поисковых запросах фильтра.

Изобретатель, копирование отбора это 5 строчек. А твое изобретение будет почем зря жрать оперативку в обычном приложении или перегрузит диски рабочего каталога сервера приложений в управляемом. В то же время не будет жрать ресурсов, а в клиент-сервере еще и за статистику СУБД зацепится. Маня, маня...

в других запросах не будет отборов по остаткам и другим фигням.

Вот в чем фишка. Нужно заранее до выполнения поисковых запросов ограничить вообще поиск всей номенклатуры по запросу в котором будет отбиратся номенклатура с учетом остатков и прочей фигни которая придумается потом. Например считать с прайса только ту номенклатуру которая продавалась и т.п. То есть задача до поиска получить заведомо нужный список номенклатуры, и далее искать уже по нему. При загрузке прайса в сто тысяч строк (представь себе сколько времени займет синхронизация) если нам нужно будет всего получить загрузку 500 позиций, то проще получив их и выгрузив в отдельную. ТЗ далее всем остальным запросам сказать не искать по справочнику а искать только в 500 позициях. Понял??

Таким образом не услоджняя все остальные запросы (не лепя к ним остатки и прочую фигню которую потом пожелают прилепить для фильтра) оптимальным считаю проверку установки отборов, выгрузку в ТХЗ, наложение во всех поисковых запросах ограничение на поиск номенклатуры. супер.

базван еще не пришел? позовите. как подойдет, не хочу пропустить. пока попкорн начну запекать

Сделал! Ура. По прайсу в сто тысяч строк если надо получить из экселевского прайса всего инфо по одной группе ! все за секунды отработало!

Выкладывай, будим тестить.:)

лучше не тз а временную

а так идея норм

Вот шо получилось. с проверкой фильтра. чтобы иной раз не делать запрос всего справочника.

Завтра разойдется как обновление 250 клиентам. Посмотрим чо народ скажет.

Никогда не видел как рабочий процесс разрывает не закрытый менеджер временных таблиц? А зрелище феерическое...

так нужно закрывать

Временные таблицы зло? ;)

Мышьяк отлично избавляет от зубной боли. Главное применять по инструкции. Так у автора эта ТЗ будет жить пока с его поделкой работают...

Семерочника за километр видно...цикл "ДляКаждого" видимо принципиально не используем да?