![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TClientDataSet [D6, Access]
parivet © (2007-08-28 13:04:00)Недавно стал использовать TClientDataSet.
Как я понял, изменения, накапливаються на клиенте, а потом в одной короткой транзакции делается сохранение этих изменений.
Как применять изменения сразу? Необходимо мгновенное обновление выпадающих списков при корректировке справочников.
sniknik (2007-08-28 19:35:00) [1]ADOInt
Vic111 (2007-08-28 18:27:00) [2]Да, действительно:
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 - какой модуль нужен, или константа?
sniknik (2007-08-28 16:44:00) [3]хм... надо же, сохранилось.
DSetOrig.Recordset.Filter:= adFilterPendingRecords; {учитывать удаленные}
+ я там почему то не в записи RecordStatus проверял, а у датасета DSetOrig.UpdateStatus (возможно это тоже самое перенесенное), и вместо rsDeleted тогда будет usDeleted.
пробуй, возможно поможет.
Vic111 (2007-08-28 16:29:00) [4]Спасиб, попробую :-)
sniknik (2007-08-28 16:27:00) [5]да вспомнил... rsDeleted просто так, без установленного фильтра не видны, т.что придётся тебе в этом поковыряться, иначе не сможешь сделать удаление записей.
sniknik (2007-08-28 16:22:00) [6]по этой же фигне в статусе, возможен и и фильтр, не помню уже, практического применения не нашло, только 1 раз пробовал давно давно по rsDeleted записи выделял...
т.что не спрашивай как делать, лом. просто имей ввиду. и если заинтересует поищи/по изучай как.
sniknik (2007-08-28 16:18:00) [7]RecordStatus
Vic111 (2007-08-28 16:12:00) [8]тоесть
try
ADODataSet1.UpdateBatch;
except
> инсерт/апдейт в ADOCommand в зависимости от статуса записи
end;
нужно будет отдельное поле где хранить статус записи или можно средствами датасета реализовать
sniknik (2007-08-28 16:04:00) [9]> дак у меня так и сделано
я бы сделал по другому...
оставил бы 1 ADODataSet из всей связки, с батчапдейте. и стандартной обработкой, с дополнением, если не прошла стандартная (сеть рухнула), то после восстановления без всяких сохранений/выделений, ручной апдейт - инсерт/апдейт в ADOCommand в зависимости от статуса записи. т.е. простой цикл, с сохранением пока можно, если опять обрыв то продолжать с того же места.
sniknik (2007-08-28 15:56:00) [10]> Дельта - это все накопленные изменения, но не внесенные в НД
вроде так
> а где они сохраняются
метод одноимённый - Delta, только они не сохраняются, они выделяются из того же рекордсета при обращении. с методом или сам ты это будешь делать время это займёт по любому. (еще неизвестно что дольше, выделить и переносить из готового или отсоединить и пробежаться по всему...)
> и как их сохранить
хз. не часто работал с клиентским, и этого точно не делал. но наверное так MyDelta:= ClientDataSet1.Delta;.
Vic111 (2007-08-28 15:52:00) [11]дак у меня так и сделано, а если сеть не восстанавливается длительное время, програму нужно завершить :-(
Сергей М. (2007-08-28 15:49:00) [12]
> где они сохраняются и как их сохранить, чтобы при восстановлении
> коннекта повторно отправить
Зачем тебе этот геморрой ?
CDS специально заточен для "тонких" клиентов с неважнецким коннектом и ограниченными ресурсами.
Сделай связку ADODataSet <- DataSetProvider <- ClientDataSet и ты получишь преимущества CDS и ADODS "в одном флаконе".
Сергей М. (2007-08-28 15:37:00) [13]
> sniknik © (28.08.07 15:34) [19]
> не дельты, а метода
На больших НД это равносильно ее отсутствию - ты бегаешь по НД в поисках таких записей, а в это время коннект опять приказал долго жить)
Vic111 (2007-08-28 15:36:00) [14]Дельта - это все накопленные изменения, но не внесенные в НД - а где они сохраняются и как их сохранить, чтобы при восстановлении коннекта повторно отправить.
sniknik (2007-08-28 15:34:00) [15]> Раз дельты нет (точнее к ней нет доступа)
нет не дельты, а метода который ее выделяет в отдельный рекордсет.
sniknik (2007-08-28 15:33:00) [16]> как-то касается
теоретически возможно, если делать переконнект после обрыва и перенос изменений в новый ещё подключённый датасет для дальнейшего АpplyUpdates/UpdateBatch... но практически выделить изменения и перенести можно и там, позаписьно, статус для одной записи есть (а может и фильтр есть аналогичный, не помню. т.е. тут будет не выделение в отдельный датасеа а фильтрация существующего).
т.е. на практике это это почти без разницы. а принцип один - отложить/выделить изменённый датасет восстановить коннект, перезапросить данные, повторить в них изменения из отложенного, и применить побыстрее пока сеть опять не "порвалась".
Сергей М. (2007-08-28 15:25:00) [17]
> Vic111 (28.08.07 15:17) [16]
Касается и еще как.
Раз дельты нет (точнее к ней нет доступа), то при возникновении исключения (связанного в дан.случае с разрывом коннекта) в ходе обновления нет возможности сохранить ее с целью повторного проведения транзакции с участием сохраненных дельта-данных после возобновления коннекта.
Vic111 (2007-08-28 15:17:00) [18]
> sniknik © (28.08.07 14:33) [15]
> дельты изменений
как-то касается
> Vic111 (28.08.07 13:25) [4]
подскажите, пожалуйста как это реализуется :-(
sniknik (2007-08-28 14:33:00) [19]> во оснговном сходна с АpplyUpdates, но более ограничена.
не сильно. в общем то единственное существенное (имхо) отличие это отсутствие метода для получения дельты изменений. остальное в том или ином виде есть.
parivet (2007-08-28 14:26:00) [20]да. спасибо.