доброго времени суток!
этот вопрос я задал на http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1037105406&n=1
ответа там не получил.
на всякий случай продублирую его здесь:

Как получив данные из DataSet'а куда-нить их вывести, напр.
в Грид и дать возможность пользователю их сортировать, не обращаясь за этим к серверу, как это сделано, например, в pl sql developer'е, т.е. кликая на столбец вся таблица перестаривается по нему?

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

Здравствуйте Аноним, Вы писали:

А>доброго времени суток!
А>этот вопрос я задал на http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1037105406&n=1
А>ответа там не получил.
А>на всякий случай продублирую его здесь:

А>Как получив данные из DataSet'а куда-нить их вывести, напр.
А>в Грид и дать возможность пользователю их сортировать, не обращаясь за этим к серверу, как это сделано, например, в pl sql developer'е, т.е. кликая на столбец вся таблица перестаривается по нему?

А>задча, по-моему, стандартная, поэтому не хотелось бы засасывать выборку в StringGrid и реализовывать соритировку там.

Не надо этого делать. Сколько строк в датасете?

Здравствуйте Sinclair, Вы писали:

S>Не надо этого делать. Сколько строк в датасете?

Трудно сказать ... м.б. до 2000.
А причем тут это?

Здравствуйте Аноним, Вы писали:

А>Здравствуйте Sinclair, Вы писали:

S>>Не надо этого делать. Сколько строк в датасете?

А>Трудно сказать ... м.б. до 2000.
А>А причем тут это?

Притом что память у клиента может раньше закончится чем его терпение и его с вами сотрудничество

Здравствуйте Klestov, Вы писали:

K>Здравствуйте Аноним, Вы писали:

А>>Здравствуйте Sinclair, Вы писали:

S>>>Не надо этого делать. Сколько строк в датасете?

А>>Трудно сказать ... м.б. до 2000.
А>>А причем тут это?

K>Притом что память у клиента может раньше закончится чем его терпение и его с вами сотрудничество

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

Здравствуйте chia, Вы писали:

C>Здравствуйте Klestov, Вы писали:

K>>Здравствуйте Аноним, Вы писали:

А>>>Здравствуйте Sinclair, Вы писали:

S>>>>Не надо этого делать. Сколько строк в датасете?

А>>>Трудно сказать ... м.б. до 2000.
А>>>А причем тут это?

K>>Притом что память у клиента может раньше закончится чем его терпение и его с вами сотрудничество

C>вспомнил свой логин
C>теперь я не аноним
C>трудно сейчас найти такого клиента, у которого не хватило бы памяти на 2000 записей с текстовыми полями.
C>время же конечно критично, но один раз клиент готов подождать, поэтому и хотелось избежать сортировку на сервере.

Но кушировать ВСЕ данные на стороне клиента не самаю лучшая идея — сегодня 2000 а завтрв гляди и уже 2000000.

Здравствуйте chia, Вы писали:

C>Здравствуйте Klestov, Вы писали:

K>>Здравствуйте Аноним, Вы писали:

А>>>Здравствуйте Sinclair, Вы писали:

S>>>>Не надо этого делать. Сколько строк в датасете?

А>>>Трудно сказать ... м.б. до 2000.
А>>>А причем тут это?

K>>Притом что память у клиента может раньше закончится чем его терпение и его с вами сотрудничество

C>вспомнил свой логин
C>теперь я не аноним
C>трудно сейчас найти такого клиента, у которого не хватило бы памяти на 2000 записей с текстовыми полями.
C>время же конечно критично, но один раз клиент готов подождать, поэтому и хотелось избежать сортировку на сервере.
Вот то-то и оно. Датасет — штука сама по себе динамическая. За время между засасыванием и сортировкой данные могли измениться. Кроме того, если на экран влазит 50 строк, а в датасете 2000, то для показа первой страницы придется выкачать в 40 раз больше данных, чем надо. За каким, спрашивается, хреном? Коннект весьма дорог. Основное время тратится на передачу данных по сети. А если их там будет не 2000, а 2000000? Даже при этих несчастных 2000 записей, сортировка на клиенте станет эффективной только после почти 40 пересортировок. Дальше объяснять?

