копирование выборок

← →
Dennica © (2005-11-07 11:54) [0]

Здравствуйте! Незнаю сюда мне писать или правилней было-бы в раздел для начинающих. В общем у меня ряд вопросов связанных с датасэтами на которые очень хотелось бы получить ответы.
1. Я пользуюсь в основном в работе TZQuery. Иногда, для удобства редактирования мне нужно показать ему часть данных, содержащихся в наборе. Для этого я знаю только 2 способа - фильтр или повторная выборка с сервера нужного диапазона. Фильтр нежелателен т.к. 1 набор может быть одновременно открыт в нескольких формах. Повторная выборка конечно хорошо, но я незнаю как после редактирования запихнуть отредактированные данные в исходный датасэт минуя сервер. Т.е. в этом случае после запихивания изменений непосредственно на сервер нужно тут же делать обновление в начальном датасэте что не есть гуд т.к. может занимать времени порядочно.
Идеальным решением было бы копирование части записей в какой-то пустой датасэт, редактирование их там и потом обновление исходного, но как это сделать я незнаю, и можно ли это вообще. Наверное можно, элементарная ситуация поидее для работы с БД. Надеюсь на ваши советы т.к. сам не смог найти способ.

2. Вопрос связанный с предыдущим. Возможно ли каким то образом писать SQL запросы непосредственно к датасэтам =)?

3. Странно, я несмог найти стандартных групповых функций для наборов, типо - replace all . Их нужно самому писать или я плохо искал =)

4. стоп. итак уже наспрашивал прилично =)

Надеюсь что народ не сочтет за труд ответить хотябы даже отрицательно на эти вопросы.

← →
Sergey13 © (2005-11-07 12:01) [1]

2Dennica © (07.11.05 11:54)
>Незнаю сюда мне писать или правилней было-бы в раздел для начинающих
Не волнуйся - перенесут. 8-)
1. А зачем такие сложности? Почему нельзя запрашивать с сервака только то что надо?
2. Напрямую - нет. Вернее почти нет. Так что скорее всего - НЕТ.
3. Отвыкать надо от таких привычек. Групповую обработку следует выносить на сервер и производить с помощью SQL запросов.

← →
ANB © (2005-11-07 12:09) [2]

> Dennica © (07.11.05 11:54)

1. Забудь про клиппер и прямую работу с таблицами
2. Чтобы не тормозил основной запрос - нужно его оптимизнуть. Кстати, нет никакого смысла хранить его результаты. Должен быть один режим с возможностью установки пользователем фильтра. На клиенте обрабатываешь установки фильтра и генеришь нужный SQL.
3. Пакетная обработка производится с помощью SQL (DML).

← →
Dennica © (2005-11-07 12:21) [3]

Sergey13 ©
> 1. А зачем такие сложности? Почему нельзя запрашивать с сервака только
> то что надо?
Я придвидел и попытался в первом вопросе сразу ответить на этот вопрос но видимо не умею объяснять. Хорошо, конкретный прмер. На сервере лежит довольно большой справочник расположенный в нескольких таблицах. По идее когда пользователь открывает его для выбора/редактирования я не могу ему предложить только первые 100 записей т.к. незнаю с чем он хочет работать. Данные расположенны иерархически и вопрос неудобства работы с большой выборкой не стоит. (да, канал до сервера узкий, поэтому больший выборки в конечном итоге экономят время). Теперь скажем нужно отредаткировать запись. Логично для этого было бы выбрать только нужную запись с сервера отредактировать их и обновить основной датасэт, т.е. изменения на сервер внести через основной набор данных. А т.к. этого невозможно, приходится обновлять прямо на сервере потом полностью перекачивать первычный набор.
Надеюсь в этот раз понятней объяснил. Итак, на вопрос зачем я попытался ответить, но вопрос как так и остался нераскрытым =)

← →
Sergey13 © (2005-11-07 12:28) [4]

2 [3] Dennica © (07.11.05 12:21)
>По идее когда пользователь открывает его для выбора/редактирования я не могу ему предложить только первые 100 записей т.к. незнаю с чем он хочет работать.
А пользователь знает? Вот и пусть скажет - чего ему надо.

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

