v7: Свертка распределенной базы #330085

Из-за моего халатного отношения база (бухгалтерия) на семерке разрослась за 4 года до огромных размеров.Размер файла 1sbkttl.dbf чуть-чуть не дотягивает до 2 ГБ.Свыше этого размера база уже нормально работать не будет - проверено, вылетает с ошибкой.Кстати в желтых книжках не видел ограничения на размер dbf файла).Вариант,который вижу - сархивировать базу, к примеру,на начало этого года.Но есть одна проблемка - около 15 периферийных баз,используемых в магазинах, где простои 1С крайне нежелательны.А ведь из-за размера базы прийдется после свертки каждых 2 кварталов делать полный пересчет итогов(скорее всего даже предварительно удалив 1sbkttl.dbf),потому что он все равно будет расти.И так прийдется после каждого свернутого периода блокировать работу на периферийных базах на неопределенное время. Была мысль создать чистую базу,а в нее через ОЛЕ перебросить из основной базы остатки в операциях на начало года и документы с начала года по текущий момент,но ведь в данном случае в периферийные базы не попадут документы с условием миграции "Место создания и центр" (так как в чистой базе они созданы в в центре),даже если изначально они были созданы в периферийной базе.Прийдется потом уже из каждой периферийной базы перебрасывать через ОЛЕ эти документы. В общем, даже не знаю,что уже и делать,как поступить,обойтись малой кровью,чтобы заняло меньше времени.Если у кого есть какие мысли,соображения,поделитесь.

SQL или пересмотреть подход к организации УРБД. На магазинах необходимо только наличие товара, цены и долги клиентов. Время от времени сгружать в единую базу данные о продажах и грохать данные в магазинах. Плюс в том что размер базы будет мизерный. Минус - данные о продажах будут только в одной консолидированной базе, по которой и придется делать весь анализ.

15 периферийных бухгалтерских баз в магазинах?

А где можно глянуть пример? Придя на фирму,где работаю по этот день,пришлось довольстоваться (и придумывать на их основе) теми платформами и компоненнтами,которые были куплены до меня.

Что именно глянуть? SQL -

(2,5)А где можно посмотреть реализацию того подхода,который был предложен (с товаром,ценами и долгами клиентов)?

Ну незнаю, может где и есть, - ко мне "пришло" с опытом.

Для ручной операции - признак место создания и центр. Сворачивай сначала на каждой переферийке, потом обмен, потом свертка в центре. Желательно все это успеть за одни выходные, или ночь :) короче паузу в работе все магазинов. Это вариант без изврата с ОЛЕ и т д :). Я так комплексную сворачивал, по регистрам - был спец. документ, миграция - тоже МС и центр.

+ для Бухгалтерии имхо покатит wrap.ert

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

(8,9,10)Спасибо,буду пробовать.

Экспериментирую сейчас на копии базы, свертывая базу с помощью wrap.ert. Но размер 1sbkttl.dbf не уменьшается,а потихоньку увеличивается.С чем это может быть связано? Знаю,что полный пересчет итогов уменьшил бы размер файла,но при моих размерах базы и количестве перифериек, это будет длительным процессом.

Даже "Упаковка таблиц информационной базы" не уменьшила его размер.

документы удалил? выгрузка-загрузка если удалил.

да и, 1sbkttl.dbf  если не ошибаюсь - итоги. Свертка wrap.ert фиксирует итоги, а не уменьшает их :) Короче скл тебе в помощь :)

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

В общем ситуация такая. Сделал свертку центральной базы.Теперь хочу соответсвенно перебросить эти изменения на периферийные базы (в количестве 20 штук).Но выгрузка всего на 1 базу занимает около 12 часов.Пробовал разместить базу на RAM-диске - 4-6 часов. А хотелось бы ускорить этолт процесс,так как специфика работы требует ежедневного обновления периферийных баз без простоев. Есть у кого-нибудь какие мысли?