Ребята, помогите разобраться в чём проблема, зависание на открытии периода. В базе прежним программистом( кем же ещё )) ) был задуман механизм отменяющий движения по регистру "Заявки" старше 30 дней. Решили убить этот механизм - распровели все заявки с начало времён по 01.10.2012, и запустили проведение базы. Сейчас процесс встал на открытии периода 01.12.2011. Что делать, куда копать, в чём причина?

База ДБФ. Размер файлов в порядке убывания:
- RG4674.DBF (830 Мб) - Итоги по Заявкам
- DT2457.DBF (183 Мб) - Документы ЗаявкиПокупателей
- RA4674.DBF (152 Мб) - Движения по заявкам

Остатков по регистру "Заявки" на дату 30.11.11 нет.

я бы для начала посмотрел, что за механизм

Механизм отменяется, если количество дней (30) поставить в ноль. Этот параметр в константу зашит.

Хотя бы понять саму проблему. Почему так итоги могли разрастись? ПРоцесс отмены заявок делал не я, поэтому не могу ручаться за точность исполнения. Поверил на слово. При личном выполнении в прошлый раз всё прошло штатно. ТЕоретически что могли сделать не правильно?

Вопрос в догонку, пытаюсь сделать полный пересчёт итогов, ругается мол "Порядок сортировки, установленный для базы данных, отличается от системного". Как менять порядок сортировки, знаю. Без этого база запускается. Отчего появлется эта надпись?

ты код покажи

(6) Какой код? Вы о чём? Код механизма? Да он незамысловатый -  отменяет штатные движения по регистру, если дата документа превышает константу. Если константа = 0 то механизм проведения движений штатный.

Так у вас просто регистр заявок теперь не закрывается. Там небось закрытие этого регистра только на отмене проведения и основывалось.

(7) тогда почему у тебя регистр не закрыт ?

(7) Вам теперь надо другой механизм закрытия реализовывать, если вам предыдущий не подошел.

(10) ну например не отменой проведения заявок, а проведения какого-нибудь документа "Снятие заявок".

(8) почему не закрывается? По отчетам ни движений, ни итогов по регистру нет. На 30.11.2011 Зависание начинается при открытии периода 01.12.11.

(12) Потому что файл итого по размеру больше чем файл движений, намного.
Или упаковку таблиц сделайте. Чтобы правильнее оценить можно было.

(13) И зависает, наверное, как раз при переносе итогов по этому регистру, потому как дофига их.

Мне не понятно, что мог исполнитель (тот который отменил распровел все заявки и начал проводит базу), что бы файл RG4674.DBF так разросся. Изначально, до этих действия он весил  36 Мб.

(15) так после тебя он так разросся ?

(16) после действий исполнителя. Я пока ещё ничего не делал.

(15) Ну ты ж сам и написал

" был задуман механизм отменяющий движения по регистру "Заявки" старше 30 дней. Решили убить этот механизм - распровели все заявки с начало времён по 01.10.2012, и запустили проведение базы."

(17) т.е. этот исполнитель сам создал механизм и сам сломал ?

Опиши как было реализовано

"механизм отменяющий движения по регистру "Заявки" старше 30 дней".

"предыдущий программист" и "Испольнитель" - разные люди. В (15) я уточнил, кто такой Исполнитель.

(20) Виктор, в чём смысл вашего вопроса? На что может повлиять ответ?   Насколько я понял, в модуле документа "ЗаявкаПОкупателя" проверяется дата документа, если она превышает константу, то движения по регистру не делаются. База регулярно проводится.

(21) Ну и чему сейчас равна константа ? Обнулена ?
Тогда сейчас у вас в регситр остатков по заявкам делаются только движения приход, соотвественно растет файл итогов по регистру.

(22)+ И для такого варианта не предусмотрено выполнение движений расход.

(22) Константа равна 0. При нуле, этот механизм не срабатывает (так прописано в условии). С чего вы взяли, что сейчас в регистре делается приход, если заявки все распроведены?

(24)+ ПО отчетам этих приходов до 01.12.11 нет.

Какой-нибудь универсальный отчет по этому регистру сформируйте с разворотом по всем измерениям.
Откуда-то ж у вас появилось куча итогов в регистре. Может там снятие другим видом документов делалось.

Если распровести все заявки и не делать проведение, после этого сделать упаковку таблиц, какие размеры таблиц получаться ?

(26) Я универсальный отчетом регистры смотрю. Итоги я могу посмотреть только на 30.11.2011, так как ТА на конец этого дня стоит. Ни остатков ни движений нет.

так что нужно сделать в конечном итоге ?

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

(29)
Была как то такая проблема
Дело в том, что итоги по незакрытым заявкам переносятся в каждый месяц.
Т.е. Если заявка не закрыта в 2000 г - то будет
12*12=144 записи в итогах.
Я вводил каждый месяц спец документ типа "Закрытие месяца по заявкам " .
Логика какие закрывать какие нет - от вашей специфики
Т.е. с 2000 г должно быть авто введено 144 таких документа
Размер RG станет сравним с RA

Журнал регистрации не фиксирует програмные изменения, если спецом это не прописать.

