В справочник надо занести порядка 120000 элементов. После занесения 65500 элементов обработка вываливается с ошибкой -70 ссылаясь на индексный файл. Что можно сделать как победить.

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

Или, прямой записью создать элементы справочника.

Как прямой записью создать элементы справочника. Есть периодические реквизиты. Что почитать

2 гига?

Да с лишним

с лишним быть не может

2 146 000 такая цифра была, что можно сделать?

(6) переиндексировать, может и помочь..
у реляционных баз, на базе коих написана и 1с, есть ограничение по количеству записей в одной таблице.
помнится, были приведены результаты экспериментов по заполнению такой базы..
лет много прошло.. забылись цифры. (( Но четко было написано, что при каком-то там количестве записей в таблице субд перестает работать.
можно погуглить в инете про ограничения..

+7 >>есть ограничение по количеству записей в одной таблице. <<
не намеренно предусмотренное, не программное, а чисто техническое, о котором все разработчики субд, а также и прог на их основе, стыдливо умалчивают.. пока эти ограничения не вылезут граблями

(7) "количество записей" тут совершенно ни при чем

(9)может быть.. жаль, я не написал ИМХО :)
в 1990 году видел воочию, как разрастался индексный файл, в конце концов он стал в 3 раза! больше файла DBF..

(6) ответ в (1) чем не устраивает ?

Если прямым запросом, то через Sqllock получать новй ИД и код и тупо инсертить в табличку справочника, периодику инсертить в 1sconst.. усё собственно, потом переидексировать правда придётся

Максимальное количество баз данных (FoxPro 2,6) 1млд - так что база тут не при чем

(10) а кто сказал, что индексный файл обязан быть меньше файла данных? :-))
а ограничение у 1с связано с размером файла именно в _их_реализации.

что должен быть меньше - не говорил никто.
а разрастается он при долгом применении: при любом изменении ссылка на старое значение помечается неиспользуемой, и создается новая запись/ссылка.
потому индексный файл, вроде-б призванный ускорять доступ, начинает тормозить.
неиспользуемые ссылки никуда не исчезают.
вот и рекомендуется реиндекс, чтобы их убрать

(12)это - по описанию. А есть факт, до обидного меньше требуется, чтобы заткнулась база

(15)Можно легко проверить,программным путем довести до максимумма кол записей и посмотреть результат.

(14) опять неверно. смотри устройство индекса.
(15) Это не "по описанию", а технологический предел формата. А зависит он от очень многих параметров - начиная от размера записи, и заканчивая файловой системой на диске.

(17)ошибаюсь.. бывает :)

(18) Если ошибаешься постоянно - стоит по крайней мере насторожиться...

(19)раз в год :)