Гаджимурадов Рустамfraks> Таким образом, мне не нужны ни родные датасеты

Сразу из запроса в свой массив засасываешь что ли?
А синхронизация как тогда? Или после каждого
изменения процедура повторяется с нуля?





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




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

Иногда работаю по другому - получил записи, сложил в буфер, добавил/убавил, поредактировал в буфере же. И потом по результатам редактировая уже иду по массиву и выполняю insert/update/delete.

Все достаточно прямолинейно.

Вся эта музыка занимает примерно 200кб на паскале.
Код непригоден для публикации т.к. тут же закидают какахами, однако для внутреннего применения у меня уже работает более 10 лет, естественно с заточками под очередные нужды.

У полей массива есть форматирование, можно делать форматы не извращаясь на сервере.
И минимальные возможности раскраски - для всей строки: цвет, стиль шрифта, цвет фона

Сортировка данных кликом на шапке грида (одна или более колонок), ненужные поля можно скрывать.
Не сделано фильтрации, не запоминается позиция колонок, но не особо пока и требовалось...
Запоминается ширина колонок.

В гриде Романа Мочалова можно было делать многострочные заголовки колонок, можно было делать выравнивание заголовков, в VTV этого нет, или не из коробки.

Гаджимурадов Рустамfraks> procedure TFrmBase.F5;
fraks> CDV.RowSavePosition;
fraks> CDS.ExecSelect(QSel);
fraks> CDV.Sync;
fraks> CDV.RowRestorePositionID;
fraks>
fraks> После редактирования в большинстве случаев обновляется весь
fraks> буфер, процедурой F5, и позиционируемся на ту же запись где были.

Понятно, спасибо.

fraks> Сортировка данных кликом на шапке грида (одна или более колонок)

А сортировку как делаешь, тоже полным рефрешем?


Нет, сортировка которая у меня делается по клику на хедере - она выполняется сугубо на клиенте.
У меня массив CDS сделан на основе TList, а сортировка - через его QuickSort. Пришлось написать только свои компаре в соответствии с типом данных, направлением сортировки и набором полей сортировки.
Это в моих CDS/CDV поведение по умолчанию, ничего дополнительно делать не нужно, сортировка всегда есть "искаропки".

Если нужна именно серверная сортировка - то это программируется отдельно, но это нужно в единичных случаях.

Так же в Popup меню грида/дерева достраиваются пункты меню

- "Сохранить в файл" DBF/XLS/CSV
- Поиск по подстроке

К хедеру грида автоматичски цепляется попап-меню, в котором по правой кнопке мыши открывается:

- список Caption полей в CDS, поставив/убрав чекбокс можно показать/скрыть поле в гриде
- список Name полей CDS, с указанием типа данных

Так же в прилинкованный к CDV статус-бар в первую панель выводится количество записей, во вторую - время выполнения запроса, если данные в CDS попали через CDS.ExecSelect

Еще в моем CDS сделан поиск по полю, на равенство. Если по этому полю сделана сортировка то поиск ведется не перебором а "половинным делением", если не ошибаюсь в названии метода. Соответственно, никаких иных словарей мне не требуется, у меня свой есть, с неограниченным количеством полей.

ёёёёёВ fib+ датасет шикарный, и поиск есть "асинхронный", и локальный фильтр, и экспорт-импорт, и т.д.

Это все появилось позже, кроме того - он именно что датасет, а мне эта парадигма категорически не нравится.
И по разборкам с фибами - нужно потыкаться в кучу мест, сделать какие-то тесты, поспрошать по форумам что бы понять как с ним толком работать, учесть все его фичи. Если мне нужно немногое - то проще сделать самому и не разбираться с чужим. избыточным для меня кодом.
В свое время просил сделать FIBLite - где есть только базовые вещи, типа как в UIB, и отдельным пакетом все датасеты и прочее.
Но было понятно что едва ли авторы возьмутся за такое глобальное разделение при минимальном спросе.
Я бы купил Lite, за полную цену фибов. Но нету такого.

Гаджимурадов Рустамfraks> Нет, сортировка которая у меня делается по клику
fraks> на хедере - она выполняется сугубо на клиенте.
fraks> У меня массив CDS сделан на основе TList

Подожди, а этот твой брифкейс - он для всех наборов данных, даже
для больших? Или ты всегда принудительно ограничиваешь First 1000 ?


Гугление про "брифкейс" дало понимание что речь про барсетку :)

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

При этом, при реальной нужде я без проблем получаю туда и 50 и 100 тысяч записей.
К примеру формирование прайса. Во временной таблице на сервере колдую над включением/исключением товаров по различным условиям, получаю там список ID и потом сджойнив все это дело тяну на клиента в CDS. Потом уже на клиенте делаю некотрые удобные агрегаты, типа суммы по издательствам, и оттуда уже делается экспорт в файл нужного формата.

Работает мой CDS весьма быстро и 1000 записей - не является для него "большой выборкой". На фоне самого фетча расходы на CDS незаметны.

К примеру, получение справочника авторов, формата ID, NAME,
47 тысяч записей, занимает 0,359сек

Используем на работе стороннюю программу для работы с заказами, так получилось что она написана на Delphi + Firebird.
Но в Delphi применены какие-то компоненты с красотами, блэкджеком и прочим.
Я лезу у ту же базу и получаю оттуда те же данные.
Чужая программа делает это за 2-3 секунды, моя - за 0,1сек.
Как так можно тормознуть работу - не понимаю. Наверное там развесистый датасет, визуальщина, красоты, фильтры и проч.
Но нафига это все такой ценой?

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


Вопрос в том что у пользователя не должно быть возможности ослаблением фильров, при всем желании, получить 100 тысяч записей.
У меня такое возможно только если в журнале документов поставить фильтр не 10 дней а 5000 дней.
В остальных местах никаких сотен тысяч не получается.

И не понял, что такое "серверный" вариант?
Если про сортировку - то естественно, запросы выдают результат уже изначально сортированный в наиболее применимом варианте сортировки. И если пользователю вдруг понадобится посмотреть не совсем стандартное, например максимальная сумма документа - то достаточно отсортировать по сумме.