Изначально dbf подобрались к двум GB. Удалось ужать самый большой файл до 1300Мб. Но иногда проблемы вылазят, поэтому всё-таки нужно резать базу.
Подрезку написал, остатки по регистрам и счетам формирую, документы до этой даты удаляются. Вроде всё ок.

Но к сожалению гладко только в теории. Уже неделю пытаюсь пройти последние 20% пути и ни как:

1) Если пытаюсь штатно удалять документы например за 15лет (с 2003 года база, удаление и за двое суток не происходит, а больше по времени ждать нет возможности).
2) Если удалять например по 2010й год штатными средствами 1с, то процесс завершается /12 часов на это нужно примерно/, но после этого ломаются промежуточные итоги.
После одной попытки подрезки они могут быть пустыми на любую дату, либо могут быть увеличенными на 2. Т.е. почемуто ломаются итоги.
3) Если удаляю документы через :
Соединение = "Provider=VFPOLEDB.1;Data Source=" + КаталогИБ() + ";Exclusive=Yes;Mode=ReadWrite;Collating Sequence=MACHINE";
метод конечно очень быстрый, но насколько я понимаю, после этого способа по определению промежуточные итоги будут содержать не верные данные?

Удаляю CDX и запускаю ТиС - над одной копией 4ро суток ждал завершения и не дождался. Над другой копией могу дождаться, но итоги не исправляются.

Уже устал бороться /учитывая, что кучу времени каждая операция занимает/ - отсюда этот пост )
http://prntscr.com/sla2bh

Неужели единственный выход - распроводить все документы после даты подрезки и затем заново их проводить?

(0) простые и баянистые советы:

1. Если данных слишком много - режь мелкими периодами, 3-5 лет

2. Почему у тебя на скриншоте документы остатков датированы 1.01.17? Чтобы остатки были на начало 01.01.17 - документы ввода должны быть 31.12.16.

3. Заметно удалить быстрее получается, если
- если период удаления небольшой - то удалять "в обратном порядке", с последнего к первому документу
- если период удаления большой, то перед удалением откатить ТА (и рассчитанные БИ) до первого документа, а потом пересчитать итоги.

(9+) "а потом пересчитать итоги." = "вернуть ТА и БИ без перепроведения, только пересчет итогов"

сформировать доки остатков. заполненые, но непроведенные
откатить ТА и БИ на перед первым обрезаемым доком.
распровести. удалить в доках ТЧ.
потом пометить на удаление (возможно придется помечать и удалять порциями)
докатить ТА и БИ до первого документа остатков.
провести доки ввода остатков.
докатить ТА и БИ без перепроведения до сейчас.
удалить штатно.
.
я совсем недавно резал базу с 2007г. по 2018. обрезал достаточно быстро.
зависит и от обьемов базы конечно. может у тебя там в каждой секунде по 10 доков впихнуто.
.
сколько документо всего до обрезки?

http://catalog.mista.ru/public/15192/

(11) У, как всё сложно, проще надо. Берешь базу, делаешь новую, переносишь в неё "правильные остатки" и справочные данные, а потом переносишь текущие документы. Делал так много раз, и с типовыми, и даже с очень не типовыми.

+(13) Единственное условие - это ставишь запрет на изменение данных до даты свертки.

(13) Вот я пару лет назад попробовал обрезать БП 3 и пришлось вернуть все взад, т.к. свертка прошла некорректно.
Посоветуешь сделать новую базу и перенести "правильные остатки"? Если это делать, то какой процедурой? Или все-таки свертка?

(15) сравнил 7ку с 8кой. Бп 3.0 это такая хрень что нормально порезать её целое искусство. Тут надо знать связи и внутреннюю структуру. Тут не получиться херак херак и в продакшен

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

(16) Спасибо за информацию. Будем эксплуатировать долго и упорно тот вариант, который есть. Проблема вполне может разрешиться сама собой. Например, переход ЗУП 2.5 -> ЗУП 3.1 попутно решил проблему обрезки базы. Учет в ЗУП 3.1 начинается с чистого листа. Процедуру переноса предоставила фирма 1С уже готовую. Правда, после этой процедуры пришлось еще обработками кое-что поправлять. Но это немного.

