Отрезали мы недавно БД (нетиповая торговля на регистрах) с помощью данной разработки: http://infostart.ru/public/100646/ подправленную под работу на нашей конфигурации.
Теперь формирование отчета по регистру взаиморасчетов формируется аж по 10-15 миунт вместо 1-2 минуты. С чем это может быть связано?

P.S. Остатки по другим регистрам формируются быстро как и до резки.
Перенос ТА на новый месяц проходит тоже долго 10-15 минут вместо 1-2 минуты.

В чем может быть причина? Что можете посоветовать?

обороты остались незакрытые?

хЕрурги, что еще можно сказать...

SQL?

DBF

Упаковку таблиц и полное ТИИ делали?

(5) думаешь удаленные записи в расчетах участвуют?

Упаковку делал. Полный пересчет итогов не делал, у нас он выполняется больше суток.
Как делать херургию, можно ссылку?

(1) что значить незакрытые обороты?
обороты удалились вместе с документами

(6) Ну участвуют, но "мешают". Хотя по времени не такой проигрыш должен быть.

Скорее всего криво свернулось.

ТИИ надо делать, предварительно удалив RG*.dbf

(10) будем пробовать, спасибо
Можно ли как-то сделать пересчет итогов только для одного регистра?

>>>> После резки итоги по одному регистру очень долго считаются

Тут возникает вопрос, а что автора побудило отрезать прошлый период?
И как быстро работали итоги до резки?
И тут же думается, что автор дилетант, и побудило его отрезать прошлый период только одно, увеличить производительность БД.
Соответственно он не удосужился разобраться в движениях :)

(7)>>> Полный пересчет итогов не делал, у нас он выполняется больше суток.

Очередное подтверждение моего довода, что у автора кривые итоги, которые не выпрямляются через ТиИ. Решение только одно, исправить движение по кривым регистрам. А именно долго думать :)

(11) писали как то в недавно
1. Скопировать все RA*.DBF, RG*.DBF в отдельную папку
2. Удалить все RA*, RG* (с индексами), кроме RA*.DBF, который нужно пересчитать.
3. Запустить, пересчитается только этот регистр (вернее все остальные будут пустыми)
4. Снова удалить все индексы, скопировать в базу из (1) все файлы, кроме RG*.DBF, который пересчитали, восстановить индексы.
Как то так.
САМ НЕ ПРОБОВАЛ

(12) автор отрезал прошлый год потому что один из файлов вырос до 2-х Гб. Последствия, я думаю, описывать не надо...
(13) оригинальный способ, спасибо, попробую

(14) Т.е. поборол последствия, а не причину?
Через год опять резать?

(11) можно

(13) так и надо.

но проще запросом пересчитать

(16) только методом (13). геморно

(18) дбф

(15) да, да
(18) есть пример запроса?
(20) разве в dbf нельзя выполнять запросы?

(21) для дбф нету, не было необходимости в этом.

(22) ну хоть для SQL

для скуля, есть как минимум ..3 реализации этого

http://webfile.ru/6116204

(25) спасибо огромной, будут ковыряться

(24) у меня даже с выборочным пересчетом...

(13) УРА!!!! Получилось. Спасибо огромное!!!