Кратко — если мы при помщи адаптера переносим данные на сервер внутри транзакции, то в случае отката транзакции получаем парадокс. Адаптер работает построчно и переходя к новой строке он переданной выставляет статус строки в DataRowState.Unchanged! Если транзакция откатилась, то как заставить адаптер то же "откатить" свои изменения статуса, что бы при повторном сохранении все не переданные строки были переданы!
А получить изменения из датасета через GetChanges() и с изменениями залезть в датаадаптер не пробовали? В случае отката у Вас будет оригинальный датасет, в случае успешного занесения — не помню, что там делать (по моему Merge, а возможно, просто в оригинальном датасете сделать AcceptChanges).
Re: DataAdapter и тразакция - как их совместить?
От:
Аноним
Дата:
13.11.05 11:39
Оценка:
У меня в случае успеха окно закрывается. Но идею сейчас опробую! Что касатся "поста" о том что мнесённые данные не вызывают изменения, то это что то напутали с привязкой! Единственая проблема здесь если textbox один то изменения только после потери фокуса!
Идея объехать на кривой простую логику адаптера даёт тако рзуьтат. Если окно не закрывать то повторная посылка (adapter.Update()) приведет к другой ошибке "Concurency violetion ...". То бишь мы не так просты — они контролируют не изменил ли запись ещё кто нибудь! Супер. Как бы это дурдом выключить?
Кстати того же результата ( table.GetChanges()) можно добиться проще. Для этого надо установить своиство
DataAdapter.AcceptChangesDuringUpdate = false;
Привет всем! Удивительно что эта тема не вызывает ни у кого желания обсудить! В книге Дэвида Сеппа «ADO.NET» на стр. 439 сказано – «некоторым разработчикам передать изменения в транзакции…. Рекомендуется ContinueUpdateOnError=false». Но что делать со статусами строк, которые уже скинулись?
>Привет всем! Удивительно что эта тема не вызывает ни у кого желания обсудить! В книге Дэвида Сеппа «ADO.NET» на стр. 439 сказано – «некоторым разработчикам передать изменения в транзакции…. Рекомендуется ContinueUpdateOnError=false». Но что делать со статусами строк, которые уже скинулись?
Вероятно, остальные надеются, что вы заглянете в MSDN, наберете в поиске что-то вроде "adapter optimistic", заглянете на первую ссылку ("Optimistic Concurrency") и прочитаете пункт "The DataAdapter.RowUpdated Event". Там рассказано, как пропустить подобную ошибку с помощью UpdateStatus.SkipCurrentRow.
Сам не пробовал (не было нужды), но документация вроде довольно логичная...
Я рад что присоединился столь квалифициированный пользователь. Но пропустив ошибку и откатив транзакцию мы получим следующую альтернативу ( я это детально исследовал на примере рписанном в начале) а) статусы не изменились ( у кого был до транзакции modified то так и остался) при повторном сохранении ошибка Concurency violatoion!
б) Статусы скинулись — ну тогда кранты (
Честно говоря, сейчас у меня нет времени подробно разбираться в проблеме.
Навскидку, я бы копировал данные перед сохранением и не мучался бы с построчной обработкой.
Реально, когда нужно отправить пакетный запрос на сервер, я обычно именно так и делаю — через OPENXML. И работает быстрее (не по одной строчке) и все происходит в рамках одной транзакции...
Получается, что реально медотом DataAdapter.Update и не воспользуешся! Удивительно то что аналогичная вещь в Delphi есть со 2-ой версии (1996 год!!!) и ни каких проблем не вызывает, только из за того что тем же авторм (Андерсом Хейльсбергом) реализовано без наворотов!
(