Если эта база на оперативном учете, например ТиС, без бухгалтерских счетов и журнала расчетов, то на ИС была очень неплохая методика "обрезки" базы. Отдельная маленькая конфигурация, которая "режет" регистры на документ свертки(добавляется предварительно в рабочую базу) прямыми запросами. Все это происходит очень быстро, значительно быстрее, чем всеми другими методами. Результат - пользователи обычно даже не замечают, что с базой что-то делали, все остатки и обороты за "оставленный" период - на месте. Единственный недостаток - это то, что обрезку можно выполнить только на ПЕРВОЕ число периода, а не на последнее, как было-бы правильнее. Но, это обходится так - если хотим свернуть(обрезать) базу на начало года - режем на 01.12.предыдущего года. Тогда остатки на 01.01.текущего года будут правильные.
Можно отрезать базу этим методом, "с запасом", оставив несколько месяцев до желаемой даты свертки, регистры "похудеют" до вменяемых размеров, а потом, уже сворачивайте своими методами, как хотите, если вместе со сверткой вы планировали еще чего-то сделать.

+(19) Вот ссылка: http://catalog.mista.ru/public/63400/

(11) Примерно так и делал кроме
"откатить ТА и БИ на перед первым обрезаемым доком."
Сейчас буду пробовать

(13) Каким образом переносить?
Ведь в таком случае всё-равно придётся перепроводить оставшиеся нужные документы в новой базе. А их перепроведение очень не желательно, т.к. скорее всего гдето по какимто документам проводки станут другими. и потом кучу времени придётся тратить на их поиск

Как увидеть что 1с чтото делаем в момент ТиС а не подвисла? /кроме диспетчера есть способ? например какойто файл растёт?/
http://prntscr.com/sliig5
вот уже помоему вторые сутки. До этого все птчики ставил - 4го суток и не было результата

(23) http://catalog.mista.ru/public/14645/

Не понимаю.Провёл эксперемент на дату 01.12.2003 /удаляю всего несколько первых месяцев/.
Делаю как здесь (13)

"сформировать доки остатков. заполненые, но непроведенные
откатить ТА и БИ на перед первым обрезаемым доком.
распровести. удалить в доках ТЧ.
потом пометить на удаление (возможно придется помечать и удалять порциями)
докатить ТА и БИ до первого документа остатков.
провести доки ввода остатков."

всё делается штатно, но при этом отчётность за 01.12.2003 в бухгалтерских отчётах пропадает:
http://prntscr.com/sliz1a

И в строке состояния показывает не верный период БИ:
http://prntscr.com/slj2fd
както связано?

(0) Помнится был один вредный способ.
1. Формируешь документ ввода остатков.
2. Удаляешь файлы регистров и проводок.
3. В файле 1SJOURN.DBF ставишь удаляемым документам пометку на удаление.
4. Перепроводишь документы после даты свёртки.
5. Делаешь ТИИ.

(25) "этом отчётность за 01.12.2003 в бухгалтерских отчётах пропадает:"
с этим разобрался.
Отчёт "Оборотно сальдовая ведомость" в основной базе полетела почемуто не показывает итоги.
Остальные отчёты /тотже анализ счёта/ показывают обороты.

п.с. тестирую дальше

(27) Основная проблема в пункте 4.

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

(29)Можно попробовать пропустить пункт 2 и 4. Если ТИИ удалит у помеченных движения, то всё хорошо. Но по времени неизвестно что получится.

(0) Я когда-то давно делал так
http://catalog.mista.ru/public/15114/

К сожалению, подробностей уже и не помню )

Обработкой из (12) тоже пользовался

И перед сверткой еще подготовка простейшая нужна
http://catalog.mista.ru/public/15111/

(31) Так более изящно, если точно знать структуру регистров.

1csql.ru 1c.proclub.ru dev.citykirov.ru уже не открываются. Ушли в лету

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

(35) Проблема не в пользователях, а в том, что гдето когдато мог поменять алгоритм проведения какихто документов. И перепроведение документов может пойти по новому алгоритму. И данные в оборотке станут отличными от текущих.
Скорее всего потом это будет сложно выровнять

