Медленно выполняется refresh

← →
LDV (2006-06-29 16:45) [0]

В результате перевода базы данных из Paradox на MS Access (желание заказчика) медленно выполняется ADOTable.Refresh.
А в Paradox формате базы данных Table.refresh выполнялся практически мнговенно. В чем может быть причина медленного Refresh в ADO?

← →
Sergey13 © (2006-06-29 16:54) [1]

А все остальное одинаково? Размер БД? По сети или локально?

← →
LDV (2006-06-29 17:17) [2]

Все остальное одинаково. Программа переводилась практически "тупой" заменой Table на ADOTable. В сети еще не пробовал, т.к. при локальном размещении базы - медленно.
Фактически выполняется следующее действие. По событию onEnter на сетку выполняется ADOTable.Refresh чтобы обновить содержимое сетки (естественно сетка только показывает содержимое набора данных). Под BDE это выполнялось практически мгновенно, в под ADO ... Да, таблица содержит "всего-то" 265 записей.

← →
Курдль © (2006-06-29 17:34) [3]

> (естественно сетка только показывает содержимое набора данных).

Это как раз неестественно. Попробуйте ADOQuery.

← →
LDV (2006-06-29 17:53) [4]

Я об этом думал. Но ADOQuery требует практически полного переписывания кода работы с базой данных.

← →
Курдль © (2006-06-29 18:11) [5]

> Но ADOQuery требует практически полного переписывания кода
> работы с базой данных.

НЕ ВЕРЮ!!! (С)таниславский

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

← →
AlexWlad © (2006-06-29 19:33) [6]

> Курдль © (29.06.06 18:11) [5]

Сдается мне, что там селектами и не пахнет (TTable). Фишка в том, что БДЕ сам кеширует данные, а АДО при Табле.Опен засасывает ВСЮ инфу в память. И реализация рефреша, ИМХО, различна для БДЕ и АДО.

← →
LDV (2006-06-29 20:05) [7]

2 Курдль

Сетка, естественно, как и в любом другом случае, только показывает данные. А что она еще может/должна делать? Если в какой-то сетке и есть другие функции (редактирование, добавление, удаление записей), то все равно они делаются с использованием источника данных, назначенного сетке. Rак я понимаю, ADOQuery "умеет" только показывать (выбирать) данные из базы.
А как реализовать (без существенного переписывания кода) функции удаления, добавления записей. Еще раз повторяю, без значительного изменения кода программы!
В моем случае я обошелся, практически, заменой в тексте программы TTAble на TADOTAble.
Может быть надо указать какие-то настроечные параметры TADOTAble? Я не специалист по ADO. Все время работал с Paradox/BDE. А потом перешел на Firebird. Там все по-другому. ADO досталось "по наследству" - уволился человек, занимавшийся этим.

← →
LDV (2006-06-29 20:05) [8]

← →
LDV (2006-06-29 20:06) [9]

← →
Рустем © (2006-06-30 01:28) [10]

> LDV

А если вместо TADOTable.Refresh применить TADOTable.Requery?

← →
sniknik © (2006-06-30 09:55) [11]

> В чем может быть причина медленного Refresh в ADO?
причина в различиях клиент серверного и файл серверного подхода работы с данными. ну и естественно в бездумной замене Table(локальный, файл серверный метод) на ADOTable(даже трудно сказать что это... само ADO это клиент серверный подход... но Table тут притянут за уши без учета этого, да вообще без всякого учета просто сделаны видимость "честного" BDE-ного Table. получившийся уродец подлежит не использованию а безжалостному истреблению...)
это я к тому что Refresh в ADO работает правильно, адекватно и быстро... при правильном подходе, чего не скажеш про этот случай, ADOTable, он просто пародирует таблицу, а на самом деле это рекордсет с самым тупым (на полную выборку) запросом внутри... т.е. для рефреша делается перезапрос, перекачка всей таблици на "клиента" (к примеру миллион записей) толко для того изменить несколько исправленных ради которых делается рефреш. (в случае с BDE-шным TTable всего лиш перепозиционирование курсора и обновление буфера DataLink-а... т.е. десяток строк...)

> А как реализовать (без существенного переписывания кода) функции удаления, добавления записей.
также как с ADOTable (он то у тебя работает, а это не что иное как замаскированный запрос через ADODataSet. кстати если использовать замену так это его а не ADOQuery)

хотя это не поможет, медленная скорость рефреша не изза конкретных компонент а изза принципа работы, вот если переделать на "интелектуальные" запросы выбирающие не все а только нужное... тогда будет сравнимо, а то, и быстрее чем с TTable (по задаче/нужному функционалу).

