Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Искусственная транзакция  (Прочитано 11797 раз)
0 Пользователей и 1 Гость смотрят эту тему.
little
Помогающий

de
Offline Offline
Пол: Мужской

« : 18-12-2007 08:50 » 

Как можно откатить изменения, внесенные в DataTable?
Требуется сделать что-то вроде искусственной транзакции для набора таблиц на случай, если при сохранении на сервер произошли ошибки. Для сервака все откатят транзакции, а как откатить изменения для измененных таблиц приложения?
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 18-12-2007 15:03 » new

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #2 : 18-12-2007 19:10 » 

RXL, Это ְADO.NET Т.е. таблица сушествует только в памяти компа.

little, Смотри описание тут http://msdn2.microsoft.com/en-us/library/system.data.datatable_members.aspx
Тебя интересуют методы AcceptChanges, GetChanges, Reset, RejectChanges
« Последнее редактирование: 18-12-2007 19:19 от Finch » Записан

Не будите спашяго дракона.
             Джаффар (Коша)
little
Помогающий

de
Offline Offline
Пол: Мужской

« Ответ #3 : 19-12-2007 08:53 » 

Finch, хм..., что самое интересное, я это сам знал. Вот теперь сижу и вспоминаю/думаю почему мне это не пришло в голову, а если пришло, почему меня это не устроило? Улыбаюсь

Вспомнил. Не устраивает потому что я не могу откатить все изменения. Таблицы могут прийти на обработку в транзакцию с уже измененнными записями. И откатить мне их нужно будет именно до того состояния, в котором они были до транзакции. А ResetChanges откатит абсолютно всё.

Как вариант вижу копирование таблиц входящих в транзакцию с последующим копированием их обратно, в случае отката транзакции. Но не слишком ли тяжелой и медленной получится такая обработка?
« Последнее редактирование: 19-12-2007 09:05 от little » Записан
Finch
Спокойный
Администратор

il
Offline Offline
Пол: Мужской
Пролетал мимо


« Ответ #4 : 19-12-2007 13:06 » 

ְAcceptChanges устанавливает чек поинты отката, все данные помечаются как неизмененнные.
ּRejectChanges производит откат таблици до чек поинта.
Reset откатывает таблицу до оригинального (первоначального) состояния.

Такие же методы есть и у DataRow.
Записан

Не будите спашяго дракона.
             Джаффар (Коша)
little
Помогающий

de
Offline Offline
Пол: Мужской

« Ответ #5 : 25-12-2007 07:37 » 

Так я и говорю, что этот вариант не подходит.
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 26-12-2007 07:38 » 

Finch, AcceptChanges и RejectChanges используются при сохранении DataTable/DataSet в БД. Ещё с ними можно писать разные хитрости для управления процессом сохранения. Например, не загрузкой, а вручную вставить в таблицу записи, которые уже имеются в БД, и выполнить для них AcceptChanges, тогда при сохранении таблицы они не будут повторно вставляться в БД. Тут же речь о другом: об Accept/RejectChanges второго уровня чисто для внутреннего употребления.

Не слышал, чтобы были такие стандартные средства. Наверно, придётся писать. Или искать готовую библиотеку с таким функционалом.

Писать можно двумя путями:

1) Аналог DoubleBuffer в графике. Создать собственный DataTable, которы внутри себя содержит 2 таблицы: основную (которая синхронизируется с БД) и рабочую (аналог буфера), в которую пишет пользователь. Соответственно, в конце внутренней транзакции либо буфер переносится в основную таблицу (commit), либо, наоборот, очищается и заполняется данными из основной таблицы (reject). Требует удвоенного расхода памяти.

2) Журналируемые изменения. Создать собственную DataTable, которая хранит текущее состояние, но при любых операциях вставки/удаления/изменения записей в свой внутренний журнал сохраняет произошедшую операцию. В случае commit журнал очищается, в случае reject идёт просмотр журнала от конца к началу и восстановление информации.

Выбор стратегии зависит от условий работы с таблицами. Транзакции с малым числом действий выгоднее делать 2-м способом, т.к. это экономит память. Транзакции с интенсивными изменениями, требующие хранения очень больших журналов, может быть выгоднее реализовать 1-м способом, т.к. это тоже может сэкономить память.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines