Долго сохраняется измененная конфигурация #489513

Доброго времени суток! В базе есть справочник Номенклатура, который содержит около 57 тысяч элементов. В режиме конфигуратора изменил состав реквизитов (2 реквизита удалил, 2 добавил). Процесс сохранения конфигурации затянулся уже часов на 8! При этом в папке New_Stru создались 4 файла, размер одного из которых достиг уже 2! Гигабайт, при том, что размер рабочей базы около 500 Мегабайт. Последние полтора часа процесс не движется совсем: в строке состояния 1с-ки пишется "Обработка справочника: Номенклатура: 50000", файлы в папке New_stru не меняются. Есть ли какой-то обходной манёвр для сохранения конфигурации?

ту же самую процедуру проводил на двух других базах, у которых справочник Номенклатура содержит порядка 26 тысяч элементов. Процесс занимал минут 15. Что может так сильно повлиять на затягивание процесса?

Снять с них сортировки и отборы, изменить (возможно, придется и вностить изменения последовательно), сохранить, включить сортировки и отборы...

сортировок и отборов нет по добавленным реквизитам. Один реквизит типа Число, второй - типа Строка.

Загрузить в скл, применить изменения, перегрузить в dbf :-)

ну это уже слишком :) Кстати, забыл написать, что база dbf

ТКВ! если это можно сделать любым dbf-редактором и gcomp'ом... зы. Я, кстати, наталкивался на аналогичную проблему и в SQL (ну, там правда, базка под 90 тогда была). Решил именно с помощью "прямых запросов прямыми руками", gcomp'а и такой-то матери....

Да все и так поняли, что dbf

Надо использовать другую программу для изменений структуры файлов. Например FoxPro.

1. Смотришь DD  и определяешь нужный файл. 2. Копируешь этот файл в другой каталог. Индексный файл грохаешь. 3. В каталоге ИБ удаляешь все записи из этого файла. Вот тут уже нужна другая программа, способная работать с ДБФ. 4. Делаешь изменения конфигурации. 5. Смотришь снова DD на предмет новых полей 6. В другом каталоге меняешь структуру живого файла другой программой (FoxPro), в соответствии с описанием DD 7. Копируешь живой файл в каталог ИБ. 8. Запускаешь 1с монопоольно, для восстановления индекса справочника. На всё-про всё 5-10 минут.

"размер одного из которых достиг уже 2! Гигабайт" могу тебя обрадовать. скоро процесс загнется 2 гиги - предел для 77 см ,

(9+) в п.3 и 4. можно объединить и не удалять записи, а удалить весь файл целиком, затем запустить 1с, файл будет сделан пустым.

Ты проктолог? :-)

"Копируешь живой файл " .... ну хоть не паталогоанатом

фс ?

Вам шашечки или ехать?

Ну а зачем все делать через нее?

Не знаю, что ты имеешь ввиду, но я дал реальный совет как сократить время внесения изменений с нескольких часов до нескольких минут. Если по твоему это не правильно, можешь так не делать, никто тебя не заставляет. Можешь сказать ещё более быстрый способ скажи. Я же решил помочь сибиряку. И это работает.

Твой метод предложенный в очень медленный, по сравнению с

1)Делаешь пустую базу, обработку из 15 строк, берешь DD из зависшего процесса, И обработкой реструктурируешь 4) см. выбирай любой метод.

1) Разжуй подробней, до меня не дошло. 2) Я уже сказал, что это медленно. 3) Это тоже медленно. + надо иметь SQL, не факт, что всегда под рукой. 4) Про ДБФ редактор не возражаю. Это то же самое. Только я для этих целей использую старый,добрый FoxPro 2.5

всем спасибо. ушел гуглить

Чего гуглить то? Ищи редактор DBF файлов, способный добавлять колонки в непустые таблицы.

Ещё один метод тебе: можешь доехать ко мне в Новокузнецк, побыстрому поменяем, вернешься обратно, всё равно будет быстрее. Прислать по почте не предлагаю, так как в таком  случае сам не научишься.

спасибо за помощь. Сейчас попробую твоим методом.