ну и еще возможность. переключить компоненты на работу в локальном варианте (для access возможно), тогда полная выборка не будет проиходить даже при таком идиотском запросе как в ADOTable. см. хелп по методу Seek там описан режим тебе нужный если пойдеш по этому пути... (Seek только в нем работает)
правда есть вероятность "сломать" чтонибудь другое, т.к. в этом варианте не работают другие методы (Sort например т.к. невозможно построить локальный индекс... вместо него можно пользоваться физическим)

← →
Курдль © (2006-06-30 10:11) [12]

> В моем случае я обошелся, практически, заменой в тексте
> программы TTAble на TADOTAble

Я не работал именно с ADO наборами компонентов. Но обычно все DB-наборы включают в себя датасэт и апдэйт обжект. Связка "датасорс-датасэт-апдэйт" позволяет таботать с набором данных, как с таблицей.

← →
VadimSpb (2006-06-30 10:44) [13]

> вот если переделать на "интелектуальные" запросы выбирающие
> не все а только нужное...

А если нужными являются именно эти миллион записей?
Любую техническую проблему можно решить организационными методами (С) ;-))
Полагаю речь идет просто о больших списках (типа абонентов). Тогда лучше сделать по принципу телеф. баз - отображать только выбранного абонента.
TADOTаble однозначно в корзину. Проще переписать что нужно на датасете, да и возможностей больше появиться. Сам когда-то переходил с большой неохотой, а теперь жалею, что сразу не сделал :-))

← →
sniknik © (2006-06-30 10:49) [14]

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

Время задержки при начальном отображении парадокс-таблиц самой BDE существенно меньше, чем в клиент-серверных СУБД, что в общем-то может ввести в заблуждение не слишком опытного разработчика.
Однако на этом и заканчиваются все "прелести" связки парадокс+BDE ;)

Применительно к данному случаю (всего-то 300 записей) грабли по всей видимости в самом коде (я, к примеру, вообще не использую Refresh, ибо это псевдообновление при многопользовалке).
Работал с акцесом довольно долго через ADO. Задержек не было на таблицах в тысячи записей. Правда TADOTable, конечно, не пользовался ибо это атавизм конкретный ;)

В данном случае посоветовал бы перейти с TADOTable на TADODataSet и "подшаманить" вставки, коррекции, удаления с переоткрытием запроса - тормоза просто исчезнут.

Да, еще надо проинспектировать опции TADOConnection (Cursor в частности)

← →
LDV (2006-06-30 14:07) [16]

2 MsGuns

Все дело в том, что кода то практически и нет. Имеется в виду для отработки события OnEnter для сетки. Только ADOTable.Refresh.

Подскажите, пожалуйста, как можно выполнить желание пользователя видеть актуальные данные при активации (OnEnter) в сетке? И еще чтобы при этом текущей была запись, на строке сетки которой нажал(стал) мышью пользователь?

>LDV (30.06.06 14:07) [16]
>Подскажите, пожалуйста, как можно выполнить желание пользователя видеть актуальные данные при активации (OnEnter) в сетке? И еще чтобы при этом текущей была запись, на строке сетки которой нажал(стал) мышью пользователь?

function TForm1.ReOpenDataSet(DataSet: TDataSet): boolean; var OldCursor: TCursor; begin result := true; OldCursor := Screen.Cursor; Screen.Cursor := crSQLWait; with DataSet do try Tag := -1; if Active then begin Tag := Fields[0].AsInteger; // Запомнить ID текущей записи Close; end; Open; Locate(Fields[0].FieldName,Tag,[]); except result := false; end; Screen.Cursor := OldCursor; end;

При условии, что в датасет первым включено поле Autoinc таблицы

← →
LDV (2006-07-04 12:58) [18]

2 MsGuns

А при каком событии вызывать ReOpen?

Если при DBGrid.OnEnter, то текущей записью в наборе в этот момент является та, на которой был курсор до "нажатия" мышью на сетке. Хотя пользователь уже видит, что курсор стоит на той записи, куда он "нажал".

>LDV (04.07.06 12:58) [18]
>А при каком событии вызывать ReOpen?

После любых изменений в таблице, выполненых не отображаемым датасетом (TTable) - например, TQuery. И по кнопке на панеле управления (меню)

>при DBGrid.OnEnter

ни в коем случае

← →
LDV (2006-07-04 14:43) [20]

А мне же надо видеть актуальные данные при активации (OnEnter) в сетке. и чтобы при этом текущей была запись, на строке сетки которой нажал(стал) мышью пользователь.

Правильно ли я понимаю, что я должен использовать ADODataSet для отображения данных в сетке.
А для операций добавления/удаления я должен использовать ADOCommand? При этом и ADODataSet, и ADOCommand должны "указывать" на один и тот же ADOConnection.

Медленно выполняется refresh Найти похожие ветки