> а зачем я его пишу? (вопрос в стиле ветки, только к автору
> ;))

Вы с ClientDataSet ом вообще работали? :-)

>VikOss ©   (28.12.12 12:14) [34]
>А не многовато запросов на сервер будет?

:)

Хе-хе, Вы разберитесь что Вы хотите. Если тянуть сразу все детали и ФИЛЬТРОВАТЬ их по мастер-ключу (типа щадить сервер), то это как бэ и не мастер-детал, как я понимаю, а фильтрация (делается ручками), а если тянуть с сервера только детали одной мастер-записи перезапуском запроса на выборку (типа классической мастер-детал), то тогда другой дело.

Я не знаю особенностей Вашей задачи, но ИМХО, второй способ для больших объемов куда предпочтительнее. А насчет нагрузки на сервер, еще раз хехе. Для того, чтобы пользователь глянул ОДНУ мастер-запись за сеанс, сервер вытянет все 100500 деталей. Это Вы считаете "щадящим" режимом ?

> Вы с ClientDataSet ом вообще работали? :-)
давно, уже забывать начал... вон сколько времени на банальный тест потратил. ;(

>VikOss ©   (28.12.12 12:30) [40]
>Вы с ClientDataSet ом вообще работали? :-)

Я еще раз спрашиваю - что послужило причиной выбора именно этой компоненты (намек на сенокосилку) ? Что-то мне подсказывает, что Вы используете его совершенно не по делу.

> +
> запрос "мастера"
> SELECT * FROM Reestr WHERE ID < 4726
> запрос "детайля"
> SELECT * FROM ReestrResp WHERE ReestrID = :ReestrID
> связка ReestrID -> ID, усе Ок.

:-) Открываем мастера - закачали, ок. Открываем Подчинённого - ID мастера текущий? не? -> качаем в кэш данные подчинённого только для одной записи из мастера НЕ?

> а зачем я его пишу? (вопрос в стиле ветки, только к автору ;))
да ладно, "зачем пишу", а вот зачем mssql/судя по профайлеру его исполняет!!!??? нужно жалобу в мелкософт написать, по VikOss он этого делать не должен...

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

Блин, ну независимое от сети приложение, сохранение данных в файло на диске, типа "портфеля", я ж написал...

> качаем в кэш данные подчинённого только для одной записи из мастера НЕ?
а у тебя кэш параллельно = рабочий рекордсет?
ССЗБ

> да ладно, "зачем пишу", а вот зачем mssql/судя по профайлеру
> его исполняет!!!??? нужно жалобу в мелкософт написать, по
> VikOss он этого делать не должен...
>

Ниче не понял, какой mssql ?
Не надо тему во флуд спускать, ок?

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

> Не надо тему во флуд спускать, ок?
она изначально такая... все темы без кода в первых постах = флуд.

Я так понял, нужно ещё "разжевать".
Программа делает следующее: при первом подключении к серверу, закачивает данные (не все, а по выборке, типа невыполненные задания) на комп юзера. Далее он может ОТКЛЮЧИТЬСЯ и спокойно работать хоть до посинения, с выключением компа. Потом подключается и обновляет данные на сервере - выполненные задания остаются на сервере, а пользователю они более не нужны.
Всё работает уже 2 года без проблем. Заметил на появившееся притормаживания и рост локальных файлов, без существенного изменения кол-ва текущих записей. Далее читаем на старте топика...

На [41] отвечать не будем ?
Уверен, что "глюк" в программе. Оттого, что он проявляется при определеных обстоятелствах, перкладывать "вину" на VCL не стоит. "Два года без проблем" - не аргумент, просто не возникало тех самых "обстоятельств"

Насколько я понял из [51] нужно чтобы приложение считывало с сервера ВСЮ информацию, сохраняло его локально и затем могло работать автономно (без сервера) в режима один-ко-многим. В данном случае применение TClientDataSet, конечно, обосновано (хотя и не есть лучший вариант решения подобной проблемы). Но в этом случае Вам предпочтительнее использовать простую фильтрацию вместо мастер-детал (как было указано выше).

> На [41] отвечать не будем ?
> Уверен, что "глюк" в программе. Оттого, что он проявляется
> при определеных обстоятелствах, перкладывать "вину" на VCL
> не стоит. "Два года без проблем" - не аргумент, просто не
> возникало тех самых "обстоятельств"

Извините, не понял на что отвечать. О выборе компоненты? А "кто" ещё умеет работать с файлами локально, да ещё без глюков?
Без проблем - значит без проблем. И ничего не возникло. Просто на малых объёмах базы этот недостаток, очевидно, не заметен. Начала расти база - стало очевидно, что подчинённые данные качаются в файл целиком, не смотря ни на что...

> Хе-хе, Вы разберитесь что Вы хотите. Если тянуть сразу все
> детали и ФИЛЬТРОВАТЬ их по мастер-ключу (типа щадить сервер),
>  то это как бэ и не мастер-детал, как я понимаю, а фильтрация
> (делается ручками), а если тянуть с сервера только детали
> одной мастер-записи перезапуском запроса на выборку (типа
> классической мастер-детал), то тогда другой дело.
>
> Я не знаю особенностей Вашей задачи, но ИМХО, второй способ
> для больших объемов куда предпочтительнее. А насчет нагрузки
> на сервер, еще раз хехе. Для того, чтобы пользователь глянул
> ОДНУ мастер-запись за сеанс, сервер вытянет все 100500 деталей.
>  Это Вы считаете "щадящим" режимом ?

Я ж описал задачу и проблему.

> а если тянуть с сервера только детали
> > одной мастер-записи перезапуском запроса на выборку (типа
> > классической мастер-детал), то тогда другой дело.

Вот тут можно поподробнее?

> Насколько я понял из [51] нужно чтобы приложение считывало
> с сервера ВСЮ информацию, сохраняло его локально и затем
> могло работать автономно (без сервера) в режима один-ко-
> многим. В данном случае применение TClientDataSet, конечно,
>  обосновано (хотя и не есть лучший вариант решения подобной
> проблемы). Но в этом случае Вам предпочтительнее использовать
> простую фильтрацию вместо мастер-детал (как было указано
> выше).

Не ВСЮ !!! ИМЕННО НЕ ВСЮ ! Внимательней - выполненные задания не нужны, они и не качаются, качаются ВСЕ ПОДЧИНЕННЫЕ данные в том числе из уже ВЫПОЛНЕННЫХ.

> Не ВСЮ !!! ИМЕННО НЕ ВСЮ ! Внимательней - выполненные задания
> не нужны, они и не качаются, качаются ВСЕ ПОДЧИНЕННЫЕ данные
> в том числе из уже ВЫПОЛНЕННЫХ - а этого, разумеется не надо! Вот тут и вся проблема. Буржуины, судя по Гуглу, то ж эту проблему решить не могут.

> Я ж описал задачу и проблему.
задача (по описанию) - скачать и работать на клиенте со всеми записями... проблема - все это очень много...

вызывай Хотабыча, он поможет. :)

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