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

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

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

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

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

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

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

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

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

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

(0) "размер одного из которых достиг уже 2! Гигабайт"

могу тебя обрадовать. скоро процесс загнется
2 гиги - предел для 77

см (4),(9)

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

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

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

фс ?

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

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

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

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

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

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

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

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

(21) Ещё один метод тебе:
можешь доехать ко мне в Новокузнецк, побыстрому поменяем, вернешься обратно, всё равно будет быстрее.

Прислать по почте не предлагаю, так как в таком  случае сам не научишься.

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