Сегодня у пользователя возникла ошибка в модуле проведения документа.
"Значение не представляет агрегатный объект (Банк)"
Ошибка возникла на строке "ВремБанк = ВремРегистры.Банк" в коде:

Процедура ОбработкаПроведенияПрочее()
    ВремРегистры = СоздатьОбъект("Регистры");
    ВремБанк = ВремРегистры.Банк;

Понятно, что какой-то эпизодический глюк, землятресение в Японии, буря на Сатурне и прочие глобальные причины. Но прикольно.
Всякие TurboMD не используются. Регистр Банк точно есть :)

Ключ торговли, точнее, оперучёта, теряется.

(1) тогда ошибка была бы на первой строке

Товарищ ТИИ, и госпожа ВыгрузкаЗагрузка что говорят ?

+(2) перепроверил СоздатьОбъект("Регистры") не выдает ошибку при отсутствии компоненты оперучета.
скорей всего (1) прав

(1) Ключ потеряться не может, он лежит у меня в ящике стола :) Хотя, да, предположение логичное.
(3) ТИИ и выгрузка/загрузка говорят, что на 100+ гигах они объявляют забастовку.
Меня, в общем то, какое-то решение не волнует. Согласен считать случайным сбоем. Просто тематично-пятнично выглядит.

А так?
СоздатьОбъект("Регистр.Банк");

(6) Повторение ошибки не представляется возможным. Банковские документы делаются десятками в день несколькими пользователями. Ошибка возникла один раз.

Если база в ДБФках то имеет смысл проверить размеры файлов , вдруг их размер близок к кретиничному.

А сегодня то есть вчера - пятничная ветка была? - что-то не могу найти!

(8) дбф база в 100+ гигов - это очень пятнично :)

(10) ага.. хочется посмотреть на структуру данных - сколько у него регистров... и чего-тотам еще..
.
с учетом того что в одной файло не более 16млн записей - 10 гиг это надо постараться... может, конечно записи очень длинные.. гораздо длинее 22 см...

а я бы глянул кто в конфигураторе на рабочей базе учится

(11) 40 было. Что не так делали??

(13) не знаю ;-) сделать не так - стотыщ способов ;-)
я просто офигеваю от количества данных.. - кто нит контролировал их непротиовречивость.? сходимость? правильность? или как..?

(14) конечно)) был вечно не закрытый регистр, который и дал сорок гигов))

Бывает

(14) Ну про непротиворечивость и правильность говорить не буду, специально не проверял. (Кстати, а какое влияние непротиворечивост оказывает на размер?)
Про всё остальное...
1. Номер один из таблиц по размеру к 1С относится косвенно. Это сохранённые печатные формы исходящих документов, привязанные к своим документам-владельцам. Всего пятнадцать гигов.
2. Номер два из таблиц по размеру, это итоги по регистру РеализованныйТовар (база на основе ТиС). Регистр закрывается. Данные в нём, как и положено, только за текущий месяц. Но порядка двадцати тысяч документов в месяц, почти двадцатьдве тысячи живой номенклатуры, жесткий партионный учет. Но всё равно пять гигов.
3. Аналогичный размер имеет регистр ПартииНаличие и где-то на гиг отстал ПартииОтданные. Оба закрываются. Не без мелких проблем, встречается иногда невыловленная вовремя зависшая себестоимость без количественного остатка, но этого мало.
4. Еще порядка пяти гигов _1SJOURN. На три с хвостиком миллиона документов. Да, согласен, что несколько общих реквизитов удалить бы. Может быть на ближайших длинных праздниках займусь.

Ну и так далее в таком стиле.

Да, совсем забыл сказать, почему такие большие одновременно РеализованныйТовар, ПартииНаличие и ПартииОтданные. У меня филиальная система, филиалы работают по агентскому договору. Центральная база консолизированная, содержит всю информацию. Значит в ней есть ПартииОтданные при передаче товара на филиалы, ПартииНаличие на филиалах и РеализованныйТовар при продаже на филиалах. Фактически, где-то три четверти итогов по партиям дублируется. Один и тот же товар числится по учету как ПартииОтданные в центре и ПартииНаличие в филиале.