поля фильтра на главной форме или в заголовке ленточной, ограничивающие набор источника данных

критерии для накладных:
год, месяц, отдел, агент, склад, тип товара

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

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


начет фильтрации на сервере - однозначно

для MDB подойдет процедурка генерации динамической строки запроса для источника данных формы на основе значений полей фильтра


есть прикольная конструкция для ADP
главная форма с полями фильтра - одноименными входным параметрам хранимки для подчиненной формы. поля связи главной и подчиненной - пустые

при изменении значения в поле фильтра обновляется содержимое подчиненной формы само по себе , без кода.

неожиданный эффект что текущая запись в подчиненной форме при такой конструкции остается на том же положении (не перескакивает на 1)

Call SaveSetting(Left(CurrentProject.NAME, Len(CurrentProject.NAME) - 4), "NAKLADNAYA", "LastEntredFilterDate", DateValue)


первый параметр - имя проекта
второй тип документа или формы
третий название параметра

на мой взгляд параметров более чем достаточно чтобы разделять ссылки при перелинковке.

хотя если используется динамическая перелинковка к разным базам возможно и в базах удобственнее...

Наоборот хорошо - каждому юзеру свои настройки а если ты выполняешь роль первого юзера то и входи в систему под его логином