Здравствуйте Sinclair, Вы писали:

S>Вот то-то и оно. Датасет — штука сама по себе динамическая. За время между засасыванием и сортировкой данные могли измениться. Кроме того, если на экран влазит 50 строк, а в датасете 2000, то для показа первой страницы придется выкачать в 40 раз больше данных, чем надо. За каким, спрашивается, хреном? Коннект весьма дорог. Основное время тратится на передачу данных по сети. А если их там будет не 2000, а 2000000? Даже при этих несчастных 2000 записей, сортировка на клиенте станет эффективной только после почти 40 пересортировок. Дальше объяснять?


злобный Синклер **** ****** Chia ****** в инете
двести тысяч строчик тычет, рассуждает о клиенте
понимает мудрый Синклер полноту паденья Chia
задает вопрос коварный "Объяснить тебе подробней?"

не дай Бог ответить Chia не вопросик сей коварный
мол давай скорее Синклер, объясника мне поскорее...
Налетит тогда наш Синклер, черной молнии подобный
всё расскажет, всё покажет, он ведь добрый... вот везенье!

Здравствуйте Sinclair, Вы писали:

SKIP

S>Вот то-то и оно. Датасет — штука сама по себе динамическая. За время между засасыванием и сортировкой данные могли измениться. Кроме того, если на экран влазит 50 строк, а в датасете 2000, то для показа первой страницы придется выкачать в 40 раз больше данных, чем надо. За каким, спрашивается, хреном? Коннект весьма дорог. Основное время тратится на передачу данных по сети. А если их там будет не 2000, а 2000000? Даже при этих несчастных 2000 записей, сортировка на клиенте станет эффективной только после почти 40 пересортировок. Дальше объяснять?

Отвечю по всем пунктам:

вы пишете: За время между засасыванием и сортировкой данные могли измениться.Это не так. Данные не так динамично меняются.

вы пишете: если на экран влазит 50 строк, а в датасете 2000, то для показа первой страницы придется выкачать в 40 раз больше данных, чем надо.Выкачивать все данные придется в любом случае (ограничение задается на этапе настройки), — так не лучше ли это сделать сразу?

вы пишете: Коннект весьма дорог.Основное время тратится на передачу данных по сети.Согласен.

вы пишете: А если их там будет не 2000, а 2000000?.2000 — это ограничение сверху, — такова специфика задачи.

вы пишете: Даже при этих несчастных 2000 записей, сортировка на клиенте станет эффективной только после почти 40 пересортировок. Это еще почему? Запрос получает набор данных за полчаса, а их сортировка на клиенте займет не более 3 (трех) секунд.Сервер уведомлять об этом совершенно уже не обязательно. Данные берутся из view, перед созданием которого юзаются несколько хр. процедур, заполняющих временные таблицы. Где я не прав — поясните?

Здравствуйте chia, Вы писали:


C>Отвечю по всем пунктам:

C>вы пишете: За время между засасыванием и сортировкой данные могли измениться.Это не так. Данные не так динамично меняются.

C>вы пишете: если на экран влазит 50 строк, а в датасете 2000, то для показа первой страницы придется выкачать в 40 раз больше данных, чем надо.Выкачивать все данные придется в любом случае (ограничение задается на этапе настройки), — так не лучше ли это сделать сразу?
Странно. Что это за "ограничение на этапе настройки"? Вот клиент хочет посмотреть на табличное представление записей. Открывает окошко. Ему показываются первые 50 записей. Зачем заставляеть его выкачивать все 2000 до того, как он захочет на них посмотреть?
C>вы пишете: Коннект весьма дорог.Основное время тратится на передачу данных по сети.Согласен.

