Ошибка субд длина ключа индекса превышает максимально допустимую - Не ошибается лишь тот, кто ничего не делает!

При загрузке в файловую базу выгрузки из SQLного варианта базы, выдает ошибку:

Ошибка загрузки информационной базы. В информационную базу загружены не все данные

по причине:

Ошибка СУБД:

Длина ключа индекса превышает максимально допустимую ‘_InfoRg23439_ByDims

Нашла, что InfoRg23439 это добавленный регистр сведений, который состоит только из 5-ти измерений:

— Дата (дата и время)

— Идентификатор (строка, 500)

— Представление (строка, 500)

— Кому (строка, 50)

— Копия (строка, 200)

У всех измерений стоят флаги «Основной отбор» и «Не индексировать».

Подскажите, почему ругается на этот регистр сведений? В чем ошибка?

Источник

Недавно столкнулся с ошибкой

во время создания файлового варианта базы. CF-файл был получен из хранилища, доступ к базе в режиме предприятия был, но при этом отсутствовал доступа к СУБД. Чтобы не тратить время на настройку клиент-серверного варианта и последующего поиска ошибки с помощью СУБД можно воспользоваться следующим вариантом:

1. по описанию ошибки определить проблемный тип метаданных («_InfoR24290″ — регистр сведений), наименование индекса («ByPeriod»), количество полей индекса («(_Period, _Fld24288, … , _Fld24298)'» — 12 штук), типы полей, входящих в индекс («TSSSSSSSSRSN» — подробнее по ссылке, в данном случае было достаточно наличия подряд 8-ми строковых реквизитов);
2. выполнить код вида

ТаблицаСтруктурыИБ = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого ТекСтрока ИЗ ТаблицаСтруктурыИБ Цикл
Если Найти(ТекСтрока.ИмяТаблицы, «РегистрСведений») > 0 Тогда
ТаблицаИндексов = ТекСтрока.Индексы;
Для Каждого ТекИндекс ИЗ ТаблицаИндексов Цикл
Если ТекИндекс.ИмяИндексаХранения = «ByPeriod» И ТекИндекс.Поля.Количество() = 12 Тогда
Сообщить(«> « + ТекСтрока.ИмяТаблицы);
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецЦикла;

3. проверить метаданные, которые были выведены в сообщении (в моём случае достаточно было уменьшить длину одного строкового реквизита).

Источник

0 / 0 / 0

Регистрация: 29.07.2008

Сообщений: 87

Длина ключа индекса превышает допустимую

24.07.2011, 12:35. Показов 48089. Ответов 17

Вот такую ошибку (и см файл) я увидел сегодня, когда загружал конфигурацию из базы на sql в обычную пустую базу на компьютере. Везде,где нашел, в неродных регистрах отключил индексирование. Что еще можно сделать и как найти регситрреквизит, у которого формируется слишком длинный ключ?

1 / 1 / 0

Регистрация: 15.11.2009

Сообщений: 947

24.07.2011, 19:38

Пока могу только посочувствовать.
1. Есть такая утилита Tool_1CD.exe. Позволяет глянуть нутро 1CD файла. Может с ее помощью можно найти поле Referens61…
2. Проделать все то же, но с маленькой базой. Вплоть до пустой.

0 / 0 / 0

Регистрация: 27.04.2008

Сообщений: 371

25.07.2011, 03:54

Идешь на Инфостарт или на сайт Чистова( не сочтите за рекламу) обработку «StrukturaHraneniaBazyDannyh_Xr8v», открываешь в скулевой базе, находишь что есть твоя «не правильная» таблица (скрин разглядеть не могу) и смотришь длинну ее индекса. Как вычисляется длинна индекса есть в ЖКК. Узнать ограничение на длинну индекса для файловой базы поможет гугль. Как узнаешь — скажешь в чем дела подумаем что можно сделать ;))

0 / 0 / 0

Регистрация: 29.07.2008

Сообщений: 87

25.07.2011, 13:50

Спасибо,самое то, еще нашел обработку DBStructure81.epf , тоже удобная и полезная вещь.
Tool_1CD.exe хороша, только не показывает название объекта 1С. Я правильно понимаю, что чтобы избежать формирования длинного ключа, нужно в проблемном объекте у проблемного реквизита убрать индексирование ?

0 / 0 / 0

Регистрация: 27.04.2008

Сообщений: 371

26.07.2011, 02:39

Ну как тебе сказать…Была то же с этим проблема — сделал регистр сведений с 10 измерениями с длинной строки в 100 )) В скуле все ок, когда переводил в файловую- бац, индек слишком длинный ) В итоги измерения перевел в реквизиты и все ок. Посмотри в ЖКК как формируется длинна индекса или в большой книге по 1С(не помню как называетьчя, но она такая большая,большая.) Если не получится, завтра помогу, посмотрю что можно сделать- сегодня времени нет.

0 / 0 / 0

Регистрация: 29.07.2008

Сообщений: 87

26.07.2011, 10:39

