Скачать: CL | DM;

Медленно изменяются записи при включенном 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 - ацкий ацтой!!!

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

---

← →
ЮЮ ©   (2007-01-11 04:34) [8]

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


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

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

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

---

← →
Loginov Dmitry ©   (2007-01-11 07:47) [9]

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


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

---

← →
evvcom ©   (2007-01-11 14:28) [10]

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

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

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.48 MB
Время: 0.027 c