TClientDataSet

← →
parivet (2007-08-28 13:04) [0]

Недавно стал использовать TClientDataSet.
Как я понял, изменения, накапливаються на клиенте, а потом в одной короткой транзакции делается сохранение этих изменений.

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

← →
Сергей М. © (2007-08-28 13:09) [1]

> Как применять изменения сразу

см. ApplyUpdates

← →
parivet (2007-08-28 13:20) [2]

А как быть с ADODataSet?

← →
Сергей М. © (2007-08-28 13:24) [3]

> как быть с ADODataSet?

С т.з. наличия там аналога TClientDataSet.ApplyUpdates ?
Никак.
У ADODataSet, мягко говоря, несколько иные задачи.

← →
Vic111 (2007-08-28 13:25) [4]

Попала на глаза эта ветка, спрошу и я здесь:

переодически бывают сбои в сети, стал смотреть в сторону TClientDataSet. Если, например в процессе работы произошел сбой, то как все сделанные изменения можно сохранить и отправить после восстановления сети.

← →
parivet (2007-08-28 13:32) [5]

> Vic111 (28.08.07 13:25) [4]

Эт ты зря...

Я связал ADODataSet1 - > DataSetProvider1 - > ClientDataSet1

это правильно? делать у ClientDataSet1.ApplyUpdates ?

← →
Vic111 (2007-08-28 13:37) [6]

ну я пробовал также, если связь по сети есть, то все проходит на ура при ClientDataSet1.ApplyUpdates(-1)

← →
sniknik © (2007-08-28 13:46) [7]

> С т.з. наличия там аналога TClientDataSet.ApplyUpdates ?
> Никак.
> У ADODataSet, мягко говоря, несколько иные задачи.
ну вообще то подобное есть, только с другим названием, т.что он может решать и эти задачи тоже, и к тому же без лишних(в этом случае) посредников.

← →
parivet (2007-08-28 13:53) [8]

> на ура при ClientDataSet1.ApplyUpdates(-1)

У меня результат остался тот же... секунды через 3-4 обновление.

> sniknik © (28.08.07 13:46) [7]

А почему не сказать как?

← →
Сергей М. © (2007-08-28 13:53) [9]

> sniknik © (28.08.07 13:46) [7]

Если имеется ввиду UpdateBatch, то его функциональность, конечно, во оснговном сходна с АpplyUpdates, но более ограничена.

← →
parivet (2007-08-28 13:56) [10]

ADODataSet1.UpdateBatch(arAll);

нет результата.

← →
Сергей М. © (2007-08-28 13:59) [11]

> parivet (28.08.07 13:56) [10]

А условия для "результативной" работы метода ты соблюл ?
В справке они довольно подробно описаны.

← →
parivet (2007-08-28 14:15) [12]

ADOQuery.LockType = ltBatchOptimistic

ADOConnection1.BeginTrans();
ADOQuery1.UpdateBatch(arAll);
ADOConnection1.EndTrans();

это не все условия?

← →
Сергей М. © (2007-08-28 14:18) [13]

Не все.

В справке сказано:

The example below shows the preparation of a TADODataSet component for batch update mode.

with ADODataSet1 do begin
CursorLocation := clUseClient;
CursorType := ctStatic;
LockType := ltBatchOptimistic;
CommandType := cmdText;
CommandText := "SELECT * FROM Employee";
Open;
end;

← →
parivet (2007-08-28 14:26) [14]

да. спасибо.

← →
sniknik © (2007-08-28 14:33) [15]

> во оснговном сходна с АpplyUpdates, но более ограничена.
не сильно. в общем то единственное существенное (имхо) отличие это отсутствие метода для получения дельты изменений. остальное в том или ином виде есть.

← →
Vic111 (2007-08-28 15:17) [16]

> sniknik © (28.08.07 14:33) [15]

> дельты изменений

как-то касается
> Vic111 (28.08.07 13:25) [4]

подскажите, пожалуйста как это реализуется :-(

← →
Сергей М. © (2007-08-28 15:25) [17]

> Vic111 (28.08.07 15:17) [16]

Касается и еще как.

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

← →
sniknik © (2007-08-28 15:33) [18]

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

← →
sniknik © (2007-08-28 15:34) [19]

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

← →
Vic111 (2007-08-28 15:36) [20]

Дельта - это все накопленные изменения, но не внесенные в НД - а где они сохраняются и как их сохранить, чтобы при восстановлении коннекта повторно отправить.

← →
Сергей М. © (2007-08-28 15:37) [21]

> sniknik © (28.08.07 15:34) [19]

> не дельты, а метода

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

← →
Сергей М. © (2007-08-28 15:49) [22]

> где они сохраняются и как их сохранить, чтобы при восстановлении
> коннекта повторно отправить

Зачем тебе этот геморрой ?

CDS специально заточен для "тонких" клиентов с неважнецким коннектом и ограниченными ресурсами.

Сделай связку ADODataSet <- DataSetProvider <- ClientDataSet и ты получишь преимущества CDS и ADODS "в одном флаконе".

← →
Vic111 (2007-08-28 15:52) [23]

дак у меня так и сделано, а если сеть не восстанавливается длительное время, програму нужно завершить :-(

> Дельта - это все накопленные изменения, но не внесенные в НД
вроде так

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

> и как их сохранить
хз. не часто работал с клиентским, и этого точно не делал. но наверное так MyDelta:= ClientDataSet1.Delta;.

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

← →
Vic111 (2007-08-28 16:12) [26]

тоесть
try
ADODataSet1.UpdateBatch;
except

> инсерт/апдейт в ADOCommand в зависимости от статуса записи

end;
нужно будет отдельное поле где хранить статус записи или можно средствами датасета реализовать

RecordStatus

по этой же фигне в статусе, возможен и и фильтр, не помню уже, практического применения не нашло, только 1 раз пробовал давно давно по rsDeleted записи выделял...
т.что не спрашивай как делать, лом. просто имей ввиду. и если заинтересует поищи/по изучай как.

да вспомнил... rsDeleted просто так, без установленного фильтра не видны, т.что придётся тебе в этом поковыряться, иначе не сможешь сделать удаление записей.

← →
Vic111 (2007-08-28 16:29) [30]

Спасиб, попробую :-)

хм... надо же, сохранилось.
DSetOrig.Recordset.Filter:= adFilterPendingRecords; {учитывать удаленные}
+ я там почему то не в записи RecordStatus проверял, а у датасета DSetOrig.UpdateStatus (возможно это тоже самое перенесенное), и вместо rsDeleted тогда будет usDeleted.
пробуй, возможно поможет.

← →
Vic111 (2007-08-28 18:27) [32]

Да, действительно:
ADODataSet1.First; while not ADODataSet1.EOF do begin if rsUnmodified in AdoDataSet1.RecordStatus then showmessage("UnModified"); if rsModified in AdoDataSet1.RecordStatus then showmessage("Modified"); if rsDeleted in AdoDataSet1.RecordStatus then showmessage("Deleted"); if rsNew in AdoDataSet1.RecordStatus then showmessage("New"); ADODataSet1.Next; end;

не подхватывает удаленные записи ()
а для ADODataSet1.Recordset.Filter:= adFilterPendingRecords;
неизвестно adFilterPendingRecords - какой модуль нужен, или константа?

ADOInt

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