Я совсем в непонятках. Reference61 оказался справочник «Помещения» (УТ 8.1), у которого нет никаких реквизитов. На всякий случай уменьшил длину наименования и выключил полнотекстовый поиск, все равно ошибка. ЗЫ — все изменения я делаю в вытащенной конфигурации.
Про формирование ключа пока ничего не нашел = (
И самое интересное, плюнул, удалил этот справочник и попробовал запустить без него. Вылезла та же ошибка _Referenc61 … Чего-то я совсем не понимаю.

1 / 1 / 0

Регистрация: 15.11.2009

Сообщений: 947

26.07.2011, 23:56

В «молоко», значит. Я бы рыл в сторону сложной структуры. Вот Allexei намекает на регистр ветвистый. Удаляй поочередно ресурсы, пока не нащупаешь проблемный.

0 / 0 / 0

Регистрация: 27.04.2008

Сообщений: 371

27.07.2011, 06:12

Кстати проверь не индексируется ли где поле неограниченной длинны. По индексам смотри книгу «Реализация прикладных задач в системе 1С предприятие 8.2» стр 698.

По длине индекса:
В файловом варианте индекса ограничена 1920 байт.
Для составного индекса его длина рассчитывается как сумма длин полей, входящих в индекс.
Для различных типов данных длина поля в байтах может быть вычислена по следующим формулам:
*Число: (Длина + 1) / 2 + (Длина + 1) / 2
*Строка: Длина * 3 + 2
*Дата: 8
*Булево: 1
*Ссылка: 16
Кроме этого, существует ограничение на количество полей, входящих в составной индекс. Для СУБД, отличных от файловой, максимальное количество полей в составном индексе – 16. Для файловой СУБД – 256. Если индекс содержит большее количество полей – они автоматически отбрасываются.
Теперь об индексировании:
С галочками индексировать получается не гуд ) Смотри есть регистр сведений с 3-я измерениями, по умолчанию будет индекс: Изм1+Изм2+Изм3. Есля первого измерения, без разницы стоит или нет галочка индексировать — это основной индекс он всегда есть и будет:
Основной= Изм1=Изм1+Изм2+Изм3, добавим галочку ко второму измерению в результате еще+ 1 индекс
Изм2= Изм2+Изм1+Изм3. Так что не гуд галочки тыкать везде где ни попадя, ибо натыкав их ты получишь один основной и два «не основных» индекса.
Ограничением на использование индекса при использовании СУБД, встроенной в 1С:Предприятие, является максимально допустимая суммарная длина ключа в индексе, равная 1920 байт.

0 / 0 / 0

Регистрация: 29.07.2008

Сообщений: 87

27.07.2011, 11:50

Пока так ничего и не получилось. Нашел приложением, которое Дайнеко описал поле, которое больше 1920, как от него избавиться — не знаю. Удаление ресурсов тоже ни к чему ни привело. Самый сок это когда удалены объекты, на которые ссылается ошибка и даже Tool_1CD не видит эти поля. Делал переиндексацию, ошибка начала ссылаться на следующий в списке справочник, удалил его, опять вернулась та же первоначальная ошибка.
Allexei, Проверить по всей базе ?

0 / 0 / 0

Регистрация: 27.04.2008

Сообщений: 371

28.07.2011, 03:43

Слушай, а если попробовать выгрузить конфу без данных и удалить косячные поля?
Так чисто ради эксперимента Эх жаль у нас таких ошибок не возникает… покопался бы Если есть возможность можеш скинуть пустую конфу- на выходных поковыряюсь.И еще интересно, ошибку выдает на созданные стороними разработчиками объекты? Кстати если эта конфа нужна может есть смысл поставить скули или если блюдите лицензионност постгрес?

0 / 0 / 0

Регистрация: 29.07.2008

Сообщений: 87

28.07.2011, 09:56

Так я так и возился с выгруженной конфой. Оттуда и удалял поля, какие мог) Нет, это стандартный объект, но в самой конфе изменений порядочно. Скуль стоит, на нем все работает и работать, собственно, приходится в базе на скуле. Но из-за ошибки не забрать конфу домой, там ковырять, вот это минус. Лови ссылку в ЛС.

0 / 0 / 0

Регистрация: 27.04.2008

Сообщений: 371

31.07.2011, 07:24

Ошибка в справочнике Номенклатура, реквизит «НаименованиеПок» (судя по названию и тому что с ним сделали — не стандартный ) — длинна 1000 символов. Галочка индексировать включена. Убираем галочку — все работает . Ошибка найдена с помощью обработки «StrukturaHraneniaBazyDannyh_Xr8v» по имени таблички.

0 / 0 / 0

Регистрация: 29.07.2008

Сообщений: 87

31.07.2011, 10:02

Allexei, Огромное спасибо!! Можешь ответить на пару вопросов? Как в этой обработке ты искал нужное поле ? А то я ни в 61ом справочнике ни в Справочник.Номенклатура не нашел полей из описании ошибки. И, чтобы запустить обработку, ты базу на скуле поднимал ?

0 / 0 / 0

Регистрация: 27.04.2008

Сообщений: 371

31.07.2011, 10:09

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

0 / 0 / 0

Регистрация: 29.07.2008

Сообщений: 87

31.07.2011, 11:20

Ты мне буквально глаза открыл. У меня же на 61ом на скуэлевской базе был совсем другой справочник — «помещения». А после твоих сообщений задумался и запустил обработку на начавшей работать пустой базе с проблемной конфигурацией. Так вот, оказалось, что все это время я свято верил,что эта доставшаяся мне конфигурация — из базы на sql, на которой я и запускал обработки структуры БД и видел 61ый справочник «помещения» вместо «номенклатуры». А тут задумался — проверил и понял, что конфигурация базы и моя конфигурация — похожие, но совсем не одинаковые . Вот такой вот фэйл, зато теперь все встало на свои места, чудес-то не бывает)

1 / 1 / 0

Регистрация: 15.11.2009

Сообщений: 947

31.07.2011, 11:27

Ура! Шампанского!

0 / 0 / 1

Регистрация: 22.06.2013

Сообщений: 9

31.07.2011, 14:34

А Алексея — повысить в должности

0 / 0 / 0

Регистрация: 27.04.2008

Сообщений: 371

31.07.2011, 16:28

Ага, дам руководству ссылку на тему. Может повысят хотя бы в зарплате )

Источник