Искусственная транзакция

[little]

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

[RXL]

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

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

[Finch]

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

little, Смотри описание тут http://msdn2.microsoft.com/en-us/library/system.data.datatable_members.aspx
Тебя интересуют методы AcceptChanges, GetChanges, Reset, RejectChanges

[little]

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

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

Как вариант вижу копирование таблиц входящих в транзакцию с последующим копированием их обратно, в случае отката транзакции. Но не слишком ли тяжелой и медленной получится такая обработка?

[Finch]

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

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

[little]

Так я и говорю, что этот вариант не подходит.

[Dimka]

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

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

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

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

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

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