Добрый день!
Подскажите, кто знает...
Вводная. База обычная, файловая, *.dbf,*.cdx. Не типовая, на основе ТиС. Не сказать, что-бы сильно большая - в разных базах от 50 до 100 тысяч наименований товаров. Размер dbf-ки справочника "Номенклатура" 15 - 30 мегабайт. Необходимо добавить один реквизит, тип "число", длиной 1. Это просто флажок, "галочка". Так вот, сохранение изменений базы после добавления реквизита в конфигураторе растягивается на многие часы!

Решил найти возможность ускорить процесс, естественно, не типовыми средствами. Что сделал:
1. Удалил индексы, перенес файл справочника в отдельную папку.
2. В конфигураторе добавил необходимый реквизит, запустил базу, файл создался новый, пустой(мгновенно).
3. Опять снес индексы, перенес новый, пустой файл в отдельную папку.
4. С помощью редактора "sergdbf"(первое, что попалось под руку, умеющее добавлять колонки), добавил поле в исходную дбф-ку(мгновенно). Там-же, заполнил эту новую колонку значениями "0"(тоже мгновенно).
5. Вернул файл на место, запустил базу с восстановлением индексов.

Пока - все отлично, база работает, реквизит добавлен, "галочка" ставится/снимается, сохраняется. Казалось-бы УРА, цель достигнута, на все про все 10 минут с перекурами и все работает!
НО!!! Для контроля запускаю ТиИ, и получаю такую картинку:

https://content.foto.my.mail.ru/mail/m_w_w/_mypagephoto/i-250.jpg

Что я упустил? Длина заголовка? Пробую в том-же редакторе менять, структура нарушается, вся таблица "съезжает", нарушаетя иерархия, и появляются какие-то цифры перед наименованиями, и т.д...
Не правильный редактор? Каким тогда лучше это делать?
Может есть какой-то скрипт, макрос или утилита для такого действия? Подскажите плиз...

PS Не добавлять реквизит в справочник, а использовать другие механизмы, например через подчиненные, типа "свойства", не предлагать. Надо так, и все тут! :-) Конфа не типовая, и ни кем, кроме меня не поддерживается.

+(0) добавил поле в исходную дбф-ку(мгновенно)
Естественно, все свойства добавленного поля точно такие-же, как во вновь созданном "пустом" файле.

(0)
1.
"Размер dbf-ки справочника "Номенклатура" 15 - 30 мегабайт."
и
"сохранение изменений базы после добавления реквизита в конфигураторе растягивается на многие часы!"
Так не бывает. Файл dbf битый. Еще до добавления нового поля. Потому так долго обрабатывается.
2. Корректировку *.md отдал на откуп Пушкину?

Файл не битый, ТиИ до добавления нового поля проходит без проблем. И после добавления штатными средствами, если выждать несколько часов, то он все-таки добавляется и ТиИ проходит. Баз несколько, и во всех одинаково.
Такое чувство, что обработка файла при сохранении происходит в какой-то "неправильной" транзакции, по 100 элементов. Первые несколько тысяч проскакивают быстро, потом процесс замедляется, и к 50000 начинает обрабатывать сотню по несколько минут...

И что значит "корректировку *.md" - ? Что там корректировать, если я во пункте 2 добавил необходимый реквизит и сохранил конфигурацию? Можно подробнее, не понял?

(0) скорее таблицу не трогать.Просто очистить.Через конфигуратор новое поле.Сделать insert данных.

+(3)Первые несколько тысяч проскакивают быстро, потом процесс замедляется, и к 50000 начинает обрабатывать сотню по несколько минут...

За процессом можно наблюдать по росту размера изменяемого файла в папке "NEW_STRU".

(4) Очистить, поле добавить, это понятно... Наверно, это правильно, что-бы не создавать новый файл... А вот чем сделать "insert данных" - ? Честно говоря, не понял...

(4) я когда то делал через студио скульный.

(0) dd файл там помоему вся инфа по файлам.

Но все равно...если запустить тии до опытов ошибка будет ?

Думаю, что существующее неиспользуемое поле можно переименовать и использовать. СтавкаНП обычно свободна, но используется в модулях.

(8) Нет, до "опытов" ТиИ проходит нормально.

