Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Непонятный глюк у TTable [D5, D6, Paradox]

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

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

Weare (2003-05-23 11:58:00) [1]

> Pat © (22.05.03 22:45)

Спасибо еще раз.

Pat (2003-05-22 22:45:00) [2]
>А можно ли как-то заставить значению уже присвоиться
>автоинкрементному полю
Нет.
>Хотя с временными таблицами-это идея.
Особенно, если тебе надо сделать "откат" в таблицах со связью один-ко-многим

Weare (2003-05-22 19:50:00) [3]

> Pat © (22.05.03 16:51)

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

Pat (2003-05-22 16:51:00) [4]
Если в качестве первичного ключа используется автоинк поле, то это нормальное поведение таблицы. Дело в том, что при CachedUpdates физически данные не вставляются в таблицу, пока не вызовешь ApplyUpdates, следовательно, новая запись не имеет значения ключегого поля, и поэтому вставляется первой.

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

Dred2k (2003-05-22 16:17:00) [5]
> Weare © (22.05.03 16:10)

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

Weare (2003-05-22 16:10:00) [6]

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

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

Dred2k (2003-05-22 16:05:00) [7]

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

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

Dred2k (2003-05-22 16:03:00) [8]
Записи скачут вверх потому, что не обновляется текущий навигационный индекс (первичный ключ, как правило), согласно которому строится порядок отображения записей. Когда кэш обновлений зафиксирован (applay), обновлен и индекс(ы) (ключ).
Вот такая версия (в диалоговом режими CU еще не приходилось юзать - использовал только для "невизуальных" операций, при этом порядок был абсолютно не важен...).

Stas (2003-05-22 16:02:00) [9]
А ты делай транзакцию.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »