Как одолеть ограничение в 2ГБ?
Kernel3x не дает результата

Для начала, нужно выяснить, почему регистр не закрывается. Потом ужо..удалить лишнюю аналитику и пересчитать итоги, и размер rg будет пара десятка метров, а не 2 гига

(81) не закрывается, потому что задним числом производят изменения в документе поступления. Убедить в том, что это не правильно, бесполезно. Базе уже примерно 7 лет. Нужно каким то образом избавиться от нулевых итогов...

(82) Это вообще ни на что не влияет

Оценить количество записей с нулевыми итогами можно простым селектом. Их там будет..мало.

очень мало.

ra этого регистра, какой размер имеет ?

(86) RA328.DBF - 41 МБ

(86) RG328.DBF - 2,1 ГБ
Период сохранения остатков: 5 дней

(87) да уж..феерический пиз..ц

RG этого регистра должен быть пару килобайт в таком случае, ну может, 2-3 мегабайта.

(87) при таком размере RA размер RG мегабайт 4-8 д.б.

(88) и че ? У нас всегда был период хранения 5 дней.
Итоги пересчитывались влёт все, за любой период, штатно.

возможно несолько фирм с отключенным контролем остатков или контроль в целом по компании. Интерккампани не делалось никогда.

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

(92) или какой-то умник добавил новое измерение, которое только в расходе заполняет

Хотя с такими измерениями
Фирма, Номенклатура, Склад, ЦенаПрод...
ЦенаПрод - вот тут, 99.9% ошибка

иначе, разве что приход с одной фирмой, расход с пустой или с другой.

Посмотреть 2 секунды, открыв движения регистра у прихода и расхода.

(92) фирма одна, а вот по партиям списываться может правильно, а если потом эту партию (поступление) удалить или изменить без проведения последующих зависящих документов?

(95) штатно все норм делается. для оптового склада ЦенаПрод везде = 0. для розницы - установлена строго. Но засада может быт здесь - олухи царя небесного при вкручивании в розницу скидок и прочего делают неправильно и тянут хвостами незакрытые партии по ценапрод.

(98) в (32) нет партий.
Или ты огласил не все измерения ? :))

(98) ну сделай блин ТИПОВОЙ отчет с максимально возможным количеством группировок без фильтров Меню-Отчеты-Ведомость по партиям и смотри что незакрыто, будет видно сразу.

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

(100) еще есть Реквизиты: Внутреннее (число)

для полного отчета по всем измерениям (такового может и не оказаться если вдруг) - заюзать или штатный "универсальный отчет по регистру" или https://infostart.ru/public/14794/

(103) вообще-то это ты приводишь скорее всего для регистра ОСТАТКИТМЦ. а номер 328 - это регистр "ПартииНаличие"

в (32)+(1-03) приведена структура типового Регистр.ОстаткиТМЦ, а речь идет о "328" - это другой регистр (Партии) с другим набором измерений

(106) Регистр: ПартииНаличие

Измерения:
Фирма
МОЛ
Номенклатура
СтатусПартии
Партия
ДатаПартии
ЦенаПрод

Ресурсы:
Количество
СуммаУпр
СуммаРуб
СуммаБезНДС
СуммаПлат

(107) я знаю.

выкладывай уже свою базу на файлопомойку целиком, нужны *.dbf и *.md, всё

(109) что, на снеговике - скучно? ;-)

(107) :)
Реквизиты
КодОперации
ПродСтоимость
Выручка

(111) да, как его теперь закрывать?

(112) :) епрст прав - выложи базу, посмотрим что можно почикать

(113) хватит и RG328

(114) https://drive.google.com/file/d/12Ap45kafKFhGpsUupuXO6OVzWKVYYAC-/view?usp=sharing

Так может по движениям восстановить RG328  и он наверняка будет меньше и создастся. Недавно так делал.
Правда файл был чуть меньше 2 ГБ но все равно индексироваться не хотел.
Перезаполнил его по RA328 и вроде все норм стало - файл RG328 стал 1.3 ГБ

(116) удалить его и перепровести документы? по времени сколько выйдет?

(117) с учетом, что периодичность сохранения остатков установлена 5 дней

(117) Документы перепроводить не надо никакие. Но если 5 дней то возможно будет долго пересчитывать

(119) пересчитать на копии, подменить, пересчитать последние 5 дней дерганьем ТА

(120) с регистром в 2 ГБ? Запускал когда то, с ошибкой вылетало

(121) Размер РА какой?

(122) 41 МБ сейчас

(122) выше писал, 47 Мб

(121) файл итогов убить нахрен. далее - как написано. посмотреть что получится.

