TDataSetProvider

← →
Yan (2003-05-26 00:52) [0]

Есть такая проблемма: имеется некоторое клиентское приложение на котором расоложены TClientDataSet ы, которые посредством TDataSetProvidera имеют доступ к некоторым таблицам. Если в таблицах там больше ста полей больше 1000 записей то загрузка данных с сервера занимает примерно 24 сек, на 3-м пне (900Мгц). Штуки с PacketRecords не подходят. Есть варианты как можно ускорить процесс передачи данных?

← →
Digitman (2003-05-26 09:29) [1]

> Есть варианты как можно ускорить процесс передачи данных?

Оптимизируй запрос, возвращающий клиенту набор данных. Тот самый, что использует TDataSetProvider. Возможно, в БД следует либо создать необходимые индексы либо посторить SQL-выражение таким образом, чтобы оно задействовало уже существующие (нужные в контексте запроса) индексы.

А TClientDataSet здесь, скорей всего, ни при чем.

← →
Vassiliy (2003-05-27 09:09) [2]

Какие у Вас компоненты доступа к БД? Используете ли Вы связь Master-Detail?

← →
Yan (2003-05-27 19:43) [3]

Индексы в интеребейсе по длинным текстовым полям не построишь. Дело в том, что запрос сам по себе на сервере выполняется 2 сек. я проверял. Но вот процесс передачи очень долгий почему-то. Я вообщем то нашел выход. Сделал еще одного провайдера и запрос, который вибираетт записи по 3-м четырем полям, грузится гораздо быстрее. Но дрежать вда провадейра как-то не охота. Проблемма именно со скоростью передачи данный от провайдера к клиентдатасету.

← →
Zacho (2003-05-27 20:11) [4]

> Yan (27.05.03 19:43)
> Индексы в интеребейсе по длинным текстовым полям не построишь.
> Дело в том, что запрос сам по себе на сервере выполняется
> 2 сек. я проверял. Но вот процесс передачи очень долгий
> почему-то.

До хрена данных передается, потому и долгий. И будь у тебя хоть Оракл, хоть DB2 - но если резалтсет большой - будет он долгий. И дело тут не в тактовой частоте процессора. Оптимизируй запрос. Выбирай столько записей, сколько реально нужно, не больше. Все равно юзер не сможет нормально работать с гридом с несколькими тысячью записей.

← →
Yan (2003-05-27 23:09) [5]

Ок. А что тогда делать если к этому гриду прикручен поиск и главное и есть случаи, когда надо искать среди всех записей?

← →
Zacho (2003-05-27 23:24) [6]

> Yan (27.05.03 23:09)

Делать поиск другим способом. Как именно - зависит от особенностей задачи.
Например, для поиска по всем записям - отдельная форма. И сначало SELECT COUNT .. Если кол-во записей больше нескольких десятков (в крайнем случае - сотен, хотя уже со 100 записями в гриде работать крайне неудобно) - пусть пользователь уточнит параметры поиска. А если хочет видеть охрененное кол-во записей - то он ССЗБ (Сам Себе Злобный Буратино) и пусть ждет, пока они все зафетчатся на клиента.

← →
Yan (2003-05-28 01:18) [7]

← →
Zacho (2003-05-28 01:40) [8]

> Yan (28.05.03 01:18)

Это только один из множества вариантов. Все зависит от задачи. Главное - спроектировать приложение так, что бы на клиента выбиралось минимум записей. Точнее, чтобы интерфейс к этому распологал :-) Но, как известно, можно сделать защиту от дурака, но изобретательный дурак всегда сможет ее обойти :-) Но если это будет оговорено в инструкции, а пользователь возмущен медленной работой приложения - то он ССЗБ

← →
Danilka (2003-05-28 07:44) [9]

Судя по всему, надо оптимизировать не только кол-во записей, но и кол-во полей: "больше ста полей" - это круто! только реально юзеру не нужно.
В гриде ему наврядли нужно больше 2-6 полей, а остальное он может получить открыв интересующую запись в отдельной форме.

TDataSetProvider Найти похожие ветки