(0) бухня ?

Если че, ТиИ запускать не надо.. никогда (особенно, если не знаешь, что оно делает)

И.. твоя база сворачивается минут за 5-10

На вот, занимайся
https://cloud.mail.ru/public/3pdW/4QnZKFKqQ

ЗЫ: нужен только vfpoledb
https://www.microsoft.com/en-us/download/details.aspx?id=14839
и 1cpp.dll
http://www.1cpp.ru/forum/YaBB.pl?action=downloadfile;file=icpp-3-2-4-0-rc1%2Erar

Надеюсь создать доки /операции ввода останков сам смогёшь

(40) Уже есть эта обработка )
Я писал в (0), что ей тоже пробую резать.
Вопрос в том, что и после этой обработки итоги падают

(38) а что оно делает? )
Запускал, т.к. был шанс что исправит ситуацию.
ТиИ промежуточные итоги на конец каждого месяца не пересчитывает?

(42) :)))))))))))
Что значит падают ?

Тиии запускать не надо, от слова совсем

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

(37) не совсем понимаю, что это значит?

И если есть ОС, то в запросах удаления воткнуть виды доков, которые удалять не надо (как и их периодику), такие как амортизация и прочий мусор, связанный с ОС

(47) Конфа какая ? Торговля? Комплексная ? ПУБ ? Бухия ?

Нетленка ?

(44) У меня какойто полтергейст творится сейчас:
http://prntscr.com/sll6ri

один и тотже отчёт. 30 минут назад давал данные /в рабочей текущей базе с которйо ничего не делаю/. сейчас перестал давать

(49) самописка

(51) При этом Анализ счёта и другие отчёты отрабатывают нормально всегда:
http://prntscr.com/sll9kq

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

Запустил этот же внешний отчёт в этой же базе под другим сеансом и данные есть:
http://prntscr.com/sllguk
Что за ... ??

(51) Дык переиндексируй базу после свёртки, тупо удалив все *.cdx и зайти монопольно

(54)он не глючит

(52) короче, создай документы ввода остатков/операций и не проводи их, потом через (40) удаляешь лишнее, далее удаляешь все *.cdx и файлы бух итогов 1SBKTTL и 1SBKTTLC

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

(57) Ну как же нет. На фото видно что один и тотже отчёт сначала открывается с данными, а  потом через какоето время в этой же базе уже пустой.
Сейчас буду пытаться искать причину.

(60) Вроде разобрался отчасти, почему не мог получить корректные результаты резки. У меня косяк в базе по промежуточным итогам идёт.
Вот первый месяц в котором есть данные: октябрь 2003 года. И уже на конец этого месяца, промежуточные итоги не верные, это видно в отчёте на ноябрь 2003:
http://prntscr.com/slnnrx

Правда это не объясняет , почему отчёт "Оборотно-сальдовая ведомость" то показывает то не показывает данные.

(14) вот я вчера и косячнул так.. бух залезла взад, я пересчитал. и все уползло на точки. до даты свертки. сижу исправляю ;-)

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

(21) ну так у тебя любое действие по изменению влечет пересчет и регистров и БИ если ТА/БИ не откатить. поэтому и долго

(29) никакие документ после свертик перепроводить не надо. если входящие остатки сформировал правильно - этого достаточно. ну по регистрам стопудово так. по БИ - может что и надо, но не думаю..

(30) если помечать на удаление штатано - движения удаляются сами штатно.

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

(0) Все-таки для ТИС обработка СверткаИБ классная вещь хотя конечно елси через Универсальный двигатель регистров - это конечно более гибко

(68)+ Просто движения через Унисерсальный двигатель регистров можно потом творчески подработать а вот свертку уж ене подработаешь

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

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

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

(71) в типовой ТиС такового нет. ТЧ можно тупо чистить без проблем.

(51) Ребята, кто попытается объяснить этот полтергейст?
http://prntscr.com/sll6ri
Обычный типовой отчёт то выдаёт данные то следующим запуском может выдавать пустые цифры.

(74) Что объяснить? Что у тебя ТИИ уже не делалось давно или то, что ты ещё там работаешь?

