Всем привет. Кто нибудь знает есть ли в firedac что-нибудь на подобие локальных точек сохранения?
То есть к примеру есть код:




при этом savepoint1 равен savepoint2, и если я захочу вернутся к состояния после добавления строки то через savepoint's это реализовать не выйдет.

wadman, не совсем понял к чему ты об этом.

у меня есть table: TFDTable, у которого cachedupdates=true, и мне нужно в момент редактирования иметь возможность откатиться к тому или иному изменению, но не держа для этого собственный журнал изменений

чччД, дык изменения на сервер не отправляются ведь.

чччД, нее так нельзя)) все реализовано на кешировании)

фактически если добавить и удалить эту же запись в updates не будет записей для отправки на сервер,и соответственно сэйвпоинты бесполезны в этой ситуации, есть ли свойство отвечающее за то как хранить изменения до отправки на сервер, т.е. держать абсолютно всё а при отправке на сервер уже выбирать только нужное, тогда и логично что сэйвпоинт будет после каждого изменения всегда новый?

defecatorRuslanSharipovфактически если добавить и удалить эту же запись в updates не будет записей для отправки на сервер,и соответственно сэйвпоинты бесполезны в этой ситуации, есть ли свойство отвечающее за то как хранить изменения до отправки на сервер, т.е. держать абсолютно всё а при отправке на сервер уже выбирать только нужное, тогда и логично что сэйвпоинт будет после каждого изменения всегда новый?

Использование транзакций, как уже сказали, снимает головную боль и сокращает велосипеды в коде.


я не могу понять как использование транзакции поможет в ситуации с "локальным" изменением?

если я правильно понимаю ты предлагаешь что то типа:

, но в этом случае запись все равно удалена

defecator, походу мы друг друга не понимаем)))

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

wadman,
так это очевидно, хотелось не прибегать к этому, думал есть в firedac что то наподобие "локальных сэйвпоинтов" или "локальных транзакций"(что было бы логично и удобно, изменил что то в нд и во всех с ним связанных нд, передумал и вернул все нд к исходному состоянию), ан нет

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

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

wadman, postgresql и mssql

defecator, доп таблица в которую пишутся имя таблицы и айдишник записи

чёт мы не в ту степь пошли)