По УРБД не спец.
- Есть ЦБ, есть штук 10-12 точек ПБ.
- сейчас типа все норм, за исключением кривой схемы обмена с незакрывающимися регистрами (что доставляет при открытии периода, но в целом терпимо ибо изредка подрезаю лишнее);
- история ив ЦБ и В ПБ - длинная, много лишнего старого/ненужного.
- вывели ассортимент (порядка 80% номенклатуры и столько же по объему базы)
- задача избавиться от устаревшего ассортимента
- штатно порезать/поудалять - не получится, на точках будет долго грузится и долго пересчитываться.
- думаю сделать так
1) !!ВАЖНО!! заканчиваем все циклы обмена "в ноль"
2) в ЦБ по выбранной группе/группам ассортимента (который нафиг не нужен) тупо помечаю на удаление ассортимент и всякое ему сопутствующее (цены, свойства, единицы, аналоги и прочее всякое - тут владею что и как);
3) в ЦБ тупо шарашу по всем документам, удаляю строки с неактивной номенклатурой по п.2; если док получился пустым - удаляю его нафиг.
4) штатно удаляю все помеченное
5) в обход штатных механизмов зануляю в ЦБ признаки модифицированности и данные по выгрузкам на точки.
6) думаю за ночь управлюсь
7) далее утром идет штатная работа ЦБ+ПБ все как обычно
8) получается в ЦБ порезанная нормальная база, на ПБ - непорезанная, но на ПБ назад никто не лазит, действий с неактивной номенклатурой/документами не производится
9) постпенно по аналогичному процессу режу данные на точках по пунктам  1-7, но только объектом обрезки будет ПБ, на одну точку- 1ночь.

Вот примерно так я себе представляю.
Вопросы:
?1. правильно я себе представляю?
?2. как правильно закончить цикл обменов "в ноль"..?

Спасибо

Урибовский обмен будет завершен, когда во всех базах в таблицах 1SUPDTS будет пусто. С ЦБ чуть хитрее будет, т.к. из неё данные у тебя мигрируют по разным периферийкам, но если ты её первой резать будешь - то имхо норм, именно такое условие должно быть.

+2
delete _1supdts
в ЦБ

тоже делаешь и в перефtрийках, в смысле обрезку и обнуление _1supdts

по пункту 9.

ИМХО лучше сделать инициацию ПБ с выгрузкой в неё всех нужных документов.

У нас ЦБ скуль, ПБ - дбф. За 4-5 часов с "нуля" обрезал таким образом по 2 ПБ.  ПБ - супермаркет, переносились документы за год, примерно 120 тыс. штук

(1) "Урибовский обмен будет завершен, когда во всех базах в таблицах 1SUPDTS будет пусто."
на ЦБ:
1. принял все пакеты от ПБ
2. выгрузил в ПБ
3. загрузил в ПБ

- этого достаточно чтобы вывести "в ноль"?

Я тоже за новую переинициализацию периферийных баз. Может можно сделать так. Переинициализировать одну периферийных развернуть локально и поменять внутри идентификаторы. Скопировать.

Новое создание всех ПБ после чистки ЦБ. И никаких гитик. Не надо извращаться.

(7) 20 пб долго будут создаваться.

(8) Хм. Если там полная копия, то это делается ровно столько, сколько 20 раз копируется база + 3 минуты на каждую. С перекурами.

(5) Да. Само собой, если между обменами нет изменений мигрирующих данных.
(7) а если объём данных такой, что в доступное временное окно не уложиться на инициализацию перифериек? Тут даже с одной ПБ могут быть траблы при объеме, большем чем некоторый. И почему-то мне кажется, что у Злопа именно такая ситуация, хотя могу и ошибаться.
Эхх, нет в нашей деревне контор с клюшками, на прямых бы запросах всё сделал...

(5) в (0) написано "- задача избавиться от устаревшего ассортимента".   Но потом в описании уже фигурируют какие-то документы.

Так что надо сделать - просто справочники порезать или же документы-остатки и т.д. ?

(11) если я порежу справочнгик ассортимента на 80% - этот ассортимент ходил же документами

А как заново переинициализировать ПБ?
ПБ небольшие

(13)
В ЦБ в таблице _1SBSET убирается флаг признака, что в ПБ выгружена первичная инициализация. Т.е. в списке периферийных баз данная база должна быть серого цвета.
    Для этого в колонке DBSTATUS необходимо установить значение “N”.


Другой вопрос то, что инициализация это только справочники с миграцией "Все информационные базы". Вдогонку надо будет выгружать все документы этой ПБ

(13) Вдобавок. Если есть справочники с миграцией "Место создания", надо сделать или их копии, или выгрузить нужные данные. Я потом просто подсовывал сохраненные дбф

