Вот такую ошибку (и см файл) я увидел сегодня, когда загружал конфигурацию из базы на sql в обычную пустую базу на компьютере. Везде,где нашел, в неродных регистрах отключил индексирование. Что еще можно сделать и как найти регситр\реквизит, у которого формируется слишком длинный ключ?
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Пока могу только посочувствовать.
1. Есть такая утилита Tool_1CD.exe. Позволяет глянуть нутро 1CD файла. Может с ее помощью можно найти поле Referens61...
2. Проделать все то же, но с маленькой базой. Вплоть до пустой.
1. Есть такая утилита Tool_1CD.exe. Позволяет глянуть нутро 1CD файла. Может с ее помощью можно найти поле Referens61...
2. Проделать все то же, но с маленькой базой. Вплоть до пустой.
Идешь на Инфостарт или на сайт Чистова( не сочтите за рекламу) обработку "StrukturaHraneniaBazyDannyh_Xr8v", открываешь в скулевой базе, находишь что есть твоя "не правильная" таблица (скрин разглядеть не могу) и смотришь длинну ее индекса. Как вычисляется длинна индекса есть в ЖКК. Узнать ограничение на длинну индекса для файловой базы поможет гугль. Как узнаешь - скажешь в чем дела подумаем что можно сделать 
)
)Спасибо,самое то, еще нашел обработку DBStructure81.epf , тоже удобная и полезная вещь.
Tool_1CD.exe хороша, только не показывает название объекта 1С. Я правильно понимаю, что чтобы избежать формирования длинного ключа, нужно в проблемном объекте у проблемного реквизита убрать индексирование ?
Tool_1CD.exe хороша, только не показывает название объекта 1С. Я правильно понимаю, что чтобы избежать формирования длинного ключа, нужно в проблемном объекте у проблемного реквизита убрать индексирование ?
Ну как тебе сказать...Была то же с этим проблема - сделал регистр сведений с 10 измерениями с длинной строки в 100 
)) В скуле все ок, когда переводил в файловую- бац, индек слишком длинный ) В итоги измерения перевел в реквизиты и все ок. Посмотри в ЖКК как формируется длинна индекса или в большой книге по 1С(не помню как называетьчя, но она такая большая,большая.) Если не получится, завтра помогу, посмотрю что можно сделать- сегодня времени нет.
)) В скуле все ок, когда переводил в файловую- бац, индек слишком длинный ) В итоги измерения перевел в реквизиты и все ок. Посмотри в ЖКК как формируется длинна индекса или в большой книге по 1С(не помню как называетьчя, но она такая большая,большая.) Если не получится, завтра помогу, посмотрю что можно сделать- сегодня времени нет.Я совсем в непонятках. Reference61 оказался справочник "Помещения" (УТ 8.1), у которого нет никаких реквизитов. На всякий случай уменьшил длину наименования и выключил полнотекстовый поиск, все равно ошибка. ЗЫ - все изменения я делаю в вытащенной конфигурации.
Про формирование ключа пока ничего не нашел = (
И самое интересное, плюнул, удалил этот справочник и попробовал запустить без него. Вылезла та же ошибка _Referenc61 ... Чего-то я совсем не понимаю.
Про формирование ключа пока ничего не нашел = (
И самое интересное, плюнул, удалил этот справочник и попробовал запустить без него. Вылезла та же ошибка _Referenc61 ... Чего-то я совсем не понимаю.
В "молоко", значит. Я бы рыл в сторону сложной структуры. Вот Allexei намекает на регистр ветвистый. Удаляй поочередно ресурсы, пока не нащупаешь проблемный.
Кстати проверь не индексируется ли где поле неограниченной длинны. По индексам смотри книгу "Реализация прикладных задач в системе 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 байт.
По длине индекса:
В файловом варианте индекса ограничена 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 байт.
Пока так ничего и не получилось. Нашел приложением, которое Дайнеко описал поле, которое больше 1920, как от него избавиться - не знаю. Удаление ресурсов тоже ни к чему ни привело. Самый сок это когда удалены объекты, на которые ссылается ошибка и даже Tool_1CD не видит эти поля. Делал переиндексацию, ошибка начала ссылаться на следующий в списке справочник, удалил его, опять вернулась та же первоначальная ошибка.
Allexei, Проверить по всей базе ?
Allexei, Проверить по всей базе ?
Слушай, а если попробовать выгрузить конфу без данных и удалить косячные поля?
Так чисто ради эксперимента Эх жаль у нас таких ошибок не возникает... покопался бы Если есть возможность можеш скинуть пустую конфу- на выходных поковыряюсь.И еще интересно, ошибку выдает на созданные стороними разработчиками объекты? Кстати если эта конфа нужна может есть смысл поставить скули или если блюдите лицензионност постгрес?
Так чисто ради эксперимента
Эх жаль у нас таких ошибок не возникает... покопался бы Если есть возможность можеш скинуть пустую конфу- на выходных поковыряюсь.И еще интересно, ошибку выдает на созданные стороними разработчиками объекты? Кстати если эта конфа нужна может есть смысл поставить скули или если блюдите лицензионност постгрес?Так я так и возился с выгруженной конфой. Оттуда и удалял поля, какие мог) Нет, это стандартный объект, но в самой конфе изменений порядочно. Скуль стоит, на нем все работает и работать, собственно, приходится в базе на скуле. Но из-за ошибки не забрать конфу домой, там ковырять, вот это минус. Лови ссылку в ЛС.
Ошибка в справочнике Номенклатура, реквизит "НаименованиеПок" (судя по названию и тому что с ним сделали - не стандартный ) - длинна 1000 символов. Галочка индексировать включена. Убираем галочку - все работает . Ошибка найдена с помощью обработки "StrukturaHraneniaBazyDannyh_Xr8v" по имени таблички.
) - длинна 1000 символов. Галочка индексировать включена. Убираем галочку - все работает . Ошибка найдена с помощью обработки "StrukturaHraneniaBazyDannyh_Xr8v" по имени таблички.Allexei, Огромное спасибо!! Можешь ответить на пару вопросов? Как в этой обработке ты искал нужное поле ? А то я ни в 61ом справочнике ни в Справочник.Номенклатура не нашел полей из описании ошибки. И, чтобы запустить обработку, ты базу на скуле поднимал ?
Да, поднял базу на скуле, в ней запустил обработку перед этим на вкладке настройки переключил флажок на в терминах SDBL - ведь мы пытаемся загрузить в файловый вариант. Далее появилась наша 61 таблица, на у нее появился индекс наш ну и тд и тп.
Ты мне буквально глаза открыл. У меня же на 61ом на скуэлевской базе был совсем другой справочник - "помещения". А после твоих сообщений задумался и запустил обработку на начавшей работать пустой базе с проблемной конфигурацией. Так вот, оказалось, что все это время я свято верил,что эта доставшаяся мне конфигурация - из базы на sql, на которой я и запускал обработки структуры БД и видел 61ый справочник "помещения" вместо "номенклатуры". А тут задумался - проверил и понял, что конфигурация базы и моя конфигурация - похожие, но совсем не одинаковые . Вот такой вот фэйл, зато теперь все встало на свои места, чудес-то не бывает)
. Вот такой вот фэйл, зато теперь все встало на свои места, чудес-то не бывает)Обучение наступательной кибербезопасности в игровой форме. Начать игру!