Всем привет!
На предприятии сильно распухают базы 1С7.7, поэтому с началом года решено производить очистку баз. Структура предприятия филиальная, обмен с филиалами по УРИБ. Скажите пжлста как очистить базы на филиалах, а на центральной базе базу не трогать? Что лучше:
- функция свертки базы?
- удаление таблиц БД?
И еще, при дальнейшей синхронизации урезаных филиалов с центральной базой не будет ли происходить подгрузка недостающей информации?
Спасибо за полный и обстоятельный ответ!!!

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

(0) Послушай совета (1), довольно полно и обстоятельно, раз задаешь вопрос такой - значит не стоит делать тебе этого

(0) сделай КОПИИ всех баз - филиальных и центральной и пока на копии не сделаешь нормальную свертку, даже БЛИЗКО не подходи к рабочим

(3) Один из вопросов:
Что лучше:
- функция свертки базы?
- удаление таблиц БД?

... сегодня 02.12.2011 ... не осилит все равно

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

послушай совета (1), пока не поздно!

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

удалить все документы, и пусть бухи руками вбивают остатки

а я вот УРИБ слабо штырю.. потому даже в общих чертах ответ на (0) мну будет интересен

(9) Че там штырить... Центральную сверни, да обменяйся. Все что в центре пометится, то и в регионах после выгрузки...

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

(11) Что именно нагнулось-то?

Я в прошлом году сворачивал ПУБ с 03 января до 10 января... Штатными методами.
Так такая, извините фигня получилась, что и неудобно говорить.
Проще внести остатки и перекачать текущие документы за январь. Как и сделали.
А руководству я сказал, что пользователи такой бардак развели в базе, что даже вычислительные машины ломаются. Они сказали: что бы мы без Вас делали! и денег дали и просили захаживать.

(0) Не с той стороны подходите.

Мне все же интересно в разрезе УРИБ, что там сломать-то можно? Свертка че далает? Считает начальные остатки, да помечает на удаление старые доки. В соответствии с правилами обмена это пойдет в региональные. Обычные в общем-то изменения, никакой разницы как если б пользователь руками че на удаление поставил. Чему тут ломаться?

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

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

(12) всяко бывает, поверьте. конечно, бывает, что и получается, но я теперь уже ученый

(16) Ты лучше расскажи как нагнул, скрипты-то умеем ваять )

(17) Ну понимаешь, у меня как бы есть опыт сборки разных баз в уриб. Ну как разных... С точки зрения объединения одинаковые, а так разные совсем. Поменял им все иды таким образом, чтобы они поверили что все они дочки одного уриба. И вполне получилось. Ну вот как можно штатно его завалить, ась? )

не помню уже, давно было

(20) наверняка просто с версиями перемудрил, а свертка тут никаким боком.

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

(22) и не в лотерею, а в карты, и не волгу а зарплату, и не выиграл, а проиграл )

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

вам бы все шутить, дядя вася

(25) ну а чего болтаешь о чем не понимаешь? Где-то видел, что кто-то что-то сломал... Забекапить все что есть, и пусть се тренируется автор. Получится - хорошо, нет - восстановит.

Таки ТС хочет свернуть дочки, а центральную оставить без изменений. А вы уже куда-то от темы совсем далеко ушли

(24) уж догадались, наверное. ошибка вскрылась позже

(27) Не думаю. Скорее всего просто центральная скульная, и ей пофик, а дочки дбф и под два гига какая-то таблица подбирается.

(29)+ как вообще можно свернуть дочки не затронув центр? Не, ну вариант конечно, можно и на них свертки прогнать, уриб от этого не сломается. Точно так же и обменяет, как если бы руками некоторые доки создали, а другие на удаление пометили. но в итоге-то они один черт в центре помеченными станут.

(29) При чем тут "думаю-не думаю"? В (0) четко написано : "как очистить базы на филиалах, а на центральной базе базу не трогать?" Мне вот такой вариант развития событий тоже интересен

(30) Ну вот и мое любопытство удовлетворили. Вечно я хочу того, чего нельзя

а вот безгеморройного варианта обмена с периферийками, когда товар на периферийку попадает перемещениями с центрального склада - так я и не нашел.. все какие-то извраты... нет возможности сказать что вот эти документы "перемещения" - для Периферийки1, а вот эти - для Периферийка2...

(31) вообщем-то мне это тоже было интересно..

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

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

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

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

(33) кажется так можно было в МОДе извратиться, но при его включении приходиться так конфу корежить, что ну его нафиг.

"удаление таблиц БД" - что это такое?!!!!

З.Ы.: Вроде решили же что обрезка регистров не увеличивает скорость оперативного проведения, т.к. остатки на ТА будут точно таким же как и до обрезки. А обороты за прошлые периоды влияют только на отчеты.

(38) а эту проблему наверно можно решить заменой перемещения расходным и приходным ордером на товар

(30)Это как раз легко....

(33) Совсем безгеморройного - нету. А низкогеморойный - я приводил. Но для SQL/

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

