Медленно изменяются записи при включенном CachedUpdates

← →
Loginov Dmitry © (2007-01-09 08:08) [0]

BDE, Paradox. Есть табличка, 4 тыс. записей. Список товаров, закупочные, розничные цены. Так вот: при включенном CachedUpdates обновление поля розничной цены даже для 500 записей выполняется порядка 5 минут. Если опция выключена, то обновление записей происходит моментально. Однако, на добавление новых записей CachedUpdates влияние практически не оказывает (добавление работает с приличной скоростью).
Интересно, у всех такая же "фича"? Как с нею бороться?

← →
ЮЮ © (2007-01-09 08:44) [1]

А с какой целью кэширование используется?

← →
ЮЮ © (2007-01-09 08:45) [2]

а запрос на изменение покажи

← →
Desdechado © (2007-01-09 12:01) [3]

похоже, нет ID или индексов, идет full scan при поиске нуждающихся в обновлении строк

← →
Loginov Dmitry © (2007-01-10 07:40) [4]

> А с какой целью кэширование используется?

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

> а запрос на изменение покажи

TQuery, RequestLife=True, SELECT * FROM Table

> похоже, нет ID или индексов, идет full scan при поиске нуждающихся
> в обновлении строк

Первичный ключ там есть.

Вообще почему-то скорость падает экспоненциально. Для 100 записей достаточно 10 секунд. Для 500 записей уже требуется 5 минут.

← →
ЮЮ © (2007-01-10 08:24) [5]

> > а запрос на изменение покажи
> TQuery, RequestLife=True, SELECT * FROM Table

:) Мне казалось, что при кэшировании изменений всегда требуется TUpdateSQL, чей запрос на изменение и хотел увидеть

> А с какой целью кэширование используется?
>эмуляция транзакций.

Тогда иначе: зачем нужна транзакция для записи в одну таблицу таких объемов информации за раз? Кроме, конечно, бесполезности труда при откючении питания на клиенте?

← →
Desdechado © (2007-01-10 11:23) [6]

Запрос на обновление у тебя по ID или по всем полям? Или по какой-то их комбинации?

← →
Loginov Dmitry © (2007-01-10 23:36) [7]

> Мне казалось, что при кэшировании изменений всегда требуется
> TUpdateSQL, чей запрос на изменение и хотел увидеть

А разница? С RequestLife=True достигается тот же эффект. Тормоза теже.

Похоже, что здесь действительно ничего не поделать. Т.е. используя в совокупности TQuery (или TTable) + BDE + Paradox + CachedUpdates какая бы структура таблички не была, врядли кому-нибудь удасться изменить более 10000 записей (человеческого терпения не хватит).

Эх.. не хотелось...
Paradox - ацтой!!! TQuery + CachedUpdates - ацтой!!! BDE - ацкий ацтой!!!

... фух.. полегчало :)

> Т.е. используя в совокупности TQuery (или TTable) + BDE
> + Paradox + CachedUpdates какая бы структура таблички не
> была, врядли кому-нибудь удасться изменить более 10000 записей
> (человеческого терпения не хватит).

так проблемы уже и при 500 записях наблюдаешь.

Кстати. В одном проекте есть TQuery для навигации. И в этом запросе отображается часть редактируемой информации. Чтобы не переоткрывать запрос после редактирования записи, сделал его CachedUpdates, и в него вносил изменения после изменеиях в таблице.

Так вот, здесь наблюдается такая вещь: в самом начале инкрементный поиск по TQuery (Locate) просто "летает". По мере накоплений изменений начинаются "тормоза". Похоже у твоей и описанной проблем ноги растут из того же места.

> так проблемы уже и при 500 записях наблюдаешь.

Так это в базе данных которая на работе. Там в табличке более 20 полей, и изменению может быть подвергнуто любое поле.
Дома же создал простейшую табличку из 3-х полей (ID, Name, RPrice), забил в нее 10000 записей (это происходит быстро даже с включенным CachedUpdates), и уж потом ставил эксперименты. Получилось, что первые 4000 записи изменяются порядка 2-х минут, а далее замедляется настолько, что оставшиеся 6000 записей на вскидку будет изменять часа 3.

> [9] Loginov Dmitry © (11.01.07 07:47)

Ну так если проблемы появляются с ростом числа изменений, сделай через каждые 100, например, записей ApplyUpdates и делов-то.

Медленно изменяются записи при включенном CachedUpdates Найти похожие ветки