Понял, спсб
не, проще ПБ порезать аналогично будет мне.

"Обрезку" запрограммил, тупо, медленно, но рабоче - устроит.

После того как порежу ЦБ - то в ЦБ надо удалить все записи из таблицы миграции - так?

База скульная.

delete _1supdts

- так?
а как указать в какой именно базе (их же в скуле может быть несколько) ?

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

Опять же - со сведением цикла обмена "в ноль"...

штатная работа, сводим цикл обмена в ноль
1. отправили все изменения из ЦБ в ПБ
2. загрузили в ПБ (приняли изменения из ЦБ)
3. выгрузили из ПБ для ЦБ (изменения в ПБ)
4. загрузили в ЦБ (изменения из ПБ)
5. выгрузили ЦБ для ПБ (подтверждение приема из ПБ)
6. загрузили в ПБ..

- так достаточно? или какие-то пункты - лишние?

(18) вопрос не в этом. этим пока не морочимся.

(17) из своей базы (соединения) ты обращаешься только к таблицам своей базы. Если спецом не указать другую базу

(19) прогони после окночания работы два раза цикл обмена, и не трахай мозг

ТП глянул?

(23) не, работаю пока

(21) "из своей базы (соединения) ты обращаешься только к таблицам своей базы"
- стал на таблицу апдейтса, пкм, сгенерить сценарий

DELETE FROM [MAIN_BASE].[dbo].[_1SUPDTS]
GO

так потянет? - думаю да...

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

Откатывать ТА назад и првродить в ТА - сильно не хочется...
есть мысль: доки ненужные строки удаляем. записываем. Не проводим. Прямыми запросами чистим движения и итоги регистров по ненужной номенклатуре...

А зачем тебе неправильные документы?

Если есть время сворачивать каждую базу отдельно штатными средствами, можно воспользоваться РегистрацияИзменений

РегистрацияИзменений
Синтаксис:
РегистрацияИзменений(парам)
Параметры:
  Парам (число) 1 - регистрировать изменения, 0 - не регистрировать изменения. Если параметр не указан, то регистрация не изменяется.
Назначение:
  Включить или выключить регистрацию изменений для конкретного объекта.
Замечание1
  Особенность вызова данного метода - он действует с момента своего вызова и до перепозиционирования объекта. Его нужно вызывать после позизионирования объекта, но до записи изменений. После следующего позиционирования объекта режим снова будет установлен в соответствии с режимом, выбранном в метаданных (т.е. установленный для предыдущего позиционирования режим сбрасывается).
Замечание2
  Метод РегистрацияИзменений доступен только для объектов типа "Справочник" и "Документ", созданных функцией "СоздатьОбъект".
Возврат:
Число - 1 - да, регистрация производится. 0 - нет. Возвращается установленный до ее вызова режим.
Пример:
Док = СоздатьОбъект("Документ.НазваниеДока");
Док.ВыбратьДокументы("'01.01.2002'/'01.07.2002'");
Пока Док.ПолучитьДокумент()=1 Цикл

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

  Док.РегистрацияИзменений(0);
  // изменяем чего надо
  Док.Записать();
КонецЦикла;

(27)  в результате в доках и врегистрах останутся только нужная номенклатура

(28) о, точно
Спасибо

так-с, пока получающееся не укладывается в приемлемые временные рамки... борю потихоньку дальше...

Вопрос по УРБД:
еслия в конфигурацию добавлю новый вид документа (универсальный двигатель регистров - на случай если все-таки придется сверку сделать чего очень не хочется) - то на точках после обмена правленной конфигурации - будет пересчет регистров или нет?

32 будет перестройка журнала, регистры не тронет.

(33) понял. спсб.

Лучше всего сделай обработку,  которая вычистить все на прямых запросах. Потом просто запустить её на каждой базе + пересчитать итоги.
Если на удаляемом справочнике были построены отборы документов, то придётся ещё и crcdoc пересчитать или почистить.
это никак не отразится на обменах.

По аналогии с этим http://catalog.mista.ru/public/66865/
Только вместо update поставить delete

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

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

(36)  ага, спасибо
Посмотрю как по коду сделано в части оперирования списком - как раз то что мне надо

(36)  допустим поставлю я делит
Допустим все нормально отработает
Пересчет итогов нужен? И если нужен - то почему?
Ведь и замену и делит делать можно не только в таблицах движений, но и в таблицах итогов
???

39 теоретически, если почистить и итоги,  то пересчет не нужен.

Только в той поделке итоги не чистятся - надо добавить по аналогии.

(41) понял. Спсб.

(42) удаляй и в итогах тоже -  и будет щастие.