(32) даже если так - последнее, что делали с базу - это проведение.

(28) Ну сделай уже упаковку таблиц, че гадать-то. Или грохни RG4674.DBF и пересчитай итоги.

(34) Пока перекодитовар ИБ на текущую кодировку, сейчас идёт полный пересчёт итогов. Жду результатов.

(35) "перекодТОВАР" )))) Вот до чего доводит слепая печать - пальцы пишут на автомате.

(36) voronve гаф mail etc ru - мдшник слей

(31)+
Есть еще более радикальный способ - задним числом вводить закрытие заявок вообще по всем заявкам, кроме последних за 3- 5 месяцев. Тогда размер RG будет близок к 0.
Логика - юзеров интересуют только актуальные остатки по заявкам, по старым - только движения
Видимо Ваш прог так и делал

Зачем было ломать - непонятно

Ребята... по-моему меня можно уже начинать убивать...

Константа влияет на "Резевры ТМЦ". А не на регистр "Заявки". Начинаю анализировать заново.

>>распровели все заявки с начало времён по 01.10.2012

что только Заявки делали движения по регистру ?

Если нет - это во-обще п-ц

тот кто распровел

Блин. Всё-равно не понимаю, что происходит...

(40) Не понял вопроса. Если отменить заявки и провести базу - все остальные движения тоже будут отменены (к примеру закрытие всех заявок).

(42)
А - думал что не будете все перепроводить - уж очень объем большой
проще было как советовал - заняло бы пару часов и все движения остались

код модуля примитивный - выгрузка итогов по регистру на дату закрытия  и движение расход по нему

Ребята, дайте теорию - Файл RG*.dbf, хранит итоги и обороты до ТА? Значит он должен обнуляться, если я передвину ТА на начало времён? Или как-то по другому?

(45)
В RA хранятся итоги. В RG только итоги. Если периодичность хранения - месяц - то за каждый месяц + актуальные

В RA - движения, описался

А если я отменяю документ, который делает движения по регистру, то у меня итоги каждый раз пересчитываются получается?

(46) На вопрос (45) вы не ответили. Хранятся итоги ДО ТА, или ещё и ПОСЛЕДУЮЩИЕ?

Структура в типовой (смотришь файл .DD для файловой блокнотом)
#==TABLE no 152    : Регистр Заявки
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RG4674  |Регистр Заявки                |A          |RG4674     |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=PERIOD    |Period Registr      |D   |8     |0        
F=SP4668    |(P)Фирма            |C   |9     |0        
F=SP4669    |(P)Номенклатура     |C   |9     |0        
F=SP4670    |(P)ДоговорПокупателя|C   |9     |0        
F=SP4671    |(P)ЗаявкаПокупателя |C   |9     |0        
F=SP4672    |(P)КоличествоРасход |N   |16    |5        
F=SP4673    |(P)СтоимостьРасход  |N   |16    |2

(49) В RG Хранятся все итоги, в RA все движения.

(51) Ну так все итоги До ТА, или ещё и ПОСЛЕ?

Если сдвигаешь ТА то итоги "последующие" не хранятся
Документы как бы проводятся в реальном времени - поэтому быстрее в разы , чем просто перепроведение

точнее они помечаются

(54) В смысле если я передвину ТА на начало времён и упакую Таблцины, то они будут Нулевые?

(55) Нет, передвинь ТА и рассчитай итоги.

(56) И RG обнуляться?

(56) + А лучше двинь ТА назад, грохни RG и рассчитай итоги, быстрее будет.

(58) Мне не для самой цели, обнулить, а понять теоретически.

(57)
Если насчет размеров - не происходит непосредственного удаления записей - используется механизм пометок

ТА на начало
Выгрузить/загрузить

Ещё вопрос по теории:
Как считаются остатки на ТА?
Берутся итоги из RG, на начало месяца ТА, плюсуются движения по RA от начало месяца до ТА? Так?

ИЛИ ДАнные на ТА уже где-то расчитаны?

Данные на ТА уже рассчитаны в самих итогах. Там итоги хранятся по периодам в соотвествии с заданной периодичностью хранения итогов.
Технических в файле RG есть поле "Period" куда пишется дата начала очередного периода. Соотвественно на дату ТА они уже рассчитаны. Выбираются записи по "Period" соотвествующему ТА. Для получения остатокв на произвольную дату, берутся итоги предыыдущего периода плюс движения да даты остатокв.

Как-то так.

То есть на дату ТА выполняется запрос вида

Select
From RG
Where Period = НачалоПериодаПоТА

Тут еще почитай.

http://www.script-coding.com/v77tables.html#3.4.1.

(66) мерси за наводку!

А в (64) по-моему вы не правы, данных по ТА там не расчитаны. Там расчитаны итоги за периоды, но никак не по ТА.

(67) Рассчитаны. За текущи период итоги поддерживаются всегда актуальными.
То есть, например, ТА на 04.11.2012.

В таблице RG записи в которых "Period" = "01.11.2012" и будут остатками на ТА = 04.11.2012. Они поддерживаются актуальными.

Точняк. Спасибо.