Midas + ADO = странное поведение. Кто сталкивался?

← →
sniknik © (2003-03-28 18:16) [0]

Делаю простое приложение, ничего не делает только открывает НД ну и естественно перекачивается с сервера на клиента (это уже у себя у нутрях :-)))

используемые компоненты на сервере связка :
TSession -> TDatabase -> TQuery -> TDataSetProvider

на клиенте :
TDCOMConnection -> TClientDataSet -> TDataSource -> ну и TDBGrid (кудаж без него?)
плюс кнопочка где делается
DCOMConnection.Open;
ClientDataSet.Open;

все замечательно работает. довольно большие обьемы (таблица 170 тыс. записей) перекачиваются за от 15 до 30 сек. от раза к разу.

но (как всегда есть но :-)), стоит заменить на сервере источник данных на ADO
т.е. TSession -> TDatabase -> TQuery ->
на TADOConnection -> TADODataSet -> к тому же TDataSetProvider
и тот же запрос к той же таблице (в dBase та же в Access и MSSQL аналогичная) начинает отрабатывать за 30-40мин! запрос явно не "виноват" самый простой SELECT * FROM Table101.

В чем может быть причина такого замедления работы? Кто нибудь сталкивался?

да забыл, все компоненты что ложатся на формы, имеют параметры "по умолчанию", ну кроме настройки связи между ними, и имени компьютера (разные пробовал) результат одинаков.
строка подключения для ADOConnecta (ну от нее тоже вряд ли чего зависит)
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\Program Files\Common Files\Borland Shared\Data;Extended Properties=dBase IV;Persist Security Info=False

← →
sniknik © (2003-03-29 11:10) [1]

Нашол пример (из книги "ADO в дельфи" авторы Федоров,Елманова) где за основу взято ADO, изменил некоторые настройки так же как у них, никакой разницы.
Думал чтото упустил поэтому взял "читый" книжный пример (к базе MSSQL) и "раздул" табличку к которой там обрашаются, результат такое же падение в скорости.
???
непонятно, старый "отстойный" БДЕ работает без проблем. А тут ..., что никто в трехзвенках не закачивает в базу больших обьемов с клиента? вернее не должен, используя ADO, раз такое ограничение, или всетаки дело в какойто "хитрой" настройке?.

← →
Anatoly Podgoretsky © (2003-03-29 11:21) [2]

Проблема конечно в твоем запросе и в различиях его обработки, в первом случае на клиент качалось столько, сколько требовалось для отображения на данный момент, во втором все 170 000 записей. В первом случае наверно при переходе в конец таблицы было бы такое же замедление.
Можно поиграться настройками АДО и достигнуть такого же поведения, какая то комбинация даст тебе желаемое, а можно поработать над запросом, что бы на клиент выдавалось минимум необходимого, в идеале ровно одна запись.
Но достигнуть этого для файл серверных систем будет трудновато, нет сервера.

← →
sniknik © (2003-03-29 11:42) [3]

Да не, я специально качаю все в обоих случаях.
Значение ClientDataSet.PacketRecords = -1, или тоже пробовал 10, 20... и + ClientDataSet.Last. А запрос без ограничений, проверка времени в конце. И количество полученого проверяю ClientDataSet.RecordCount сразу после запроса или ClientDataSet.Last в случае PacketRecords <> -1.

Делаю замер скорости на перекачку данных. (понадобится при начальном заполнении базы). Иногда нужно.

> Можно поиграться настройками АДО ...
да вот играюсь играюсь а наигратся не могу :о)))

> Но достигнуть этого для файл серверных систем будет трудновато, нет сервера.
вот!.. вот сервера то быстро пакеты передают! пока у меня на первом месте MSSQL на ту же таблицу 11сек.
хотелось бы ~ тогоже, весьма приблизительно, даже в 10раз медленнее устроит.

← →
sniknik © (2003-03-29 11:45) [4]

чтобы не возникало недоразумений (сразу надо было)
получение данных, так
Label1.Caption:= DateTimeToStr(Now);
DM.cdsContacts.Open;
DM.cdsContacts.Last;
Label2.Caption:= DateTimeToStr(Now);
Label3.Caption:= IntToStr(DM.cdsContacts.RecordCount)

← →
sniknik © (2003-03-29 15:46) [5]

Чтобы не быть голословным выложил пример в кладовку
http://delphi.mastak.ru/cgi-bin/download.pl?look=1&id=1048941720&n=1
(dBase базу не выкладываю, легко сделать самим)

и еще, хотя тестится на dBase, в основном это нужно для базы Access, там ситуация анологичная, впрочем как и при подключении к MSSQL.

Все ... доигрался. :о)))

В смысле проблема решилась, нашол нужную комбинацию параметров, в частности курсор серверный (ни в одном примере не стоит! хотя логично), ltBatchOptimistic и еще кое чего менял.

кстати в примере который в кладовке глюк (я не делал пример специально для кладовки, просто сархивировал рабочий с теми параметрами что были на тот момент) там в конекте LoginPrompt труе стоит. снимите если будете пробовать.

ну а вопрос снимается в связи с благополучным разрешением.
всем спасибо.

А ты наверно клиентский курсор делал, в этом случае все перекачивается на клиента и там рулится.

Anatoly Podgoretsky
я вообще все делал (все комбинации что в голову приходили), но пока не разобрался более менее смысла от перебора было мало :-)).

курсор серверный у меня одно время стоял, только как оказалось в это же время LoginPrompt труе был. Что как понимаете не способствовало ... :-)).

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

и кстати я и пытался все на клиента перекачать, и в случае с серверным курсором тоже (пробегаю по записям, для уверености), так что тут вряд ли от этого, скорее всего там какаято колизия возникает с локальным, либо в случае серверного курсора передается просто канал (указатель) а дальше данные качаются прямо между компонентами без участия TDataSetProvider? Ну это пока домыслы. Короче еще разбиратся и разбиратся (в обшем за тем и начал).

Midas + ADO = странное поведение. Кто сталкивался? Найти похожие ветки