Нужно свернуть УПП 1.3 за 7 лет . База примерно 70 Гб , серверная ОС 64-бит , 1с сервер 32 бит. Использовал типовую обработку с сайта 1с ИТС СверткаБазы.epf . Сначала за все семь лет поставил - через сутки вывалилась ошибка "Недостаточно памяти" . То же самое - когда попробовал за 2 года и за 1 год. Сейчас пробую за пол-года свернуть. Пока жду.
Много чего прочитал уже в Интернете про эту проблему. Насколько понял , команда bcdedit /set increaseuserva NNNN мне не поможет (хотя написано как-то по разному везде)  , т.к. это для 32-битн ОС , а в 64-битн. ОС 32-битн. приложению , скомпилированному с флагом IMAGE_FILE_LARGE_ADDRESS_AWARE , уже будет доступно 4 ГБ для работы - а больше для 32-битн. выделить нельзя.
Кто как решает данную проблему ? (свернуть нужно для проверяющих , чтобы за 7 лет большинства документов не было)
Спасибо

За пол-года то же самое - "Недостаочно памяти"...

(0)[Кто как решает данную проблему ?]
проблемы нет
свертка не нужна
нужен ввод начальных остатков

кроме того, УПП после свёртки лишиться ОС, НДС и авансов

(0) // Кто как решает данную проблему ? (свернуть нужно для проверяющих , чтобы за 7 лет большинства документов не было)

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

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

(2) По ОС , НДС и авансам не сворачиваю (рекомендации в обработке). Мне нужно за 7 лет свернуть , а два года оставить.
Если не использовать типовую с ИТС СверткаБазы.epf - то надо значит обработку какую-то делать по переносу остатков в другую базу и через КД ( или обработка по переносу данных между одинаковыми конф.) переносить все остальное.
Может есть что готовое для этого ?

(4) Свертка и что-то готовое для УПП ?! - Это фантастика.

(4) ни о чем

(4)
Но если планы обмена РИБ в УПП 1.3 в вашей версии есть, то вот считай это заготовками на перенос данных, без необходимости разработки правил и т.п. Но чтоб сформировать остатки - это надо по каждому конкретному участку разработать или хотя бы протестить свои процедуры.

(1) Ради проверяющих можно и памяти добить на время, нет?

(8) не. у него 32 бита клиентское и серверное приложение.

(8) Памяти 64 ГБ на сервере, дело не в этом

>то надо значит обработку какую-то делать по переносу остатков в другую базу

не надо ничего никуда носить...

это копия базы под аудит.

срезать остатки по всем регистрам на "дату начала проверки", налупить по ним корректировок, документы "до" удалить

можно попробовать свертку на 8.3.9 с 64 бит. клиентом

>уже будет доступно 4 ГБ для работы

будет не 4, а 3.5

Цель свертки?

(12) тогда ему нужен еще один сервак, чтоб независимо от рабочей на 8.3.9 перейти

(13) написано же - не пущать аудиторов в старые периоды

(14) захочет - найдет

(10) Вот, оказывается, за что дерут такие деньги за 64-битный сервер.

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

>Вот, оказывается, за что дерут такие деньги за 64-битный сервер.

самое смешное когда "купить сервер" пишут как "лекарство". хотя падает клиент

(19) По методике, идущей в комплекте с типовой обработкой свертки, предусмотрен перенос ф-ций в общий серверный модуль.

(15) "чтобы за 7 лет большинства документов не было" // Вижу в (0) "чтобы за 7 лет большинства документов не было". Такое только сверткой (гарантированно) не решается - документы останутся сидеть в туевой хуче несвернутых субконт и других несвернутых комбинаций в движениях, поэтому вдобавок придется перекидывать такие движения на какие-нибудь документы-агрегаторы наподобие "Ручной учет"

(11) Да , спасибо , вот это наверное самый оптимальный путь .
1) Стандартной сверткой делаю документы остатков
2) Потом уже другими средствами удаляю все документы (которые удалятся) до даты ввода остатков (на этом шаге как раз стандартная СверткаБазы.epf падает с "Недостаточно памяти")
3) той же стандартной СверткаБазы.epf переношу документы по вводу остатков (корректировки регистров) на секунду назад
Проверяю.

