Сохранение всех изменений в таблице и их отмена.

← →
Weare (2003-04-04 13:34) [0]

Доброго дня, уважаемые мастера.

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

Слышал я что-то про свойство CashedUpdates, но не знаю как с ним бороться, из хелпа ничего не понял :(

Прошу прощения за такой вот ламерский вопросик :)
Спасибо.

← →
zacho (2003-04-04 13:42) [1]

А чего там понимать ? Делаешь CachedUpdates:=true; Хочешь подтвердить изменения - DataSet.ApplyUpdates, отменить - DataSet.CancelUpdates.
Еще можешь посмотреть на TDataBase.StartTransaction, Commit, Rollback.

← →
Mike Kouzmine (2003-04-04 13:56) [2]

Onbeforescroll, BeforeInsert
if not t.state in [dsBrowse] then t.Cancel;

← →
Weare (2003-04-04 16:18) [3]

Спасибо, но тогда как связано индексирование таблицы со свойством

CashedUpdates. У меня ругается, если я его ставлю в True: "Table is not indexed".

← →
NickBat (2003-04-04 16:22) [4]

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

← →
Mike Kouzmine (2003-04-04 16:23) [5]

А какие стандартные средства навигации?

← →
NickBat (2003-04-04 16:26) [6]

DBNavigatorBar к примеру.
Я имел ввиду, что если вывожу таблицу, то только для просмотра. Если пользователь, что-то правит, то ему сначала надо сохранить свои исправления.

← →
Mike Kouzmine (2003-04-04 16:28) [7]

Я навигатор не использую вообще.
А если ему не надо сохранять? Злой Вы.

← →
Mike Kouzmine (2003-04-04 16:29) [8]

Шутка.

← →
NickBat (2003-04-04 16:31) [9]

>Mike Kouzmine © (04.04.03 16:28)
>Я навигатор не использую вообще.
>А если ему не надо сохранять? Злой Вы.

Ну или отменить :)))

← →
Weare (2003-04-04 16:36) [10]

Все это хорошо, а если надо менять несколько записей, а уж потом думать сохранять это или нет.

Кстати, спасибо zacho - все работает. Вот только пришлось проиндексировать все таблицы. Никак не могу понять как связано это свойство CashedUpdates c индексацией, может кто знает???

← →
NickBat (2003-04-04 16:55) [11]

>Weare
Приведите пример когда пользователю надо менять ОДНОВРЕМЕННО несколько записей в ОДНОЙ таблице.

← →
Dred2k (2003-04-04 17:02) [12]

> Weare © (04.04.03 16:18)
> Спасибо, но тогда как связано индексирование таблицы со
> свойством
>
> CashedUpdates. У меня ругается, если я его ставлю в True:
> "Table is not indexed".

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

← →
Mike Kouzmine (2003-04-04 17:05) [13]

Можешь попробовать использовать транзакции. Иногда помогает.

← →
Weare (2003-04-04 17:16) [14]

>to Dred2k
> Пробовать не охота, но предположу, что связано с отсутствием
> первичного ключа. Попробуй. У меня великолепно пашет, но
> везде в таблицах есть первичный ключ (суррогатный ID или
> ROW, как правило). Вот такая версия...

Да это как раз из-за первичного ключа, но при чем тут он?

>to NickBat © (04.04.03 16:55)
> Приведите пример когда пользователю надо менять ОДНОВРЕМЕННО
> несколько записей в ОДНОЙ таблице.

Мне не надо ОДНОВРЕМЕННО менять. Дело тут вот в чем, пользователь открыл какой-то документ, например "приход товара" (это из моей задачи). Делает там определенные изменения, и потом видит, что где-то ошибся и ему не надо, чтобы сделаные изменения вступали в силу, так он этот документ просто не сохраняет.

Спасибо всем, у меня все уже работает (отдельное спасибо zahco), мне все-таки не понятно как связаны CashedUpdates и индексирование таблицы.

← →
NickBat (2003-04-04 17:21) [15]

>изменения, и потом видит, что где-то ошибся и ему не надо,
>чтобы сделаные изменения вступали в силу, так он этот документ
>просто не сохраняет.

Ну так вперед и не сохраняй на здоровье! При чем тут несколько записей, если он открыл документ "приход товара"? Документ-то один и запись, как я понимаю, одна?

А вообще-то для этого есть транзакции.

← →
Dred2k (2003-04-04 17:31) [16]

> Weare © (04.04.03 17:16)

> Да это как раз из-за первичного ключа, но при чем тут он?

...

> мне все-таки не понятно как связаны CashedUpdates и индексирование
> таблицы.

Судя по твоему письму, понятно.
;)
А насчет "при чем ключ" - подозвреваю, что нужно для внутренней реализации BDE. И еще. Механизм транзаций и кэшедапдейтов для парадокса, скорее всего, один и тот же (или похож).
Вот выдержка из хелпа bde32.hlp по транзакциям

To perform transactions on a Paradox table, a valid index must exist. Data cannot be rolled back on Paradox tables lacking an index.

Таким образом, нужен нормальный индекс. А первичный ключ в общем случае - это уже перебор (хотя тоже индекс). ;)
А вообще, поищи в сети - наверняка есть статьи на этот счет. Кажется, видел на Королевстве Дельфи ( http://www.delphikingdom.com), но могу ошибиться...
Яндекс нам поможет.

← →
Weare (2003-04-04 17:36) [17]

>to NickBat © (04.04.03 17:21)

> Документ-то один и запись, как я понимаю, одна?

Нет, если документ один, то это не значит, что там запись одна. К примеру, в этом документе могут "приехать" и 20 розеток, и 15 выключателей, и еще чего-нибудь.

← →
MsGuns (2003-04-04 19:42) [18]

>Weare © (04.04.03 17:36)

NickBat прав и я подписываюсь под каждым его словом начиная от запрета юзеру свободно куролесить по всему гриду и кончая поддержкой нормальных транзакций.
В случае же "отката" всех изменений, к примеру, в фактуре накладной, одними отменами изменений в документе не обойдешься, тем более что парадокс в принципе не поддерживает транзакции (вплоть до 8-й версии). Хотя бы потому, что изменение кол-ва в любой строке накладной может сразу "отражаться" в нескольких совершенно других таблицах, с которыми юзер в данный момент вроде бы и не работает. Например, в таблице остатков, таблице заказанного товара и т.д. Если делать как в 1С, т.е. "откатывать" весь документ, а потом его править и соотв-но "закатывать", то отмена действий во время правки как бы теряет свою актуальность. Если же реализовать нормальную (ИМХО) интерактивную многопользовательскую модель (Валя ввела, а Таня сразу увидела), то во-первых, надо дать Вале "кнопулю" типа "Сохранить изменения", а во-вторых кинуть парадокс к чертям собачим и перейти на нормальную КССУБД.

Сохранение всех изменений в таблице и их отмена. Найти похожие ветки