v7: ошибка в итогах регистра - как поправить #690106

1С 7.7 ТИС ДБФ Есть у меня регистр Движение Бухт. И вот по одному товару после сбоя получил такое на начало - 0 бухт приход    - 20 бухт расход    - 20 бухт на конец  - (-10)бухт Тестирование делал (без пересчета итогов). Не помогло. регистр имеет измерения склад товар метраж и ресурс количество бухт по товару с кодом 00223 и метражом 10 возникла такая ошибка

быть не может. сделай отчет и посмотри какими документами выполнены движения

и пересчитай наконец то итоги

не могу пересчитать итоги, очень долго будет и у меня УРБД и база 6 ГБ. Это случилось 29.11.2013. До этого показывало нормально на начало - 1 бухта на конец  - 1 бухта

"не могу пересчитать итоги, очень долго будет и у меня УРБД и база 6 ГБ" - быть такого не может. У нас база на 60 гиг за ночь пересчитывалась, правда на шустром сервачке

Я что-то забыл. Ведь пересчет итогов на обмен УРБД никак не должен повлиять?

ну 60 за ночь это ты хватанул. а у меня 19 гигов за ночь пересчитывает. хотя конечно если сервка на i99 тогда может ;)

Не должен Считал считал, правда у нас там был только 1 большой регистр по учету затрат

на копии запущу пересчет итогов. проверю

я что-то вечно опасаюсь пересчитывать итоги из-за УРБД. Хотя вроде никакого отношения к обмену пересчет не имеет.

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

а разве при проведении транзакция не открывается автоматом?

проведение выполняется в транзакции - это реализовано на уровне движка. а некторые умники выполняют проведение (несколькх/набора документов) в транзакции. при этом вложенные транзакции 1с НЕ поддерживает. и если при таком проведении на каком-то документе вылетает по ошибке - то при незавершенной или отмененной "внешней" транзаккции (изменение статуса документа на "проведенный" не выполняется) - внутренняч получается авто-зафиксированной, и у помеченного на удаление документа зависают движения - которые тупо есть, а вот увидеть их, например, штатно через ПКМ на документе в форме списка (журнале) - никак, там даже пункт "показать движения" недоступен, потому что его доступность движком определяется по статусу(признаку) "проведен".

Вот до сих пор в копии итоги пересчитываются

Дарю Слово "Долго" не принимается, у нас БД вообще то 40 Гб ишо? :) Пересчет итого сутки... 6 Гб, это 2-3 часа в худшем случае :)

Ты его на Буке запустил? :) Надеюсь ты когда запустил ТиИ, то выбрал только пересчет служебной информации и итого? Не стоит ставить все галочки :)

" и в регистре появляются движения по непроведенным или даже помеченным на удаление документам, а их увидеть не так уж и просто..." Просто. Если база sql то есть моя обработка ( на инфостарте) которая ищет различные ошибки в 7.7 sql базе. Если там какой-то ситуации нет а тебе очень нужно то могу дописать.

База ДБФ. Пересчитываю на копии.

ЧеловекДуши - ну ты крут. Правда там все больше по 8-ке а у меня 7.7 ДБФ. Пересчет еще идет на копии - и конца опка ен видно

Ну ведь я же знаю что до 29.11.2013 все показывает нормально. Значит случился сбой 29.11.2013. В периферийках тоже все показывается нормально и неважно на какой день, то есть там сбоя не было

самое простое решение (для тебя): 1. Сделай копию базы 2. удали все RG (и их индексы) 3. Удали все RA кроме пересчитвываемого регистра (и их индексы) 4. проверь физическую целостность (создадутся пустые файлы вместо удаленных), переиндексируйся (создадутся индексы) 5. пересчитай итоги. 6. скопируй нужный RG и его индекс в боевую базу. -----------

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

2-3 часа - это для кого-то может быть слишком долго....

проведение помеченых на удаление документов - не меньшая глупость. он вообще "мастер глупостей"™.

а зачем почти все RA и все RG? Я точно знаю что проблема в одном регистре

вот RA, которого надо пересчитать - и надо оставить.

не люби мозги - сделай пересчёт итогов

Спасибо. У меня еще книги покупок и продаж сто лет не закрываются. Нет у меня их формирования в ТИС. Все в бухгалтерии формируется. Надо закрывать хотя бы с 2010 года

Делаю на копии. Может к завтра и пересчитаются. Хотя сервер вполне мощный

я думаю по-другому сделать. распровести этот документ, перепровести его и затем за ноябрь просто перепровести базу. Это совсем не долго будет

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

может пора свёртку базы делать?

примрно так, как на более позних конфах восстанавливаются последовательности... именно про это и речь!

вы не французский ли дворянин из рода Биллов? вот потому-то пересчет и идет так долго. анафига? судя по всему, у него мелконькая базенка....

6 гб сутки пересчета. Забавно.

Я в ручную быстрее пересчитаю

Да база немаленькая и пользователей порядка 40 У меня регистр партий большой, почти 1.5 ГБ. Свертку буду делать в январе, мы оставляем 3 года обычно. Хотя сейчас уже получилось четыре.Но свертку делаю с помощью обработки, которая все делает быстро, но остатки формирует не прошлым годом, а 1 января текущего года.

То что проблемы с базой имеются - я знаю. И пересчет итогов идет очень долго. Что интересно - если запустить выгрузку-загрузку, то пересчет будет намного шустрее. Но это на новогодних каникулах чтоб еще и новые периферийки создать успеть.

Буду пробовать вообще всю базу перепроводить начиная с начала. Откачу точку актуальности на январь 2010 года.

потому что смотри на ИСе "Шьiшки для мартышки" - там есть и для ДБФ и для скуля

сделай бэкап. удали (для дбф - физически удали файла, для скуля занули соотв. таблицы) итогов и движений по всем регистрам. . и перепроводи с начала времен со сдвигом ТА. . 6 ГБ - долговато сутки считать. . проверяй на закрытие регистры кассы (деньги вносят, но не изымают), книги покупок/продаж, комиссия если есть. При тових объемах месяц ну в самом крайнем случае минут 15 должен открываться.

перепроведи месяц. остановись на последнем дне. сформируй закрытие меясца по книге покупок/продаж. открой следующий месяц - делать руками или программнодо опупеняи

ну я так и хочу. период как раз открывается на центральной базе минут 5 не больше. Поэтому неопнятно почему так долго итоги пересчитываются

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

это тест на артикулицию?

Судя по это он про возможность существования записей регистра для непроведенного документа. Но может он и не об этом...

базу в RAM - все пересчитается мигом

В DBF-ном движке нет вложенных транзакций. Нет различия каким образом она запущена встроенным языком 1С-а. На каждое Начать-Зафиксировать транзакцию ведется счетчик +1 -1. Реальная транзакция запускается только для "верхнего" уровня. Если в "нижнем" уровне происходит отмена транзакции (по любой причине - явно или неявно), то взводится признак который не позволяет выполнить фиксацию реальной транзакции. Т.е. заменяет фиксацию на откат. Проверено :-) тут: