Остатки по регистрам #19397

Ситуация такова - база 2 Гб, слетели остатки. Оставил на ночь крутитьтся на серваке пересчет итогов - не успела.Подскажите пожалуйста, как можно быстро пересчитать остатки по регистрам.

Ап

Up

Ну например купить нормальный комп или разогнать старый.

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

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

Сначала неплохо бы выяснить с каких таких конфет остатки слетели, а то будешь раз в неделю заниматься такой фигней

Взять архив за прошлый день и через ОЛЕ добавить документы за текущий день.

2Ага, а ежели правили задом ???.2Что за стервер-то такой чахлый ???.

- сервер точно не знаю какой - проц. Xeon стоит.

а мой опыт говорит мне что у регистров нет субконто Если база на sql то появлялся тут человек который предлагал обработку очень быстро пересчитывающую итоги.* * *На dbf платформе другого способа нет

Dbf - под терминалкой работают.

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

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

Если знаешь хотя бы примерно причину то . Иначе выхода нет кроме того чтобы стандартными средствами пересчитать итоги.* * *Если ну никак не удается без юзеров стандартными средствами пересчитать итоги - пиши обработочку которая в разделенном режиме будет потихоньку перепроводить все документы.

С таким до этого встречался только на "Бухгалтерии", и даже не представляю, отчего такое могло произойти. Буду пробовать запускать у себя.

А в чем проявляются слетевшие итоги?

Остатки - начало 10, приход - 0, расход - 0, конец - -50. Примерно так. Притом такое по регистру остатков, по партиям похоже нормально.

Только пересчет стандартными способами. Ничто другое не поможет

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

Увеличивать производительность сервера, разгоняй его до экстремальных режимов. Потом только верни все на меcто ж-))

Запустил на своем серваке - буду ждать.

Ни хрена это не поможет. Если таким образом слетают итоги - то нет просто документа который это спровоцировал. Итоги неправильные понимаешь ...

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

Если слетают индексы то их достаточно грохнуть и 1с-ка их восстановит.* * *Данные в отчет попадают из cdx? Индексы служат для установки связей и ускорения выборки данных. В отчеты ничего из индексов не попадает !!!

2"загрузи базу саму в себя","В подобной ситуации как правило слетают файлы .CDX, а когда загружаеш саму в себя они восстанавливаются из .DBF. " - что за БРЕД.При любой загрузке итоги пересчитываются.

Пробовал перепровести документ, который двигал данную номенклатуру, ничего не изменилось.

Так никогда не бывает что ОДИН вид документов делает движения по регистру (если он не оборотный). Тут скорее несколько видов

+ В типовой ТиС больше 20 документов могут делать движения по регистру ОстаткиТМЦ

Ну, знаешь, бывает :) Документ "ПриходРасход" :) почему бы и нет :) смотря кто конфу писал :) ёмоё. уж все сказали, грхни индексы. вдруг поможет. а вообще, не в докуметах дело. у тебя сумма 4+2 = 10 получается не потому, что какой то из документов криво записал движения, а потому, что в файле движений лежат движения, неадеквантые остаткам в файле остатков. так бывает, но редко :) на регистрах. на бухии, имхо, вполне нормальное явление, когда задним числом ковырнули, тут же появляются СК(май)<>СН(июнь).//// сколько у тебя будут пересчитываться оперитоги - известно илшь высшему разуму. это же ТВОЯ БАЗА.....реиндексация скорее всего не поможет. поможет именно пересчёт итогов. структура 1С регистров именно такова, что остатки сохраняются ИНОГДА, т.е. раз в месяц, раз в год раз в день - в ренгистрах. и подсчёт итогов ведётся от остатка на границе периода +- движения. иногда при каких-то обстоятельствах выходит, что движения есть, а итоги не изменены.надо пересчитывать.

"Документ "ПриходРасход" ... может-может, не спорю. Можно вообще делать все движения одним документом ;-)* * *А если вспомнить идеологию программирования в опер учете - то ведь ясно оговорено, что движения прихода расхода делаются разными документами.

Вообще-то я в подобных ситуациях делаю тестирование и исправление. До сих пор помогало всегда.

Учитывая что при тестировании и исправлении проводится пересчет итогов - неудивительно что помогало ;-)))

я к тому, что, как мне кажется, там этот пересчет быстрее проходит.

Рамиль: кажется. механизм один и тот же

если создатели движка 7.7 читают этот форум, они вертятся на табуретках от смеха. мы, блин, азов не знаем того на чём работаем.

а где эти самые "азы" изложены? всяко не в ЖКК, да и на ИТСах, насколько помню, тоже только обрывочные сведения

Кстати, номер релиза? Не 18 ли?

Нет релиз 21. На ночь оставил на своем серваке, так до утра и не усепл