Я от подобного подхода практически сразу отказался. Если используется imdd, то соответствующие структуры прописываются в словаре. Теперь вспомним, что отчёты добавляются и изменяются несоизмеримо чаще, чем структура базы данных. Если в небольших и мало изменяющихся приложениях такой подход особых проблем не создаёт, то в больших и долго играющих становится архитектурной ошибкой. У зарубежных коллег периодически пишут о словарях с 1000+ таблиц, насколько я понял по обсуждения, именно из-за такого подхода.Игорь Столяров писал(а): ↑13 Апрель 2023, 20:08Конечно нет. У нас отчёты в REPORT.
Но есть запросы в которых выполняется некая обработка данных, и результат действительно показан в BROWSE на IMDD.
В таких списках работают все фишки, вроде сортировки по колонкам, Edit-In-Place, масштабирования зоны просмотра LIST,
просмотр карточек, сортировка на закладках, контекстного поиска и т.д. Ну т.е. все возможности штатного BROWSE ABC.
Для ШВС была сторонняя разработка "броуз по очереди". Но она как-то не получила распространения. Подход с универсальной системной таблицей с одним полем ID и индексом по нему выглядит оптимальным решением. С одной стороны, используется стандартный броузер со всем функционалом (кроме сортировки, просто не возникало потребности), и структуры с итоговыми данными определяются локально, а не в словаре.