(75) На ТИИ он умрет ждать, в (0) он об этом как раз и писал, а ты это прочитал?.
Лучше попробовать выгрузить/загрузить, это раз в 100 быстрее. Либо грохнуть все rg.*, примерно так же будет.

суко. касса. на начало. 0.006
аж слезу выбило.. ;-)

Да ты просто Экспериментатор :) https://www.youtube.com/watch?v=pgolaktMXbU
Обычное дело при обрезке базы...

(75) Врде ж все видно на фото по ссыолке, в 19-40 я запускаю отчёт и он показывает все данные, затем запускаю его заново в 19-41 и он данные уже не показывает

(78) :)))))) пиши исче

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

(74) Актуально. Без оборотки нет возможности сверять порезанную базу с исходной

1.Сформировать документы ВводаОстатков в текущей базе
2.Перенести их в пустую базу (http://catalog.mista.ru/public/195955/)
3.До перенести цены и так далее через ole

(74)переиндексируй базу, зайди монопольно, "полтернейст" исчезнет

Если нужны подробности,
ознакомься
http://catalog.mista.ru/public/15577/

(84) Не помогло, всё-равно пустые ячейки:
http://prntscr.com/smsaft
(85) Не совсем разобрался, просто блокнотом нужно отредактировать Seven.dll и DBEng32.dll найти контекст “Kernel32.dll” и заменить двойку на тройку?
и оместить в каталог исполнительных модулей 1С файл Kernel33.dll

После этого при запуске 1с ругается на испорченную dll

(87) а есть уверенность что за 1 день там что-то было ?

(87) выше приводил скрин он где заполнено.

но что-то мне мыслит что но просто суетится.
ну и версия платформы, надеюсь, 27..?

(88) непонятен сам подход. Если у него база начинается с 2017 года, почему в 2009м должно что-то быть.

(90) логично!

(88) неа, там период другой

(90) А почему бы и нет? У меня тут внезапно обнаружились документы за 203 год.... Да, не 2003, а...

Правда, они без движений, но...

(94) фу, неряха... ;-)

(95) Тю на вас, те документы созданы были, когда я находился от этой базы в 800х километрах и 10 годах... )))

(96) фу, бяка-2!

(97) Уйди, противный. Когда нашёл - удалил.

(87) Несколько раз выкладывал скрины )
в том числе и там где полтергейст (51)
http://prntscr.com/sll6ri
на скрине видно одновременно два отчёта, которые были запущены один за одним.
Первый выдал данные, через 10 секунд ничего не меняю и открываю тотже отчёт и он уже пустой

(90) Откуда взят 2017? Сейчас база с 2003 года

(87) И даже если бы за этот день ничего не было, то отчёт должен показать остатки на начало. А если бы не было и остатков на начало, то тогда отчёт не показывал бы сами счета в первом столбце

(100) потому что у тебя на скрине в (0) остатки на 01.01.2017

поэтому твоя задача сейчас - не заниматься дурью про 2009 год и 2003 год. А всё поудалять это. Вычистить все эти годы. И сравнивать остатки на 01.01.2017 в новой и старой базе.

(99) не на одном скрине нет 1 января 2009 года.

Сори, с пустой обороткой разобрался:
в отчёте данные выводятся так: ФорматС(Ит.СНД())

во всех отчётах при открытии есть:
сФорматС = "Ч0"+(Метаданные.ДлинаСуммыПроводки)+"."+Метаданные.ТочностьСуммыПроводки;

а в Оборотно-сальдовой не было это строки

Соответственно, сФорматС иногда принимало нужное значение /после запуска другого отчёта/
а иногда было пустым
)

(105) Ужос нах! Я так понимаю не ты это сделал?
Соблюдали бы стандарт 1С 7.7, обозвали бы как глФорматПроводки, закинули бы инициализацию в глобальник и было бы у тебя минус два дня работы...

(106) ну. белорусы - не сильно торопливые. а на Полесье, в Пинске - тем более.. ;-)

(106) В одной из типовых конфигураций используется такой метод. А я этот единственный отчёт случайно взял оттуда