Приветствую! Знаю, что была такая тема и не одна. Но год близится 2019, а решение неизвестно.
Короче, есть справочник товаров, у него 101 реквизит уже есть. Добавляю 102-й. И сохраняется база уже почти 12 часов. В любом другом справочнике это занимает не более 5-10 мин. База файловая, винт ссд 960 эво. Скорость бешеная. Но что-то мне подсказывает, что реквизит не удастся добавить. Есть у кого решение ?

Добавлю реквизит в базу за 2 минуты.

так то тема, [:]|||||||||||||||||||||||||||[:]

(1) сторонними средствами?

извращенцы )))

кол-во элементов справочника сотни тысяч-миллионы ?

(0)  "у него 101 реквизит уже есть" - и какая в этом необходимость?

Я бы пересмотрел структуру.

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

Православный метод, на пустышке создать нужный мд и словарик, любым дбф редактором открыть табличку справочника и добавить нужное поле (имя поля, размер взять из словарика или посмотреть в пустой таблице базы пустышки). Далее подмена мд и словарика. УСЁ.
ЗЫ: ну и индексный файлик прибить желательно и зайти монопольно.

(5) есть необходимость. Логически все построено корректно. Много полей с ценами и скидкими, почти все периодические

(8) Цены и скидки? В ТИС цены хранятся в другом справочнике. По скидкам уже не помню. Давно в ТИС не заглядывал.

(7) Спасибо. Православный метод в голове крутился с самого начала, но времени не было этим заниматься. А сейчас понимаю, что это и есть короткий путь ...

(9) там от ТиС одно название. Просто в тему закинул

101 реквизит это неправославно.
Афтырь никогда не слышал про 3НФ, наверное...

(12) а можно немного больше информации об этом ?

(13) https://ru.wikipedia.org/wiki/Третья_нормальная_форма

(8) уродство. если есть несколько полей одинакового "назначения" - то явно что-то с логикой не то...

"Много полей с ценами и скидкими, почти все периодические"
походу вот тут проблема, потому как это все хранится в одном файле, 1ссонст, тут надо логику перестраивать

Обычно такая хрень возникает когда не получается (по разным причинам) формализовать задачу. такой костыль и у меня есть - в карточке номенклатуры уже есть с 10 полей по типу АртикулГиперглобус, АртикулФамилия и прочие, выведенные в отдельные колонки в списках справочника номенклатуры. Уродство оно и есть уродство. Внятного изложения мыслей какие "операции" в списках справочника Номенклатура нужны с использованием этих артикулов, зачем их видет одновременно или с какими целями - от продаж не дождался. Так и висят уродскими костылями, периодически какие-то отмирают, заводятся новые.
Полная аналогия как в (0).
Костыль. Причем кривой, аж бесит.

Может в этом причина тормозов?
(8)почти все периодические

Какой размер файла 1SCONST.DBF - ?

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

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

(18) размер 1SCONST.DBF - 530 Мб, что уже многовато, приблизится к 2000 и коллапс

Есть еще вариант через SQL, но тут тоже много времени уйдет

Ты лучше на количество записей глянь. 1SCONST.DBF обычно не в размер, а 16 миллионов записей упирается.

(0) Все ж таки мне кажется что такое количество реквизитов очень сильно избыточно. Хотя когда-то делая проект по транспорту я делал такой справочник на все случаи жизни с одной записью и кучей полей. А больше ведь никак и не сделать было в семерке. И В начале работы формировал список значений куда распихивал по полям все элементы этого однозаписного справочника.

Перерабатывай структуру данных. От периодики по максимуму отказывайся, это один из основных архитектурных недостатков семёрки. Всё равно чаще всего нужна текущая цена, её и храни в реквизите отдельного справочника. Максимально используй данные других справочников, явно в таблицу цен просятся контрагенты.

Готовься переходить на SQL, с таким размером базы у тебя уже данные вероятно содержат ошибки. ТиИ делаешь? В архивы веруешь?

(25) База жива, ТиИ проходит отлично. Познакомился с базой 2 месяца тому назад. Были глюки, вылеты, но редко. Сделал выгрузку\загрузку и ТиИ. База сразу похудела на 30%. Пока полет нормальный. Только справочник товаров крутится медленно

(21) коллапс наступит уже при приближении к 1.2Гб

(26) Почисти нулевые записи итогов, возможно удивишься, симотри на ИС поиск по "Шишки для мартышки"

Итак, господа, православный метод сработал быстро и без ошибок. Спасибо всем за дискуссию, особенно господину Ёпрсту.

Метод тут (7)

(29) Рано я отрапортовал об успехе. Справочник товаров отображается только при ненажатой иерархии и внутри почти все поля очищены, при этом файл dbf заполнен. Надо разбираться...

Вы,скорей всего,в количество отборов уперлись,а не в количество реквизитов.
дело в том,что для каждого отбора строится не только просто отбор,но и отбор с иерархией.
Я отборы делал через отдельные справочники,куда первым элементом пихал ссылку на основной справочник,тогда при отборе о ображается справочник,где нет иереархии,но нужно грамотно поля прописывать при записи,чтобы не слетал отбор.

(31) Это 77. Какой отбор с иерархией? Тупые индексы и потом запросы по ним

(30) индексный файл прибей и зайди монопольно

(33) я так делал с самого начала, не помогает. Вопрос решен через SQL