>документы останутся сидеть в туевой хуче несвернутых субконт и других несвернутых комбинаций в движениях

от этих документов можно оставить только "оболочки" движения которые они порождали есть в корректировках в агригированном виде

(20) Кажется, как раз тот случай.

может и тот.

мы сталкивались с такой же конфигурацией ОС и сервера 1С (64 и 32). где падал именно клиент - так был устроен документ в отраслевом решении

(0) типовая свертка не вариант, можно даже не рассматривать.

(20,24,25) Предвидел , что это не поможет , т.к. сервер 32 бит - но на всякий случай для интереса попробовал перенести указанные процедуры в общий модуль для выполнения на сервере - результат в данном случае ожидаемый "Недостаточно места на сервере 1с Предприятие"

(+27) Делал за пол-года

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

(29) Ерунда это все. Надо осознать (2).

(27) эмуль для свёртки поставить не позволяет начальство ?

если штатная обработка для свертки не вариант , тогда что можно рекомендовать вместо нее.
На  копии базы (файловой) пытался сделать свертку, после 2 дней работы вылетела с ошибкой, и особых путей чтобы ее делать поэтапно я не нашел.
Так как делают свертку УПП, если кто делал?
Перенос остатков как я понял это не вариант!

(32) Откуда понял, что перенос остатков в новую базу не вариант?

Ну лично я на примере УПП наблюдал такое поведение:
1) Выбрали, Пытаемся запустить, начинаем допиливать и в итоге база постепенно перестает адекватно воспринимать обновки...
2) Обновки какое-то время накатываются сбоку, затем накатывается получившийся файл на рабочую. Если пилить конфу продолжают, то этот вариант тоже начинает загибаться.
3) прошло уже от 5 до 7 лет и с криками, матами, перематами возникают обстоятельства непреодолимой силы и принимается решения поставить новую версию УПП. Балго, что этому моменту или 1.1 заменяется на 1.2 или 1.1 на 1.3 или 1.2 на 1.3 или любая УПП на ERP.

Итог. Все остатки выгружаются и пересаживаются в новую базу. А старая лежит в архиве на "посмотреть еси че"

Ну а мы работы не боимся - было бы чего работать.
Легких путей тоже не ищем.
Поэтому создание обменов и перенос/конвертация данных между старыми-новыми - это наш метод.

>и в итоге база постепенно перестает адекватно воспринимать обновки...

с упп сейчас проще... ну и зависит от того чего допилено

>Обновки какое-то время накатываются сбоку, затем накатывается получившийся файл на рабочую. Если пилить конфу продолжают, то этот вариант тоже начинает загибаться.

зависит от допильщиков

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


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

(32) я пробовал делать. Ждал несколько дней, закончиться закончилась, но сразу обнаружились ошибки в учете (т.е. свертка некорректно отработала), размер все равно после сжатия большой... практического смысла нет. Если для "чистого листа", то похоже, только новую вводом остатков делать. Какашка все эти ваши свертки.

А есть ли стандартные обработки для переноса остатков из одной базы в другую?

были для зупа например... из зика

но она мудреная... сначала конвертация зика в 8-ку, потом выгрузка/загрузка...

в итоге новая база полна мусора. с одной стороны уволенные давно (накой хрен они нужны) с другой чего-то не хватает (средний заработок за 2 года вроде не переносился)

на инфостарте кто-то фарцует правилами из УПП в БП 3.0

(0) http://catalog.mista.ru/public/190956/
http://catalog.mista.ru/public/139651/

Платформа-то на каком моменте хотя бы падает? Получение остатков в разрезе всех субконто?

(40) -> хотя увидел ответ в (27), но статья выше все-равно будет полезна для понимания.

(37) остатки из одной базы в другую переносят конвертацией данных. Кто чем умеет.

Кто-то КД2 использует, кто-то КД3 - на текущих версиях из одной восьмерки в другую восьмерку, да на одной и той же платформе проблем в конвертации/переносах не возникает.

Там проблема с остатками возникает, когда Клиент и Специалист не могут сходу выбрать весь перечень регистров и измерений на которых что-то нужно, а на которых нужно похерить. Когда в источнике измерения и регистры не совпадают с приемником по составу, по количеству самих типов и т.д. Естественно, что для таких случаев и готовых процедур быть не может, а их и нету по факту готовых