Для очистки базы от документов и регистров в базе 1с77 есть замечательный скрипт, удаляющий таблицы напрямую. Потом после тестирования и исправления с базой можно было работать. Прелесть в том, что процессу удаления занимает не более минуты. Есть ли такой же инструмент для базы 1с8? Стандартное удаление помеченных на удаление занимает значительное время. Создание базы из файла конфигурации или почкованием периферийной базы не подходит, т.к. при этом меняется внутренний идентификатор базы. В связи защитой, которая привязана к внутреннему идентификатору базы, эти способы не подходят.

Думаю накидать обработки которая создает такой скрипт (обходя метаданные и используя СтруктуруХраненияДанныхИБ) не такая уж и сложная задача

а создание временной пустой из конфигурации, ее выгрузка в дт - и загрузка из этого дт в целевой - тоже меняет внутр.ид целевой?

(2) Да

(1) Моей квалификации недостаточно. На просторах инета подобных поделок не обнаружил.
Правда нашёл один вариант. В универсальном обмене в формате XML есть последняя страничка "Удаление данных". В режиме конфигуратора убрал из состава полного обмена все объекты и запустил удаление документов и регистров. Сколько займёт времени пока не знаю, т.к. процесс еще идёт...

(4) "Стандартное удаление помеченных на удаление занимает значительное время" - тут есть выход, не помечать на удаление всю базу, а удалять порциями, по 3-5 тыс. элементов. Тогда стандартное удаление займет не так уж много времени, в общем, можно за пару часов всё вычистить. Запустив удаление несколько раз.

(0) Если надо оставить справочники я бы написал обработку (аналогичную писал давно для 7.7)
примерно по шагам
1. Отключаем итоги
2. Удаляем движения регистров (естественно все в режиме обменданными.загрузка-истина)
3. Помечаем документы к удалению и очищаем данные (реквизитты и таб.части)
4. Запускаем процесс физического удаления помеченных объектов.
5. Запускаем ТИИ
6. Включаем итоги

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

Дроп табл. Делов то на 15 минут с перекуром

(7) А без перекура на час ))

(6) Скинь )

(7) схема обработки которая накидает скрипт в (1) только не DROP, а TRUNCATE TABLE

(4) если не прикладывать усилий - ничему и не научишься

(9) семерошную обработку?
Это ж мне в архивы лезть придется - зачем,
ты же сам написал в (0) что есть для семерки прекрасный скрипт под скуль - наверное он побыстрее будет

В годах этак 5х-7х - процесс очистки базы от документов занимал примерно час - но и без скрипта по сценарию (6) не намного дольше.

+(12)
А что проблемного в 7.7 очистить документооборот?
В файловой: удаляем индексы, все dh dt ra rg, файлы общего журнала и перекрестных ссылок.
Делаем тии и вуаля
итог: База очищена от всех доков.
Процесс в пределах часа (с перекурами)

(13) Мне надо для 1с8 )

(14) +, но быстро

(14) я попробовал ИР - намного удобнее и быстрее

+(16) Нечто подобным в текущий момент занимаюсь - пробная свертка и перенос БП20 в 30 (базе 8 лет с проблемами ведения учета)

(16) Надо посмотреть. Спасибо.

загрузить кастрированный cf без РН и документов, потом загрузить исходный cf

(19) Изобрази такое чудо в студию!

(18) в ИР есть Структура хранения БД и там Очистка таблиц СУБД

Тоже пробовал ИР. Много полезного.
Вот про очистку таблиц БД через СУБД
http://devtool1c.ucoz.ru/_si/0/22160898.png

(22) ТОлько ты не учитываешь один момент - не у всех есть доступ к скулю

(23) Так это не я. Я лишь показал иллюстрацию к выше обозначенной возможности.

Пустую базу создал и объединил файлы конфигураций , так не проще ?

(20) Изобразить то можно, только вот готовить его заманаешься за счет перекрестных связей

https://infostart.ru/1c/articles/795965/

Я делаю так:
1. Делаю выгрузку базы и конфы.
2. создаю копию чистую.
3. Универсальной обработкой переношу справочники.

Быстро и удобно.

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

(27) Это пробовал изначально. По этой схеме меняется какой-то внутренний идентификатор базы. После этого не работает обработка с вшитой защитой.
(29) Любопытно. Надо попробовать.

(23) Именно этот фактор меня остановил. База моего клиента файловая.

(27) Во-первых, ТС утверждает что подобные варианты ему не подходят из-за защиты, "которая привязана к внутреннему идентификатору базы". А во-вторых, автор обработки заблуждается относительно регистрации в плане обмена "Полный"  - не все объекты базы данных участвуют в обмене. Даже если он РИБ-обмен с наименованием "Полный" :(

(29) Внутренний идентификатор сохранится, но овчинка выделки не стоит: при удалении объектов из конфигурации - контроль идет на уровне конфигурации, а наличие/отсутствие данных в базе - не принципиально. Они будут "участвовать", когда будете обновлять конфигурацию базы данных.

(33): нифига не понял. "кто на ком стоял?" (с)

(34) В чём смысл лишних телодвижений?

(35): в (0).
как неожиданно, да?

(36) Мда, информативно поговорили :) "Единственное, что человек делает всегда искренне, так это —  заблуждается."(с)
Вторая попытка: в чём смысл (29)?