C>вы пишете: А если их там будет не 2000, а 2000000?.2000 — это ограничение сверху, — такова специфика задачи.
Не буду утверждать с уверенностью, не зная задачи, но жизнь — штука сложная. Если у вас набор данных фиксирован (например, список настроек приложения), то это уже совсем не датасет. Это что-то другое. Да, в таком случае датасет используется исключительно как низкоуровневый протокол передачи для нереляционных данных. В противном случае любые предположения о количестве записей противопоказаны. Надеюсь, вам удалось застать эпоху проклятий в адрес интеловцев, в свое время из аналогичных соображений сокративших адресуемый диапазон с 4Гб до 1Мб?
C>
C>вы пишете: Даже при этих несчастных 2000 записей, сортировка на клиенте станет эффективной только после почти 40 пересортировок. Это еще почему? Запрос получает набор данных за полчаса, а их сортировка на клиенте займет не более 3 (трех) секунд.
Это очень странно. Что же это за задача, при которой сервер готовит 2000 [i]редко изменяющихся записей за полчаса? Похоже, здесь вкралась какая-то ошибка проектирования. Я никак не могу придумать такую ситуацию. В моей практике время передачи данных по сети всегда(или почти всегда) много больше времени подготовки результата на сервере.

C> Сервер уведомлять об этом совершенно уже не обязательно. Данные берутся из view, перед созданием которого юзаются несколько хр. процедур, заполняющих временные таблицы.[/i] Где я не прав — поясните?
В тот момент, когда каждый раз при обращении к серверу полчаса выполняются хранимые процедуры, которые почти всегда возвращают одинаковый результат. А что, завести таблицу под эти результаты никак нельзя? И зашедулить выполнение этого страшного запроса на ночное время, с потребной регулярностью?

Здравствуйте Sinclair, Вы писали:

S>Странно. Что это за "ограничение на этапе настройки"? Вот клиент хочет посмотреть на табличное представление записей. Открывает окошко. Ему показываются первые 50 записей. Зачем заставляеть его выкачивать все 2000 до того, как он захочет на них посмотреть? фильтр настраивается так что на выходе будет как правило 20-50 записей и этого должно быть достаточно

S>Не буду утверждать с уверенностью, не зная задачи, но жизнь — штука сложная. Если у вас набор данных фиксирован (например, список настроек приложения), то это уже совсем не датасет. Это что-то другое. Да, в таком случае датасет используется исключительно как низкоуровневый протокол передачи для нереляционных данных. В противном случае любые предположения о количестве записей противопоказаны. Надеюсь, вам удалось застать эпоху проклятий в адрес интеловцев, в свое время из аналогичных соображений сокративших адресуемый диапазон с 4Гб до 1Мб?
данные меняются примерно раз в час. это зависит от датчиков, которые сбрасывают замеры в базу, если 1-2 замера не попадет в результирующую выборку, ничего страшного не произойдет. специалистам (клиентам) важен качественный результат.

S>Это очень странно. Что же это за задача, при которой сервер готовит 2000 редко изменяющихся записей за полчаса? Похоже, здесь вкралась какая-то ошибка проектирования. Я никак не могу придумать такую ситуацию. В моей практике время передачи данных по сети всегда(или почти всегда) много больше времени подготовки результата на сервере.
представте себе расчет нейронно-физических пар-в радиоктивных веществ. Насчет проектирования, м.б. вы и правы, но тут уже деваться некуда


C>> Сервер уведомлять об этом совершенно уже не обязательно. Данные берутся из view, перед созданием которого юзаются несколько хр. процедур, заполняющих временные таблицы.[/i] Где я не прав — поясните?
S>В тот момент, когда каждый раз при обращении к серверу полчаса выполняются хранимые процедуры, которые почти всегда возвращают одинаковый результат.
А что, завести таблицу под эти результаты никак нельзя?
можно и но это первое что пришло мне в голову, но после консультации с нашим админом бд, пришли к выводу что лучше сделать вью из-за востребованности порой только части/половины этой таблицы и, достаточно редко ~ раз в месяц.
И зашедулить выполнение этого страшного запроса на ночное время, с потребной регулярностью?
раз в месяц?

вообще-то вопрос был, — как отсортировать данные на клиенте, а не зачем это надо...

Здравствуйте chia, Вы писали:

хъ

C>вообще-то вопрос был, — как отсортировать данные на клиенте, а не зачем это надо...