(9) Можно конечно, но... Это раз, ну два... А потом неиспользуемые поля закончатся, хочется научиться это делать без таких "костылей". Да их, на самом деле уже нет. НП есть, но у него тип другой, справочник ставки НП. И действительно, в модулях много где используется, косяки полезут, только успевай корректировать.

В измененной базе сделал выгрузку/загрузку данных, прошло без ошибок. Запустил ТиИ, пока крутится, не вылетело. До выгрузки/загрузки вылетало почти сразу.

Я делал как то но очень длинным путем.
Копируешь MD и файлы справочника (cdx и dbf) в новую папку.Открыть как новую базу - выгрузить данные - загрузить в SQL (будет чистая база с заполненым справочником) - добавить реквизит (в sql это происходит на порядки быстрее) - выгрузить базу - загрузить в новую dbf - скопировать md и файлы справочников в исходную.

+(11) ТиИ завершилось без ошибок(точнее, мелкие, с одним"!" были, но по номерам документов, никак не связанные с этим справочником). Так, что - выгрузка/загрузка данных помогает. Но, это сама по себе не быстрая процедура, надо искать способ редактирования заголовка DBF, что-бы исправить ошибку. Возможно, нужно другой редактор попробовать.

(12) SQL база не вариант... У себя я еще могу попробовать, но у клиентов ни как, там обычные DBF версии 1С.

(13) а перед ТиИ пробовал dd удалить и пересоздать?

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

Просто заимей комп получше...

По факту у тебя проблема с галочками "Сортировка" и "Отбор по реквизиту" для реквизитов справочника.

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

Ну и компы/железо говно на hdd дисках медленных, процы уровня P4 и памяти 512мб-1гб ))

(15) Да у меня то терпимо. Но у клиентов компы самые разные.

Что касается галочек "Сортировка" и "Отбор по реквизиту". Да, я про это читал. Но, сама процедура снять/поставить эти галочки, не окажется такой-же по времени, как добавление реквизита? Надо пробовать.

(18) Вот эти тормоза (с реструктуризацией) и были основной причиной по которой массово в свое время с радостью переходили на 1С 8.1 где такого изврата не было.
Пусть 8-ка и тормозила с ОФ намного сильнее чем 77 для юзеров в обычной работе.

Помнится смешно было когда на 400 компах (в почти 200 аптек и складе) 77 летала.
А чтобы 8-ка хоть как то крутилась пришлось заказывать партию оперативки и посылать техников все компы апгрейдить чтоб хотя бы 2 гига памяти было.

Короче пора уже 77 на покой и переходить на 8-ку.

Ага. Но, "мыши плакали, кололись, но продолжали жрать кактус" :-)

В общем - победил.
Первые три пункта так-же, а вот начиная с четвертого:
4. В редакторе Sdbf(!!!! это важно!), открываем новый, пустой файл с добавленным полем, пункт меню "Таблица" => "Добавить из другой", выбираем исходную, запрос "Условие отбора" оставляем пустым, ждем примерно около минуты. Таблица заполняется данными.
5. Все! Копируем в базу, запускаем с переиндексацией.

6. Радуемся полученным результатам, ТиИ проходит на УРА!

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

+(21)Да, забыл. Еще, после добавления данных, надо заполнить новую колонку нулями. Становимся на нужную колонку, меню Колонка=>Заменить=>Значения. Вводим "0", ОК.
Вроде все.

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

Лечил подобным образом убитую базу 7.7.
7-кой создал правильный пустой dbf, в 8-ке написал обработку переноса из битого dbf в нормальный пустой. База починилась. Мне дали мороженое, а потом денег. ;)

А дай ссылочку почитать, если не сложно...
Описание, что надо снимать галочки "Сортировка" и "Отбор по реквизиту" я видел... Но... Как-то не впечатлило. Моих реквизитов с этими галочками там только два, я их добавлял, потому, что использую в некоторых процедурах метод "НайтиПоРеквизиту", я их знаю. А сколько там еще типовых, до меня добавленных - х.з., надо лезть разбираться, каждый реквизит проверять. И не забыть потом опять их на место вернуть, а то что-нибудь обязательно работать перестанет. И сколько это займет по времени - тоже вопрос.
Поэтому, если есть какой-то еще метод(без использования SQL), и только штатными средствами, очень любопытно взглянуть.

(26) к (24)