(1)А нафига тогда форум? Так пофлудить зашел сюда?умник епрст
В (0)спрашивет как сделать.

(45) форум --- не есть решение проблем

аха так чисто потрындеть и в яндекс послать?

(47) скорее да, чем нет

(47) а почему бы и нет?
Я, например, прежде чем задать вопрос, лезу в яндекс...
может, поэтому у меня так мало вопросов....

(49) лазил бы в гугель, вопросов было бы ещё меньше :)

(49) ты просто "устарненец аварии на чаэ" =)

(50) гугля - куйнябуржуйская

(51)???

"устарненец" === ликвидатор

(50) для разных вопросов - разные поисковики.

(52) ага. а жигуль - надёжный отечественный аптомобиль

(54) Скорее, ликвидатор пострадавших от ЧАЭС...

(56) смотря, что ты подразумеваешь под словом "надёжность"

Бложек.mistа.ru

(57) бу га га

кстати, я заметил, что Mikeware любить пострадавших =)

(61) он, просто, быстро замечает зорким глазом ошибки в ДНК

(62) что такое "ДНК" ?

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

(63) ответ в (49)

(65) вдруг ты имел ввиду, что под данной аббревиатурой подразумеваешь Дворец Народных Кулинаров

(66) Дятлом Написанный Код

(33) "нет возможности сказать что вот эти документы "перемещения" - для Периферийки1, а вот эти - для Периферийка2"
"штатный" способ - насоздавать в конфигураторе документов ПеремещениеПереферийки1, ПеремещениеПереферийки2... настроить в каждом свои правила миграции - и вперед, у нас такой велосипед вполне работает

(69) Ну, это несколько идиотский способ...
Проще уж велосипед с создаваемыми в периферийках пустышками....

насчет, сделать свертку только в периферийке, а в ЦБ - оставить полностью документы, может быть попробовать:
0. провести все обмены, остановить создание новых документов и редактирование старых
1. в ЦБ у всех документов поставить галку миграции только "место создания", потом эту обновление в ПБ
2. свернуть периферийку отправить получившийся обмен в ЦБ (вот здесь все изменившиеся объекты не длолжны уйти в ЦБ - правильно ??)
3. убедились после нескольких обменов в результате "свертка только в периферийке, а в ЦБ - полностью документы"
4. возвращаем прежние правила миграции
взлетит корректно ?

(70) в (69) способ конечно идиотский, коробит душу творца, но ведь рабочий вариант ? конечно если ПБ не десятки

(70) а что за вариант "с создаваемыми в периферийках пустышками" ?

(71) Пляттььььь...
1.Провести полный цикл обменов.
2. Свернуть периферийки.
3. почистить в каждой периферийке апдейтс. (если файловая - переиндексироваться)
4. радоваться жизни...

(72) Даже если "не десятки", но могут "появляться- исчезать"... плодить виды документов?

(73) правило миграции БСиЦБ. В ПБ генерятся пустые доки перемещений, которые улетают в ЦБ. При "создании" перемещения в ЦБ выбирается подходящая по параметрам пустышка, и заполняется данными. И теперт совершенно штатно она будет гулять между ЦБ и нужной ПБ.
Баян, короче....

(76) спасибо

(77) Баян не мой, я просто дал объяву :-)))

(76) только у нас место создания документа - не ЦБ, а ПБ
а сделанный таким методом док ПБ - инициатор документа не увидит созданный для нее пустышку из ПБ-получателя документа

(79) кто на ком стоял?

т.е. из ПБ1 док Перемещение должен попасть в определенную ПБ2 (ну и в ЦБ само собой)

а для проведения этой операции "методом пустышек", ПБ1 (источник документа) должна видеть документ Перемещение, созданный в ПБ2 (получатель документа)

(81)а, теперь понял. Миграция  _через_ ЦБ.
Я решение тоже описывал. У меня работает. - через внешний справочник правил миграции.
для файловой базы - не будет. (точнее, будет, но я не знаю как сделать, а искать мне лень, ибо не надо)

(83) манипуляции с таблицами на низком уровне ?

(83) у меня ЦБ SQL и ПБ почти все SQL

(84) Не совсем. Но и не без этого.
Триггер на таблице даунлоадс, остальное - в ПриЗаписи

(85) вид перифериек - пофиг.

(86) а где почитать подробней ?

(88) да где-то тут описывал. был знатный ср@ч :-)))

(89) хотя бы месяц или год назад ?

УРБД: Регистрация изменений
пост 37

УРБД - миграция только в свою точку
Пост (13) - чуть более подробно

(45) мальчик, тебя кто-то обидел ?

упс.. это девочка

(30) Если очень хочется, то можно!
Сделай обмен - получи ответ - почисти базу - удали две ДБФки.   :-)

В Центре все доки на месте, а на перефирийки  - улетели на Мисту

(33) На перефирийке создаешь пустой документ ПЕРЕМЕЩЕНИЕ - выгружаешь в центр - в центре заполняешь и проводишь - выгружаешь обратно на перефирийку!    :-)