Непонятный глюк у TTable

← →
Weare (2003-05-22 15:56) [0]

Может кто-нибудь подскажет как обойти следующий глюк.
Мне необходимо, чтобы можно было отменять сделанные изменения в таблице, поэтому св-со таблицы CashedUpdates ставлю в True.
После добавления записи в грид, который ссылается на Table с включенным св-вом CashedUpdates, запись перескакивает на самый вверх. Если еще одну добавить, то она перескочит выше предыдущей. Но когда переоткрываешь таблицу(программу), то эти новые записи отображаются в конце в порядке их занесения туда. Что это за глюк такой, ведь с отключенным CashedUpdates эти записи, как и положено, записываются в конце и не скачут?
Подскажите, плиз, как избавиться от этих перескоков?

Извините, что повторяю этот вопрос, но я так никакого ответа на него не получил. Что ни у кого не возникало такой ситуации?
Спасибо.

← →
Stas (2003-05-22 16:02) [1]

А ты делай транзакцию.

← →
Dred2k (2003-05-22 16:03) [2]

Записи скачут вверх потому, что не обновляется текущий навигационный индекс (первичный ключ, как правило), согласно которому строится порядок отображения записей. Когда кэш обновлений зафиксирован (applay), обновлен и индекс(ы) (ключ).
Вот такая версия (в диалоговом режими CU еще не приходилось юзать - использовал только для "невизуальных" операций, при этом порядок был абсолютно не важен...).

← →
Dred2k (2003-05-22 16:05) [3]

> Stas © (22.05.03 16:02)
> А ты делай транзакцию.

Paradox и транзакции - никому не посоветую. ;)
(хотя BDE это и поддерживает в определенной степени, но работает сие тварение с бАльшими траблами, хотя и строится, по ходу, все на тех же CU).

← →
Weare (2003-05-22 16:10) [4]

> Dred2k © (22.05.03 16:03)
> Записи скачут вверх потому, что не обновляется текущий навигационный
> индекс (первичный ключ, как правило)

Может вопрос покажется глупым, но можно ли, тогда как-то обновлять индекс, например на OnNewRecord. И если да, то как? :(

← →
Dred2k (2003-05-22 16:17) [5]

> Weare © (22.05.03 16:10)

Я написал, что у меня таких заморочек (необходимостей) при работе с CU еще не было (а тестировать времени нет).
Мое дело версию изложить, твое дело, как разработчику, версию проверить. Причем по хелпам, документам и т.п. Советую начать с bde32.hlp.

← →
Pat (2003-05-22 16:51) [6]

Если в качестве первичного ключа используется автоинк поле, то это нормальное поведение таблицы. Дело в том, что при CachedUpdates физически данные не вставляются в таблицу, пока не вызовешь ApplyUpdates, следовательно, новая запись не имеет значения ключегого поля, и поэтому вставляется первой.

P.S. Вместо CachedUpdates использую временные таблицы. Копируй данные с помощью CopyTable(). Когда надо сохранить измененные данные - копируешь обратно и удаляешь временные таблицы.

← →
Weare (2003-05-22 19:50) [7]

> Pat © (22.05.03 16:51)

Спасибо.
А можно ли как-то заставить значению уже присвоиться автоинкрементному полю, или какие другие способы?
Хотя с временными таблицами-это идея.

← →
Pat (2003-05-22 22:45) [8]

>А можно ли как-то заставить значению уже присвоиться
>автоинкрементному полю
Нет.
>Хотя с временными таблицами-это идея.
Особенно, если тебе надо сделать "откат" в таблицах со связью один-ко-многим

← →
Weare (2003-05-23 11:58) [9]

Непонятный глюк у TTable Найти похожие ветки