Здраствуйте. подскажите пожалуйста по такому вопросу. имею в обслуживании сеть аптек, периодически при выключении света или "техничка", вообщем при непридвиденном выключении компа во время проведения операции продажи летит регистр остатков(именно таблица с итогами). по некоторым товарам начинает показывать неправильные остатки. Причем если делаешь отчет за большой промежуток времени то всё ОК, если на текущую дату то начинают вылазить левые количества, левые партии с количеством(партионный учёт). Лечится только последовательным откатом итогов по этому регистру до 2000 года и новым расчетом итогов на текущую дату. Простым пересчётом итогов не получается так как выкидывает с ошибкой недостаточно памяти(довольно большая таблица), командой  регистрыНакопления.КонтрольОстатков.ПересчитатьТекущиеИтоги() тоже вылетает с ошибкой. В инете почему то очень мало инфы по этой теме, вот я и думаю или это очень редка ситуация(хотя я с ней сталкиваюсь регулярно) или есть какой то метод(возможность) её избежать и я про него не знаю. Извините за много буков.....

забыл добавить. конфа полностью самописная

(1)ты забыл вопрос добавить

(0) Подсказываю - источник бесперебойного питания.

Каждый раз, как что-то происходит с базой, нужно делать ей ТИИ. И всё будет гуд.

(0) Может свернуть регистр? Аптекам нужны движения которым уже 16 лет?

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

бесперебойники стоят, но невсегда помогают. они не спасают от шаловливых рук фармацевтов, ТИИ не поможет. при пересчете итогов выкидывает с ошибкой "нехватка памяти". итоги обрезаны. движения только за пол года. по ошибке с памятью тоже всё способы решения найденные в инете перепробовал. непомогает. скуль не могу. вопрос в том почему если у меня эта ситуация вылазииит регулярно в инете по ней очень мало инфы. может я чего то не знаю и недопонимаю?

(7) ну самописная база ведь, значит там нереально криво всё спроектировано. Удивительно, что вообще пока работает. Радуйтесь.

ой вот не надо голословных обвинений. всё нормально написано. дело не конфигурации, а в самой структуре БД и том как с ней работает 1с

(9) Склонен согласиться с оратором в (8).
Ты же сам задаешься вопросом о том "почему если у меня эта ситуация вылазит регулярно в инете по ней очень мало инфы"

Тебя это не на какие мысли не наталкивает?

А почему, если регистр обрезан и движения только за полгода, приходится пересчитывать с 2000-го года?
И что это за регистр такой, что вылетает по нехватке памяти? У меня в бухне размер регистра ~18ГБ, из которых ~6Гб - таблицы движений + ~7Гб - индексы к ним, ~4Гб - таблицы итогов + ~0,1 индексы к ним. Пересчитывает не быстро, но ни разу не вылетало по нехватке памяти.

Что такого в твоём регистре, что 1С-ке памяти не хватает?...

(10) видимо, не закрывается в 0

да, многие позиции не закрываются. движения по товару, у меня в офисе до недавнего времени ФАЙЛОВАЯ работала при таких размерах 32 гиг, общий размер, таблицы итогов по 4-е гига, индексы к ним под 10 гигов, только из-за ограничения на максимальный размер таблицы перешел в офисе на постгри. в аптеках размеры таблиц конечно меньше но не на порядок. я думаю вылетает из за слишком большого ассортимента и различных аналитик по нему. конечно я не отметаю вариант кривизны конфы, но всё таки сразу указывать на это я думаю неправильно. при том что там собственно накосячить то очень тяжело. простой регистр с измерениями: товар, партия, склад, фирма, разделите учёта и ресурсами количество и резерв. всё. запись движений вообще без извращений и наворотов.

Dmitrii а вы каким релизом пользуетесь?

про откат до 2000го я образно написал

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

(15) Транзакция - это или всё, или ничего.
Правда, про демо (ака файловая) не скажу, там может быть всё, что угодно.

(9) Вы требуете, чтобы 1с на файловом движке обеспечила полный механизм транзакций с их фиксацией и откатом? Т.е. написала свой локальный SQL-сервер, устойчивый к действиям криворуких пользователей? Не слишком ли велики Ваши запросы?

(15) А вам, собственно, не по-барабану это? Вы все равно управлять этим не сможете и базы все также будут валиться. И какие в жпо транзакции на файловом движке могут быть? К данным еще и журнал транзакций хранить? Или Вам версионники больше по душе?

И кому одноэсовцы стали вдруг должны?

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

(18) Не было там никакого механизма транзакций. Данные писались сразу в файлы. И если в середине записи обламывался комп, но получались все те же битые записи.

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

Отключают электроэнергию - ставьте ИБП. Этот совет был в самом начале. Но Вы решили найти некую волшебную пилюлю, при которой проблема сама рассосется.

вашу позицию я понял. не имею привычки спорить в форумах. про иБП я ответил сразу что он стоит. не ну все же надеются на волшебную пилюлю ))))...авось она есть ...

(20) Дык и это предложили выше - SQL :) Увы, бесплатный сыр только в мышеловке.

жалко конечно )))). ну пусть тема повисит. может кто нибудь всё таки напишет про волшебную галочку(флажок) где нибудь в глубине настроек документа, программы, регистра ) :-))))

(1) примите мои соболезнования

(22)Хватит читать книжки про Гарри Потера, возьмись за ЖКК.

(13) >> каким релизом пользуетесь?

Релизом чего?...
Платформа - сейчас 8.3.7.2027. Но мы стабильно обновляем платформу согласно требованиям, указанным к конфигурации 1С Бухгалтерия 3.0, или чуть выше.
Конфа - 1С БП 3.0.43.247 довольно сильно переписанная.
MSSQL - 2014
Сервер 1С - x64.
Клиент 1С (естественно) x32, но работает на ОС x64, т.к. раньше часто возникали проблемы при подключении конфигураций к хранилищу.

Причин проблемы нехватки памяти может быть много. Не совсем понятно даже кому именно не хватает памяти. Что бы сделал я (в порядке приоритетности):
1. ОС на сервере СУБД и 1С - x64
2. ОС на клиенте, где запускается ТИИ (если это делается не на сервере 1С) - x64
3. Версия сервера 1С - x64
4. Версия СУБД - x64
5. Для PostgreSQL - поставить самый последний релиз для 1С с сайта https://postgrespro.ru/products/1c_build . При этом по большинству отзывов PostgreSQL гораздо веселее и стабильнее живет под Linux'ом, чем под Windows.

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