Есть ДБФ база. В ней есть справочник ОбъектыСтрахования (подчинен справочнику "ДоговораСтрахования"). Добавляю в этот справочник ОДИН реквизит (Имя="Сезонный", Тип=Число.1.0), пытаюсь сохранить. Начинается обработка справочника, которая продолжается около ЧАСА! Сервер - нормальный: 2*Xeon (по 4 ядра), 4 Гига ОЗУ, база лежит на РЭЙДЕ 1+0, ОС Win 2003 Standart.
После чего вылетает ошибка "Code Base Error 70" на индексный файл этого справочника "SC667.CDX".

Что за хреновина?? ТИИ делал - ошибок нет. Изменения в других объектах метаданных такой ошибки не вызывают.
Помогите. Вчера весь день на это убил.

(0) Размер базы какой ?

Ха, прикольно. Зашел в NEW_STRU, увидел там эту табличку и индексный файл к нему размером в 1,9 Гигов. Отсюда, скорее всего, и проблема. Но с чего вдруг он такой огромный становится????

JohnyDeath писал(а) 10. Ноября 2009 :: 08:14:

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

Сори не  совсем правильно прочитал.
Выгружаем базу ( для ускорения в базе можно удалить документы и регистры) Загружаем в новую sql базу.
Входим в базу sql видим что 1с работает
Выходим из базы
Там в sql базе  добавляем реквизит Сезонный.

Индексы для этой таблички:
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=IDD      |of ID         |0     |ID                                                          |IDD       
I=PCODE    |of PARENT and |0     |PARENTEXT,PARENTID,ISFOLDER,CODE(UPPER)                     |PCODE      
I=PDESCR   |of PARENT and |0     |PARENTEXT,PARENTID,ISFOLDER,DESCR(UPPER)                    |PDESCR    
I=CODE     |of CODE       |0     |CODE(UPPER)                                                 |CODE      
I=DESCR    |of DESCR      |0     |DESCR(UPPER)                                                |DESCR      
I=VI666    |VI666         |0     |SP666                                                       |VI666      
I=VIP666   |VIP666        |0     |PARENTEXT,PARENTID,ISFOLDER,SP666                           |VIP666    

Z1 писал(а) 10. Ноября 2009 :: 09:00:

Хорошо, попробую. А ТИИ разве такие случаи не вылавливает?
И почему индексный файл возрастает до таких огромных размеров?

Также если хочешь  и если это возможно для тебя и твоих работодателей есть еще вариант
В базе( в копии) оставляешь только справочники , документы и регистры удаляешь
Упаковываешь ее. Передаешь мне архив через интернет.
я базу запихиваю в 1c sql и разбираюсь.
Пока есть немного времени.

JohnyDeath писал(а) 10. Ноября 2009 :: 09:23:

Теоретически да. Сначала базу переносишь.
проверяешь что все работает.потом добавляешь атрибут.
я до sql2008 не добрался ( обещали дать сервер тестовый да
что то как-то все не складывается ).

PS (полуoff) а не думал чтобы Флаги типа Сезонность хранить
как char(1)? Место экономим. Чуть удлиняется объект форма надо при открытии при записи копировать в дополнительный реквизит формы.

Не может быть при размере dbf 14.5 мб CDX 2 Гб
Даже если на все реквизиты индексы навешаешь

Думаю тут проблемы в железе или возможно прямым доступом CDX правили.

Удаляешь  все CDX и переиндексируешь - 10 мин.

P.S.
Вместо ТИИ делается выгрузка и загрузка.
Никаких проблем

1. Снимаешь все галки сортировка и отбор в этом справочнике.
2. добавляешь свой реквизит
3.Сохраняешь
4.Вертаешь все галки взад..
5.Сохранеяешь
6.Наслаждаешься...

ИЛИ:

на пустой базе создаешь мд-ник и словарик + правишь в рабочей поля справочника + подмена мд и дд...

Возможно какая то битая строка лежит в наименовании или реквизите с отбором.

Наверно стоит сделать выгрузку/загрузку базы.
Правда это займет много времени

JohnyDeath писал(а) 10. Ноября 2009 :: 09:51:


Ну пока у меня кроме того что написал и написал  Eprst новых идей нет.

А в пустой базе реквизит добавляется нормально ?

JohnyDeath писал(а) 10. Ноября 2009 :: 10:08:


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

Кстати вспоминаю - была одна проблемка  PARENTID - был зациклен. Т.е. папки циклически были
вложенными.
Но был ли при этом гигансткий рост CDX не помню.

1. Снял галку с единственного индексного реквизита "ТипТС". База опять долго колбасилась, но всё-таки доделала свое дела на критической отметке индексного файла в 2 095 089 Байт! Добавлять реквизит и снова ставить галку не решился - не дотянет по-любому 

2. Выгрузка-Загрузка тоже не помогла.

3. Сделал обработку по наводке Z1 и перезаписал все элементы. Был один косяк - неуникальный код у одного элемента. Исправил. Опять долго колбасится. Уже за гиг перевалило ((.

Сейчас со скулем буду пробовать.

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

JohnyDeath писал(а) 10. Ноября 2009 :: 13:19:


Ну да.
Открыть например в Foxpro  - добавить столбец - ну минуты 3.
Подменить DD и md - еще пара минут

Переиндексировать - посмотреть что произойдет с CDX .

На зацикленность Parentid неплохо бы проверить -
выбрать все группы и потом   найти их родителей, и так раз 15.
Если через 15 шагов не пусто - значит зацикленность

По наводке Саши ака Chieftain установил количество уровней для справочника с 2 в 1 (благо групп у меня сейчас нет и пока не предвидится). Всё моментально сохранилось!

Дык нету ж родителей совсем. Но щас попробую программно сделать выборки по твоему совету.

kiruha писал(а) 10. Ноября 2009 :: 14:54:

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

Вот замена ParentExt на одинаковое значение не вызывает тормозов при 2 уровнял, индексный файл еще уменьшился

Цитата:

Тесты (#41) не коректны.
надо проверять снаружи 1с-са и как текстовые поля, потому что при преобразовании Строка <--> Число может что-то теряться,
а на уровне строк(индексов) будут совпадения.

Создал тестовую конфу, на которой видно, что 1С как-то криво перестраивает индексы. Не знаю актуальна ли проблема в SQL, но в DBF результат на лицо.
Порядок действий:
1. Обработкой "СозданиеЭлементов" создаем 20000 элементов
2. Сразу видим какого размера индексный файл для таблички "Подчиненный"
3. Можно в конфигураторе снять галку на сортировке реквизита "Тип". Сохраняемся и очень долго ждем. Смотрим на размер индексного файла в папке NEW_STRU

В моем случае для 20000 элементов справочника "Подчиненный" табличка данных весила 7,2 Мб, размер индексного файла составлял больше ГИГАбайта! Если удалить индексные файлы и зайти монопольно (пересоздать индексы), то CDX занимал скромные 2 Мб!

Больше 20000 не пробывал, но думаю, что в размере около 30000 упремся опять-таки в ограничение размера инд. файла в 2 гига.
Если кому-нибудь не сложно и интересно, проверьте, пожалуйста, у себя.