(25) что там лечить? у автора нет описания полей ни в мд, ни в дд. Добавил рекизит в таблицу, потом спрашивает что там не так. Хочешь добавить быстро: сзделай тоже самое что и ты сделал только сначала добавь его пустую базу, получишь дд, мд, потом ложишь их в рабочую, добавляешь поле с имением как в дд путем прямого добавления, заполняешь, радуешься...

(21)
"В общем - победил."(с)
Владислав.
Посмотрите описания индексов таблицы в файле DD. Проблема возникает т.к. существует ограничение на размер ключа в индексе 117 байт, для таблиц начиная с 30000 записей. Тут обсуждали данную проблему: https://forum.infostart.ru/forum9/topic36308/

(28)у автора нет описания полей ни в мд, ни в дд.
Ну как это нет? Я же создаю "пустой" файл вместе с внесением изменений в MD и пересозданием DD.
В (0) же написано: 2. В конфигураторе добавил необходимый реквизит, запустил базу, файл создался новый, пустой(мгновенно).
Соответственно, в MD и DD новое поле прописалось!  
Естественно, я потом добавлял в старую ДБФку, поле не "от фонаря", а точно такое(с таким же именем, типом и размером) как в "пустой", вновь созданной ДБФке, и соответственно в MD и DD! Просто тот редактор, с помощью которого я это делал, судя по всему, портил заголовок DBF.

(29) Спасибо, сейчас почитаю...

(30)
Суть в 30 сообщении той темы.

Давно уже необходимости именно в таких извратах не возникало
Там 100500 полей или настолько дохлый комп? В часы с трудом верится

Да уж... Почитал. Ну, моя методика вполне себе работает. Добавляю поле штатными средствами, в пустую ДБФ-ку, а потом загружаю в нее данные. Быстро и не затратно.
Я думаю, можно попробовать другим редактором добавить поле в ДБФ, тоже должно получиться. Индекс при штатной реструктуризации у меня распухал до 300 мб. В нормальном режиме работы - 14 мб. Короче, все понятно. Вот фрагмент DD, который определяет структуру проблемного справочника: https://cloud.mail.ru/public/49G5/5QS1CvN3M
Не нравится мне там один реквизит:
F=SP9321    |(P)КодЕГАИС         |C   |19    |0
и индекс по нему:
I=VI9321   |VI9321        |0     |SP9321(UPPER=128),DESCR(UPPER)                              |VI9321    
I=VIP9321  |VIP9321       |0     |PARENTID,ISFOLDER,SP9321(UPPER=128),DESCR(UPPER)            |VIP9321
Скорее всего, тормоза из-за него. Надо его удалить, тем более он уже и не нужен - оставлен для совместимости, вместо него уже давно подчиненный справочник добавлен.
Может и реструктуризация быстрее заработает.

Полей - 35. Комп клиентский, на котором это пол дня работало - Core i5 с 8 гиг ОЗУ. Диск, правда не SSD.

(0) В ТиСе в номенклатуре есть поле НеВключатьВпрайс, и на нём сортировка. Если перед изменением её убрать, а потом включить обратно, то общее время процесса сократится на порядок. Это именно для ДБФ, в СКЛ такой проблемы нет.
Во времена седой старины это знали чуть ли не все :)

(35) спасибо не знал о таком

я делал так брал чистую базу добавлял реквизит смотрел какое поле добавлено в файле *.dd

потом в рабочей загружал в Visual foxpro нужный *.dbf файл добавлял поле
и затем подмененял заменял файлы *.md *.dd из новой базы

муторно зато быстро самое главное не запутаться

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

(36)Visual foxpro не пробовал, но "Sdbf", так-же как и первый редактор, о котором в первом сообщении темы упомянал, портит заголовок, вчера для эксперимента попробовал - также, добавляется, в базе все красиво, реквизит виден, сохраняется, как так и надо. Но, ТиИ не проходит, с той-же ошибкой. Если берешь пустую ДБФ, созданную штатно в 1С, и загружаешь в нее данные из другой(исходной) таблицы, то все нормально. Что-то там не так с заголовком файла делается, когда структуру изменяешь. Visual foxpro наверно более правильно работает, и не портит заголовок.

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

+(38)И еще штуки три реквизита с признаком "Сортировка", не мои, но и не совсем типовые - досталось "тяжкое наследство" от предыдущих, допиливавших эту конфу до меня программеров... Так, что вариант с созданием пустой дбфки и загрузки в нее данных сторонним редактором на текущий момент проще и быстрее получается.