forum.clarionlife.net

В связи с тем, что я не слишком корректно задал свой вопрос о примере с фильтрацией по группе связанных файлов в топике по C10, прошу немного мне подсказать ещё.
Делаю обычный броуз (несколько), проблема в том, что к нему(к ним) надо красиво и удобно для девушек предусмотреть возможность выбора и установки значений примерно ~20 фильтров, как из справочников так и по отдельным полям связанных файлов, т.е. вполне типичная задача - Картотека. Потом естественно надо полученную выборку из .tps распечатать вместе со значениями выбранных девушкой фильтров. Количество фильтров и их разнообразие собственно и понуждает меня задать вопрос. Хотелось бы посмотреть на современный дизайн и возможное решение такого рода задач в CW.
Понятное дело, что я ещё совсем не ориентируюсь в имеющихся темплейтах для C6.3 поэтому прошу это учесть.
Заранее Спасибо тем кто ответит!

Для начала (т.к. TPS) сообщите количество записей в базе. Сейчас + сколько будет через 1-2 года...

Потом естественно надо полученную выборку из .tps распечатать вместе со значениями выбранных девушкой фильтров. Количество фильтров и их разнообразие собственно и понуждает меня задать вопрос. Хотелось бы посмотреть на современный дизайн и возможное решение такого рода задач в CW

SuperTagging+SuperQbe от BoxSoft - решение самое простое, но при большом колич записей(больше неск тысяч) и при сетевой работе будут тормоза типичные для TPS. Это можно значительно ускорить при через терминальный сервер.
п.с. я лично очень активно использую

sorry, почему-то выпадают целые слова - пишу в походн условиях

Admin писал(а):Для начала (т.к. TPS) сообщите количество записей в базе. Сейчас + сколько будет через 1-2 года...

В файле по которому идёт броуз до 50000 через пару лет, сейчас 35000 и под ДОС хороший или приемлемый темп фильтрации на старых компах. Файлы которые включены в задачу сейчас имеют до 150000 записей, следует ожидать 200-300 тысяч записей, ну а справочники естественно короткие грубо до 50-100 записей наверно. В зависимости от задачи фильтрации выбираются ключи, т.е. тупой перебор записей сводится к минимуму, поэтому Ваш вопрос мне не очень понятен, т.к. это не принципиально.

Прошу заметить, что в вопросе есть слово Дизайн.

morkovin писал(а): но при большом колич записей(больше неск тысяч) и при сетевой работе будут тормоза типичные для TPS.

Не замечал такого даже при работе в сети, правда пользователей было немного, поэтому всё что успевал конвертировал в .tps.

имеют до 150000 записей, следует ожидать 200-300 тыс

и держать это в тпс? и ни разу файл БД не повреждался при активной сетевой работе? Перевести всё на SQL и формировать фильтры через sql-запросы. Я при 25 тыс. записей перешел на sql

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

в вопросе есть слово Дизайн

1. Контролы в browse 2. Нажали кнопку ПОИСК 3. Окно выбора критериев

и результат- выборка

morkovin писал(а):

имеют до 150000 записей, следует ожидать 200-300 тыс

и держать это в тпс? и ни разу файл БД не повреждался при активной сетевой работе? Перевести всё на SQL и формировать фильтры через sql-запросы. Я при 25 тыс. записей перешел на sql

У нас в tps есть таблицы и с несколькими миллионами записей при многопользовательской работе с ними от 20 до 30 пользователей с достаточной долей интенсивности и сложной бизнес-логикой. Разумеется, работа на терминальном сервере. Стоимость легального терминального решения сейчас, после появления продуктов типа tsplus, не напрягает совсем. Поэтому переход на sql не является сейчас технически необходимым в большинстве случаев, больше дела вкуса и особенностей конкретной бизнес-среды, в которой работает приложение.

Тормоза при работе с tps на полном переборе записей в стандартном кларионовском броузе (поиск по фрагментам наименования товаров) был замечен на объеме более 100 000 записей. Связано с частым повторным пересчитываем данных. До этого вполне терпимо, пользователей не напрягало. Сделали специальный режим фильтрации, при котором один раз делается скан по базе, id отобранных записей сохраняются в кьшке, а затем фильтация уже по этой кьшке. Если количество записей большое, то срабатывает разделение на страницы, на подобии интерфейса в вебе. При таком подходе все работает быстро.

Разумеется, работа на терминальном сервере.

Меня привлекает связка UbuntuServer+Wine+ClarionApp+TerminalServer и к этому всему доступ чере TS-клиент с Win- и Lin-компов. Но,увы, нет доступного (для меня) 64-разрядного компа для экспериментов в качестве сервера

morkovin писал(а):

имеют до 150000 записей, следует ожидать 200-300 тыс

и держать это в тпс? и ни разу файл БД не повреждался при активной сетевой работе? Перевести всё на SQL и формировать фильтры через sql-запросы. Я при 25 тыс. записей перешел на sql

Данное приложение работало не в сети, за 18 лет ни одного сбоя не было. Это одна из первых моих задач. Не сомневайтесь, что и в сети было бы точно также, позднее я получил необходимый опыт, ни одного сбоя не было и годовую премию мне выплатили после того как я был сокращён из-за игр с собственностью предприятия.
С SQL запросами я тоже встречался, когда лень разбираться с предметной областью тогда принимают решение обогатить госкорпорацию Микрософт.

Admin писал(а):Дизайн по вкусу, переменные для фильтра хранить в группе. Группу можно передать дальше в процедуру печати для формирования отчета по тем же параметрам что и броуз.

Про вкус понятно, вот только задача достаточно типичная и надеюсь есть уже решения со вкусом под виндой. Их и хочется посмотреть. 20 лет назад я лепил виртуальный экран в два физических и со вкусом расставлял справа в той его части, что сразу не видна доступ к фильтрам...

Можно посмотреть для начала стандартный QBE шаблон. Он, конечно, скорее для показа возможностей, но от него можно отталкиваться. По-любому, думаю, придётся врукопашную делать. Универсальных продвинутых средств я, например, не знаю.