Ты как то спутал красное и кислое, ИМХО. Если у тебя есть набор данных, то зачем для редактирования запрашивать одну запись еще раз? Редактируй прямо в этом наборе.

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

Что за БД и компоненты доступа?

← →
Dennica © (2005-11-07 12:38) [5]

ааа, чтож это такое то!!! Сидел писал 10 минут, забыл имя вписать , выдало ошибку о незаполненности и похоронило все труды... ууу блин :))

← →
Dennica © (2005-11-07 12:50) [6]

ANB ©
>1. Забудь про клиппер и прямую работу с таблицами
>2. Чтобы не тормозил основной запрос - нужно его оптимизнуть. Кстати,
> нет никакого смысла хранить его результаты. Должен быть один режим с
> возможностью установки пользователем фильтра. На клиенте
> обрабатываешь установки фильтра и генеришь нужный SQL.
Запросы я конечно оптимизировал и виполняются они достаточно быстро. Дело в другом! Дело в том что я жадный! =)) и мне жаль гонять лишний раз по сети таблицу всю если нужно перекунить одну запись.

2Sergey13 ©
> Ты как то спутал красное и кислое, ИМХО. Если у тебя есть набор данных,
> то зачем для редактирования запрашивать одну запись еще раз?
> Редактируй прямо в этом наборе.
Прямо в этом к сожалению не получается =( Это связанно с используемыми компанентами в основном, которые требуют чтоб данные были нефильтрованными. Но вдаваться в подробности не хочу. Вопрос мой был не в этом.
> Что за БД и компоненты доступа?
zeos и postgres

← →
Sergey13 © (2005-11-07 13:01) [7]

2[6] Dennica © (07.11.05 12:50)
> Прямо в этом к сожалению не получается
"не получается" <> нельзя. Иногда по крайней мере. (это не утверждение, ибо эту связку не юзал)

> Это связанно с используемыми компанентами в основном, которые требуют чтоб данные были нефильтрованными.
Так не фильтруй. Я ж тебе об этом и говорю. 8-)

>Но вдаваться в подробности не хочу.
Дело твое, но, ИМХО, зря. Вполне вероятно, что из ложного посыла ты делаешь ложные выводы и ненужную работу.

>zeos и postgres
тут я пас. Ни того ни другого не пробовал.

← →
Dennica © (2005-11-07 13:34) [8]

О боже, что мне сегодня так не везет то! Уже и имя на месте а после добавить все труды бесследно исчезают =\

3Sergey13 ©
Я конечно понимаю, что мы могли бы обсудить структуру моего приложения, изменить интерфейс и обойтись без прямой работы с датасэтом, но я бы нихотел менять структуру и интерфейс поэтому не стал это обсуждать.

На прошлой неделе мне попадался прмерно такой код:
with TDataSetProvider.create(self) do begin try dataset := zquery1; ClientDataSet1.data := data; finally free; end; end;
По замыслу этот ког перебрасывает данные в клиентский датасэт без обращения к серверу, но реально я смотрю в монитор и вижу что запрос на сервер происходит. Может есть еще способ обратится к внутреннему буферу датасэтом.

Dennica © (07.11.05 12:21) [3]
(да, канал до сервера узкий, поэтому больший выборки в конечном итоге экономят время).

Время экономят маленькие выборки, ровно столько сколько нужно и ни грамом больше.

Anatoly Podgoretsky ©
> Время экономят маленькие выборки, ровно столько сколько нужно и ни
> грамом больше.
Да я не спорю с этим и в большинстве случаев именно так и поступаю, но тут вопрос в другом. Ну должен же быть способ копирования между наборами, нутром чую =) Взять хотяб пример мой из поста выше. Да у меня не работает, но ведь у кого-то он работал. Какие нужны условия для того чтоб скопировать при этом не обращаясь к серверу? =) Меня по большому счету интересует лиш это.
Никто про копирование пока не сказал решительного невозможно поэтому подожду может у кого еще мысли появятся какие. ;)

копирование выборок Найти похожие ветки