сделать копию базы.
сдвинуть ТА на самый первый документ.
удалить RG328.*
на псоледнем документе текущем в сейчас - правой мышью - установить ТА на документ - в появившемяс окошке НИЧЕГО ГАЛКАМИ НЕ ОТМЕЧАТЬ, все выключить (то есть без перепроведения документов).
прога начнет сдвигать ТА от первого дока на сейчас, ПЕРЕСЧИТЫВАЯ ИТОГИ и более ничего не делая (документы не перепроводятся!).
.
ждать.
.
когда закончится (если закончится) - смотреть что получилось.
скорее всего получилось примерно как было и раньше.
плюс есть возможность не дождаться можжет молотить и сутик и двое и больше в самом худшем случае.
.
индикатором является продолжительность открытия нового периода.

(125) Ну не знаю как можно получить из Ра в 47 МБ РГ в 2 ГБ

(127) наверное ТС очень старался.

(128) Да все бывает - плюс на минус вот и итог появился

(129) могло еще так быть, например, поработали чуток, потом поняли что партионка нахрен не нужна, отключили ее в коде. а ранее наработаннное осталось незакрытым и начало тянуться . все 10 лет что работает база. вот и дотянулось.

автор смотри чего я тебе нашел - https://ru.wikipedia.org/wiki/Виргинский_опоссум
"При серьёзной опасности опоссумы «притворяются» мёртвыми. Сильно напуганный опоссум входит в каталептическое состояние, падает на землю, сворачиваясь клубком и поджимая конечности; на прикосновения он не реагирует, а лежит на боку с приоткрытой пастью и вывалившимся языком. При этом мышцы его расслабляются, а анальные железы выделяют зловонный зеленоватый секрет." (с)
https://scontent.fiev21-1.fna.fbcdn.net/v/t1.6435-9/166012492_1903418776477108_4023971221029157740_n.jpg?_nc_cat=103&ccb=1-3&_nc_sid=825194&_nc_ohc=RvA1JPzv71QAX_3Con5&_nc_ht=scontent.fiev21-1.fna&oh=42292f0b65277301338f1d96ea607c6e&oe=60CF2645

(131) спасибо, поржал! ;-)

Короче, скучно тут с вами, пойду на выставку смотаюсь RosUpak

(127) Был у меня такой клиент. Выгрузка базы - 50 мегабайт, MDF - 10 Гигабайт. Пересчет итогов за 6 лет, запущенный из спортивного интереса на мощном компе, - я сбросил на второй неделе.
А всего-то один регистр на 7 измерений, в которых последние 2 - должны были быть реквизитами, но кривые руки сына маминой подруги, на коленке подрихтовавшего чужую нетленку, сделали из регистра остатков огромную кучу мусора. Ведь разница между "Измерением" и "Реквизитом" несущественная). Номенклатура тогда была под 150 тысяч.
НА каждом (!) реквизите при этом стояли галки "Отбор движений" и "Отбор итогов". А на регистре - "Быстрая обработка движений".
Ну и чтобы это всё быстрее работало - периодичность сохранения остатков была установлена в "Пять дней".
Оптимизаторы, блин...
Берёг я потом эту базу как экспонат для Кунсткамеры.

Я это всё к чему - может у ТС там не только регистр не закрывается (хотя это и наиболее вероятно), но и периодичность сохранения остатков прооптимизирована.

Ну посмотрел dbf из (115) - куча пустых партий с минусовым остатком по количеству и нулями по суммам.
И с чего такой регистр должен свертываться?
Возможно из старой и кривой свертки они ползут...
Много зависших партий от 2015 года, видимо по той же причине.
Ну а так СуммаУпр всегда равна СуммаРуб, можно ее удалить.
ДатаПартии в этом регистре вообще не нужна, ее можно из самой партии вытянуть.

(135) Короче,.. Овчинка выделки не стоит? или как то можно позакрывать?

(136) двигателем регистров закрой старые партии

(137) на начало каждого периода или последнего?

(135) ДатаПартии в типовой ТиС не эквивалентна дате документа партии. В некоторых местах чуть по другому делается если посмотреть. Но не думаю что это принципиально. если надо будут более развернуто пояснения - это отдельно...

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

(115) кинь ra этого регистра

(141) https://drive.google.com/file/d/1_hKUUppAbardCDkyr8eOlhFN0k0k6uAg/view?usp=sharing

галактика замерла в ожиданиии...

(143) )))

(142) У тебя
1.мол и цена прод можно выкинуть, как и цена упр (в плане производительности)

2. есть 2 возврата от покупателя с партиями от  28.06.2019 и 02.06.2020 по другой фирме, по которой не было расхода

но, там записей в rg не так и много, ибо провели их мае этого года.

3.ща.. занят пока.
Основной затык будет в партиях/датепартии/статусе партии. ща скажу, где

(142) читаем (145) и отвечаем на вопрос: а зачем ты соврамши что учет ведется по одной фирме?

При таком колве движений по партиям - периодичность в 5 дней - нафиг не нужна. выставить периодичность итого = 1 месяц, размер КП после пересчета итогов упадет раза в 4-6.