Видел этот пост на мастаке... Ну если нельзя использовать ADO, используйте TClientDataSet.

Оба имееют возможность (ADO в режиме клиентского курсора) заниматься сортировкой рекордсета в памяти.
Можно и фильтровать там же (на клиенте).

Здравствуйте kig, Вы писали:

kig>Здравствуйте chia, Вы писали:

kig>хъ

C>>вообще-то вопрос был, — как отсортировать данные на клиенте, а не зачем это надо...

kig>Видел этот пост на мастаке... Ну если нельзя использовать ADO, используйте TClientDataSet.

kig>Оба имееют возможность (ADO в режиме клиентского курсора) заниматься сортировкой рекордсета в памяти.
kig>Можно и фильтровать там же (на клиенте).

я использую DOA, а эта утилита является частью большого проекта написаннного с использованием DOA. Поэтому, переход на другую схему работы с БД не резонно.

Похоже, если мой датасет не умеет сортировать локально (а он не умеет), то приедтся релизовывать это вручную, делая наследника от датасета или от средства отображения данных.

Всем спасибо за участие. Вопрос закрыт по причине создания налседника TDbGrid, с требуемыми свойствами

Здравствуйте chia, Вы писали:

C>Здравствуйте kig, Вы писали:

kig>>Здравствуйте chia, Вы писали:

kig>>хъ

C>>>вообще-то вопрос был, — как отсортировать данные на клиенте, а не зачем это надо...

kig>>Видел этот пост на мастаке... Ну если нельзя использовать ADO, используйте TClientDataSet.

kig>>Оба имееют возможность (ADO в режиме клиентского курсора) заниматься сортировкой рекордсета в памяти.
kig>>Можно и фильтровать там же (на клиенте).

C>я использую DOA, а эта утилита является частью большого проекта написаннного с использованием DOA. Поэтому, переход на другую схему работы с БД не резонно.

C>Похоже, если мой датасет не умеет сортировать локально (а он не умеет), то приедтся релизовывать это вручную, делая наследника от датасета или от средства отображения данных.

C>Всем спасибо за участие. Вопрос закрыт по причине создания налседника TDbGrid, с требуемыми свойствами

Хотя Вы тему уже закрыли:

Наследника TDbGrid с возможностью сортировки писать смысла нет. Хотя бы по тому — а если Вам завтра понадобится
TDBListBox с сортировкой?

Исходя из того, что Вы пользуйте стантдартные средства Д — DB-Aware контролы (TDBGrid) и упоминаете "датасет", логично
предположить, что компоненты DOA — это наследники TDataSet. Так вот, я Вам предложил не уйти от DOA для доступа к Ораклу, а использовать возможности "движков" на клиенте ("...то приедтся релизовывать это вручную, делая наследника от датасета..."), которые уже реализованы.

Вот, сравните, что требуется, чтобы устроить сортировку на клиенте с использованием TClientDataSet:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, Grids, DBGrids, Provider, DBClient, DB, ADODB;

type
  TForm1 = class(TForm)
    ADODataSet1: TADODataSet;
    ClientDataSet1: TClientDataSet;
    DataSetProvider1: TDataSetProvider;
    DBGrid1: TDBGrid;
    DataSource1: TDataSource;
    procedure DBGrid1TitleClick(Column: TColumn);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.DBGrid1TitleClick(Column: TColumn);
begin
  ClientDataSet1.IndexFieldNames := Column.FieldName;
end;

end.

В IDE:

DBGrid1.DataSource := DataSource1;
DataSource1.DataSet := ClientDataSet1;
ClientDataSet1.ProviderName := DataSetProvider1;
DataSetProvider1.DataSet := ADODataSet1;

Замените ADODataSet1: TADODataSet на, как он там называется? Типа TDOADataSet?
И пользуйте.

Здравствуйте, kig,

Все именно так, как Вы и написали — только компонент называется OracleDataSet
Именно это мне надо было!
СПАСИБО!

Здравствуйте, _MarlboroMan_, Вы писали:

M>злобный Синклер **** ****** Chia ****** в инете

Рифмоплёт, блин