Есть приход 07.09.2017 который сделал 12 записей (12 товаров в нём) с отличным статусом партии, и который породил 3264 записей в итогах (ибо списания с таким статусом партии нема).

но это пока не всё.

При таком РА и таком РГ и даже при периодичности в 5 дней = все равно очень все несбалансировано.
Скорее всего проводили сделки, а потому удаляли приходы и/или работали исключительно как печмаш без контроля остатков. Поэтому в коде отрубить нафиг формирование движений по партиям (там немного мест, забыть про партии совсем и работать дальше как работали.

(146) Добавлено фирм несколько, но фактически используется только одна

(149) Так и есть! Пользователям делают правки в документах задним число, с изменением цен, количества и др.

Короче, основной трабл, в валюте.
У вас не верный пересчет, либо балуетесь курсами и куева туча записей оставляет куеву тучу останков, ибо суммаУпр<> СуммаРуб.

Валюта упр и бух учета какая ?

(153) UAH изначально было установлено(

(150) фактически - несколько. Епрст показал.

(154) поэтому, при скачке курса массово меняем цены согласно нового курса

(156) это никак не относится к кривости партий

(155) в справочнике несколько, а в документах одна фирма... Возможно проскользнула в проведении другая фирма, но не массово

нужен ли валютный учет? то есть себестоимость и финрезультат в разрезе двух валют? если нет - то валюту учета установить такую же как нацвалюту. прибить все РГ. отключить контроль остатков (перевсти периодичность итогов на месяц) и полностью перепровести базу. вернуть контроль остатков как было (периодичность оставить месяц)

насколько мне помнится при двухвалютном учете в партионке все там нормально по СуммаУпр и СуммаРуб. если играются задним числом ценами, количествами и прочим, то регулярно восстанавливать ГП., а лучше привести процессы к нормальному варианту учета без массовых правок жопой.

(158) похрен. либо да либо нет. "не массово" - это самоуспокоение, ведет к тому что на это забивают и имеем то что имеем.

(158) в справочнике фирм пометить на удаление ВСЕ ФИРМЫ кроме ОДНОЙ ИСПОЛЬЗУЕМОЙ.
Удалить шттано. Апосмотреть что из фирм осталось неудаленным. курить бамбук и много думать.

На вот, наглядненько:

http://pics.rsh.ru/img/_7edz6jfw.png

Вы покупаете с одной суммой, списываете с другой в СуммаРуб у вас осталось 5 копеек.
Эти пять копеек на остатке, теперь с 16 года в каждом периоде.
Таких записей в ra 17 тыр с копейками. Делайте выводов, сколько записей будет в rg, не удивительно, что он распух с геометрической прогрессией.

(156)
Короче, установить валюту упр и бух учета одинаковой.
Сделать тупо
update ra328
set sp343 = sp421

Прибить rg328.dbf, rg328.cdx,ra328.cdx

Зайти монопольно, сделать пересчет итогов, сдвинув ТА на первый документ и обратно, на последний.
Усё.

Наслаждяться, кушать печенки.

Я понял, спасибо, сейчас буду делать)

(166) это все можно было увидеть типовым отчетом "Ведомость по партиям", но вы забили болт на мои рекомендации и отвлекли такого уважаемого спеца как Епрст на полную хрень.
.
Ёпрст не признается, но ночами он тихо плачет в подушку и тоскует по клюшкам.
Поэтом для ТС расстрел отменяется...

ну и исправить (148)

(166) я бы всетаки сдвинул периодичность итогов на "месяц"...

(167) не, я не такой..

(169) не надо. 5 дней - идеально

(170) такой, такой... иначе че ты оправдываешься ;-)

(171) ну, м.б....
5 дней когда инфы по движениям настолько много, что это имело бы смысл. При таком объеме движений (40Мб) за НЕСКОЛЬКО ЛЕТ, как минимум 5 (с 2016) - 5 дней имхо ну совсем лишнее.

Нет. При 5 дней - самый быстрый режим работы.
Мгновенная запись движений, мгновенный расчет остатков (в том числе. сводных). Мгновенные штатные отчеты с коност

Автору, при желании, можно выкинуть измерения
фирма/мол/ценаПрод/датапартии/статуспартии
ресурсы валютаупр/суммаплат

и.. размер ra (он и так смешной) будет еще меньше
+порезать числовые реквизиты (16.2 сделать, 8.2, напрмер)

Короче, можно соптимизировать и так детскую базу.

(174) это понятно. я как раз говорю, что это м.б. при том объеме движений как у ТС совершенно некритично (хоть и быстро).

ДатаПартии используется при расчете ФИФО. И отличается от даты документа при регистрации возвратов.

(175) нафига ему это делать, поправит сейчас как ты сказал и уписаются от счастия и без этого всего.

ТС напиши потом что в итоге получилось-то... по размерам...