Ошибка длины совместно используемого ключа

MySQL disallows indexing a full value of BLOB, TEXT and long VARCHAR columns because data they contain can be huge, and implicitly DB index will be big, meaning no benefit from index.

MySQL requires that you define first N characters to be indexed, and the trick is to choose a number N that’s long enough to give good selectivity, but short enough to save space. The prefix should be long enough to make the index nearly as useful as it would be if you’d indexed the whole column.

Before we go further let us define some important terms. Index selectivity is ratio of the total distinct indexed values and total number of rows. Here is one example for test table:

+-----+-----------+
| id  | value     |
+-----+-----------+
| 1   | abc       |
| 2   | abd       |
| 3   | adg       |
+-----+-----------+

If we index only the first character (N=1), then index table will look like the following table:

+---------------+-----------+
| indexedValue  | rows      |
+---------------+-----------+
| a             | 1,2,3     |
+---------------+-----------+

In this case, index selectivity is equal to IS=1/3 = 0.33.

Let us now see what will happen if we increase number of indexed characters to two (N=2).

+---------------+-----------+
| indexedValue  | rows      |
+---------------+-----------+
| ab             | 1,2      |
| ad             | 3        |
+---------------+-----------+

In this scenario IS=2/3=0.66 which means we increased index selectivity, but we have also increased the size of index. Trick is to find the minimal number N which will result to maximal index selectivity.

There are two approaches you can do calculations for your database table. I will make demonstration on the this database dump.

Let’s say we want to add column last_name in table employees to the index, and we want to define the smallest number N which will produce the best index selectivity.

First let us identify the most frequent last names:

select count(*) as cnt, last_name 
from employees 
group by employees.last_name 
order by cnt

+-----+-------------+
| cnt | last_name   |
+-----+-------------+
| 226 | Baba        |
| 223 | Coorg       |
| 223 | Gelosh      |
| 222 | Farris      |
| 222 | Sudbeck     |
| 221 | Adachi      |
| 220 | Osgood      |
| 218 | Neiman      |
| 218 | Mandell     |
| 218 | Masada      |
| 217 | Boudaillier |
| 217 | Wendorf     |
| 216 | Pettis      |
| 216 | Solares     |
| 216 | Mahnke      |
+-----+-------------+
15 rows in set (0.64 sec)

As you can see, the last name Baba is the most frequent one. Now we are going to find the most frequently occurring last_name prefixes, beginning with five-letter prefixes.

+-----+--------+
| cnt | prefix |
+-----+--------+
| 794 | Schaa  |
| 758 | Mande  |
| 711 | Schwa  |
| 562 | Angel  |
| 561 | Gecse  |
| 555 | Delgr  |
| 550 | Berna  |
| 547 | Peter  |
| 543 | Cappe  |
| 539 | Stran  |
| 534 | Canna  |
| 485 | Georg  |
| 417 | Neima  |
| 398 | Petti  |
| 398 | Duclo  |
+-----+--------+
15 rows in set (0.55 sec)

There are much more occurrences of every prefix, which means we have to increase number N until the values are almost the same as in the previous example.

Here are results for N=9

select count(*) as cnt, left(last_name,9) as prefix 
from employees 
group by prefix 
order by cnt desc 
limit 0,15;

+-----+-----------+
| cnt | prefix    |
+-----+-----------+
| 336 | Schwartzb |
| 226 | Baba      |
| 223 | Coorg     |
| 223 | Gelosh    |
| 222 | Sudbeck   |
| 222 | Farris    |
| 221 | Adachi    |
| 220 | Osgood    |
| 218 | Mandell   |
| 218 | Neiman    |
| 218 | Masada    |
| 217 | Wendorf   |
| 217 | Boudailli |
| 216 | Cummings  |
| 216 | Pettis    |
+-----+-----------+

Here are results for N=10.

+-----+------------+
| cnt | prefix     |
+-----+------------+
| 226 | Baba       |
| 223 | Coorg      |
| 223 | Gelosh     |
| 222 | Sudbeck    |
| 222 | Farris     |
| 221 | Adachi     |
| 220 | Osgood     |
| 218 | Mandell    |
| 218 | Neiman     |
| 218 | Masada     |
| 217 | Wendorf    |
| 217 | Boudaillie |
| 216 | Cummings   |
| 216 | Pettis     |
| 216 | Solares    |
+-----+------------+
15 rows in set (0.56 sec)

This are very good results. This means that we can make index on column last_name with indexing only first 10 characters. In table definition column last_name is defined as VARCHAR(16), and this means we have saved 6 bytes (or more if there are UTF8 characters in the last name) per entry. In this table there are 1637 distinct values multiplied by 6 bytes is about 9KB, and imagine how this number would grow if our table contains million of rows.

You can read other ways of calculating number of N in my post Prefixed indexes in MySQL.

MySQL disallows indexing a full value of BLOB, TEXT and long VARCHAR columns because data they contain can be huge, and implicitly DB index will be big, meaning no benefit from index.

MySQL requires that you define first N characters to be indexed, and the trick is to choose a number N that’s long enough to give good selectivity, but short enough to save space. The prefix should be long enough to make the index nearly as useful as it would be if you’d indexed the whole column.

Before we go further let us define some important terms. Index selectivity is ratio of the total distinct indexed values and total number of rows. Here is one example for test table:

+-----+-----------+
| id  | value     |
+-----+-----------+
| 1   | abc       |
| 2   | abd       |
| 3   | adg       |
+-----+-----------+

If we index only the first character (N=1), then index table will look like the following table:

+---------------+-----------+
| indexedValue  | rows      |
+---------------+-----------+
| a             | 1,2,3     |
+---------------+-----------+

In this case, index selectivity is equal to IS=1/3 = 0.33.

Let us now see what will happen if we increase number of indexed characters to two (N=2).

+---------------+-----------+
| indexedValue  | rows      |
+---------------+-----------+
| ab             | 1,2      |
| ad             | 3        |
+---------------+-----------+

In this scenario IS=2/3=0.66 which means we increased index selectivity, but we have also increased the size of index. Trick is to find the minimal number N which will result to maximal index selectivity.

There are two approaches you can do calculations for your database table. I will make demonstration on the this database dump.

Let’s say we want to add column last_name in table employees to the index, and we want to define the smallest number N which will produce the best index selectivity.

First let us identify the most frequent last names:

select count(*) as cnt, last_name 
from employees 
group by employees.last_name 
order by cnt

+-----+-------------+
| cnt | last_name   |
+-----+-------------+
| 226 | Baba        |
| 223 | Coorg       |
| 223 | Gelosh      |
| 222 | Farris      |
| 222 | Sudbeck     |
| 221 | Adachi      |
| 220 | Osgood      |
| 218 | Neiman      |
| 218 | Mandell     |
| 218 | Masada      |
| 217 | Boudaillier |
| 217 | Wendorf     |
| 216 | Pettis      |
| 216 | Solares     |
| 216 | Mahnke      |
+-----+-------------+
15 rows in set (0.64 sec)

As you can see, the last name Baba is the most frequent one. Now we are going to find the most frequently occurring last_name prefixes, beginning with five-letter prefixes.

+-----+--------+
| cnt | prefix |
+-----+--------+
| 794 | Schaa  |
| 758 | Mande  |
| 711 | Schwa  |
| 562 | Angel  |
| 561 | Gecse  |
| 555 | Delgr  |
| 550 | Berna  |
| 547 | Peter  |
| 543 | Cappe  |
| 539 | Stran  |
| 534 | Canna  |
| 485 | Georg  |
| 417 | Neima  |
| 398 | Petti  |
| 398 | Duclo  |
+-----+--------+
15 rows in set (0.55 sec)

There are much more occurrences of every prefix, which means we have to increase number N until the values are almost the same as in the previous example.

Here are results for N=9

select count(*) as cnt, left(last_name,9) as prefix 
from employees 
group by prefix 
order by cnt desc 
limit 0,15;

+-----+-----------+
| cnt | prefix    |
+-----+-----------+
| 336 | Schwartzb |
| 226 | Baba      |
| 223 | Coorg     |
| 223 | Gelosh    |
| 222 | Sudbeck   |
| 222 | Farris    |
| 221 | Adachi    |
| 220 | Osgood    |
| 218 | Mandell   |
| 218 | Neiman    |
| 218 | Masada    |
| 217 | Wendorf   |
| 217 | Boudailli |
| 216 | Cummings  |
| 216 | Pettis    |
+-----+-----------+

Here are results for N=10.

+-----+------------+
| cnt | prefix     |
+-----+------------+
| 226 | Baba       |
| 223 | Coorg      |
| 223 | Gelosh     |
| 222 | Sudbeck    |
| 222 | Farris     |
| 221 | Adachi     |
| 220 | Osgood     |
| 218 | Mandell    |
| 218 | Neiman     |
| 218 | Masada     |
| 217 | Wendorf    |
| 217 | Boudaillie |
| 216 | Cummings   |
| 216 | Pettis     |
| 216 | Solares    |
+-----+------------+
15 rows in set (0.56 sec)

This are very good results. This means that we can make index on column last_name with indexing only first 10 characters. In table definition column last_name is defined as VARCHAR(16), and this means we have saved 6 bytes (or more if there are UTF8 characters in the last name) per entry. In this table there are 1637 distinct values multiplied by 6 bytes is about 9KB, and imagine how this number would grow if our table contains million of rows.

You can read other ways of calculating number of N in my post Prefixed indexes in MySQL.

0 / 0 / 0

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

Сообщений: 87

1

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

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


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

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

0

1 / 1 / 0

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

Сообщений: 947

24.07.2011, 19:38

2

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

0

0 / 0 / 0

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

Сообщений: 371

25.07.2011, 03:54

3

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

0

0 / 0 / 0

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

Сообщений: 87

25.07.2011, 13:50

4

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

0

0 / 0 / 0

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

Сообщений: 371

26.07.2011, 02:39

5

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

0

0 / 0 / 0

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

Сообщений: 87

26.07.2011, 10:39

6

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

0

1 / 1 / 0

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

Сообщений: 947

26.07.2011, 23:56

7

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

0

0 / 0 / 0

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

Сообщений: 371

27.07.2011, 06:12

8

Кстати проверь не индексируется ли где поле неограниченной длинны. По индексам смотри книгу «Реализация прикладных задач в системе 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 / 0

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

Сообщений: 87

27.07.2011, 11:50

9

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

0

0 / 0 / 0

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

Сообщений: 371

28.07.2011, 03:43

10

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

0

0 / 0 / 0

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

Сообщений: 87

28.07.2011, 09:56

11

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

0

0 / 0 / 0

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

Сообщений: 371

31.07.2011, 07:24

12

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

0

0 / 0 / 0

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

Сообщений: 87

31.07.2011, 10:02

13

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

0

0 / 0 / 0

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

Сообщений: 371

31.07.2011, 10:09

14

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

0

0 / 0 / 0

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

Сообщений: 87

31.07.2011, 11:20

15

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

0

1 / 1 / 0

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

Сообщений: 947

31.07.2011, 11:27

16

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

0

0 / 0 / 1

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

Сообщений: 9

31.07.2011, 14:34

17

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

0

0 / 0 / 0

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

Сообщений: 371

31.07.2011, 16:28

18

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

0

Влияние ограничений длины ключа индексов на проектирование объектов метаданных

Опубликовано: 29.07.2014 /

В процессе работы с 1С:Предприятием 8 в некоторых случаях может выдаваться сообщение: «Длина ключа индекса превышает максимально допустимую» или другое аналогичного содержания. Этот документ посвящен причинам возникновения такого рода ошибок и содержит рекомендации по их предотвращению.

Индексы

Для ускорения поиска нужных записей в таблицах базы данных создаются индексы. 1С:Предприятие 8.1 создает индексы автоматически в соответствии с набором объектов метаданных конфигурации и их свойствами. Подробная информация об индексах, создаваемых 1С:Предприятием в таблицах базы данных, непосредственно доступных в запросах, содержится в документе «Индексы таблиц базы данных».

Особый интерес представляют индексы таблиц регистров, включающие поля измерений или базовых измерений.

Из индексов, создаваемых в таблицах базы данных, которые непосредственно из запросов не доступны, важно отметить индексы, создаваемые в каждой из таблиц итогов регистра бухгалтерии. Таблиц итогов создается на 1 больше, чем максимальное количество субконто в назначенном данному регистру плане счетов. Причем, отличаются они количеством полей значений субконто. В индекс входят следующие поля:

Период + Счет + Измерение1 [+ Измерение2 …] + ЗначениеСубконто1 [+ ЗначениеСубконто2 + …]

Ограничения на индексы

Поскольку для хранения данных 1С:Предприятие использует СУБД (либо встроенную, либо Microsoft SQL Server), то и поддержка индексов таблиц базы данных целиком возложена на используемую СУБД. Поэтому достижение ограничений, накладываемых различными СУБД на создание и использование индексов, может привести к ошибкам при работе с 1С:Предприятием. Поэтому при разработке конфигураций эти ограничения важно иметь в виду.

Файловый вариант информационной базы

Единственным ограничением на использование индекса при использовании СУБД, встроенной в 1С:Предприятие, является максимально допустимая суммарная длина ключа в индексе, равная 1920 байт. При попытке создания индекса с длиной ключа, превышающей 1920 байт, будет выдано сообщение об ошибке.

Клиент-серверный вариант информационной базы

Клиент-серверный вариант информационной базы подразумевает использование Microsoft SQL Server в качестве СУБД. В Microsoft SQL Server определены следующие ограничения на использование индексов:

  • максимальное количество полей, участвующих в индексе, равно 16.
  • максимально допустимая суммарная длина ключа в индексе равна 900 байт.

Важно иметь в виду, что в процессе определения объектов метаданных 1С:Предприятие при попытке создания индекса, включающего более 16 полей, в клиент-серверном варианте ИБ индекс усекается справа до 16. Это повышает надежность работы системы, но может привести к некоторому снижению производительности операций над соответствующими таблицами из-за ухудшения качества усеченных индексов.

О вычислении длины ключа

Длина ключа в индексе не является столь определенным понятием, как количество участвующих в нем полей. В общем случае при создании индекса невозможно точно определить длину ключа в создаваемом индексе. На то есть две основные причины:

  • Во-первых, способ построения индекса существенно зависит от используемой СУБД.
  • Во-вторых, длина ключа каждой записи индекса может зависеть от содержащихся в ней данных. В частности, при использовании в индексе полей типа VARBINARY Microsoft SQL Server помещает в запись индекса данные фактической длины, которая может быть меньше, чем заданная максимальная длина поля. С другой стороны, при использовании в индексе данных типа NCHAR или NVARCHAR длина представления этих данных в записи индекса для некоторых СУБД может существенно превышать максимальное количество символов, отведенное на поле строкового типа, из-за использования ключей сравнения (Collation Key), построение которых зависит от национальных настроек базы данных.

По этим причинам 1С:Преприятие 8.1 не выполняет автоматической проверки длин ключей создаваемых индексов. Таким образом, если при создании или использовании индекса будет превышена максимальная для данной СУБД длина ключа, то 1С:Предприятие выдаст сообщение об ошибке, порожденное используемой СУБД.

Рекомендации по конфигурированию

Поскольку введение ограничений на длины ключей в создаваемых индексах в платформе 1С:Предприятия не может быть универсальным и в тоже время может создать дополнительные сложности, при разработке конфигураций необходимо эти ограничения учитывать. Следование ниже приведенным правилам не позволит длинам ключей в индексах подходить к «критической отметке».

  • Не используйте индексирование по строковым полям, суммарная длина которых превышает 300 символов. Такой индекс может быть создан при выборе в значения «Индексирование» или «Индексировать с дополнительным упорядочиванием» свойства «Индексировать» реквизита или измерения. Кроме того, индекс по полю будет создан при вхождении этого поля в какой-нибудь критерий отбора.
  • Не используйте в регистрах слишком много измерений, особенно, если среди них есть поля строковых типов. Для ориентировки можно считать, что поле типа число занимает 16 байт ключа индекса, строка — 3*n байт (где n — максимальная длина строки), дата — 8 байт, булево — 1 байт, ссылка на один объект — 16 байт, ссылка на несколько объектов — 20 байт.
  • Избегайте использование измерений составных типов. Исключение может составлять комбинирование ссылок различных типов.
  • Не задавайте в планах счетов слишком большое максимальное количество субконто (превышение числа 5 может быть оправдано только в случае более тщательного анализа опасности превышения максимальной длины ключа индекса, и эффективности работы самого регистра).
  • Не рекомендуется в одном регистре бухгалтерии использовать субконто со значениями различных примитивных типов. См. также Назначение прикладного объекта «План видов характеристик».
  • Не используйте в регистрах бухгалтерии слишком большое количество измерений в сочетании с большим максимальным количеством субконто.

Техническая часть:

В файловом варианте 1С:Предприятия длина индекса ограничена 1920 байт.
Для составного индекса его длина рассчитывается как сумма длин полей, входящих в индекс.
Для различных типов данных 1С:Предприятия длина поля в байтах может быть вычислена по следующим формулам:

  • Число: (Длина + 1) / 2 + (Длина + 1) % 2
  • Строка: Длина * 3 + 2
  • Дата: 8
  • Булево: 1
  • Ссылка: 16

Кроме этого, существует ограничение на количество полей, входящих в составной индекс. Для СУБД, отличных от файловой, максимальное количество полей в составном индексе – 16. Для файловой СУБД – 256. Если индекс содержит большее количество полей – они автоматически отбрасываются. Так работает модель информационной базы 1С:Предприятия.

Теперь об индексировании:

Рассмотрим самый простой случай непериодического независимого регистра сведений с тремя измерениями: Изм1, Изм2, Изм3.
Для него система всегда автоматически (независимо от того, указаны или нет свойства Индексировать для каждого измерения) строит основной индекс Изм1 + Изм2 + Изм3, в который входят все измерения в том порядке, в котором они заданы при конфигурировании.
Если для Изм2, например, задается свойство Индексировать, то создается еще один дополнительный индекс: Изм2 + Изм1 + Изм3.
Если для Изм3, например, задается свойство Индексировать, то создается еще один дополнительный индекс: Изм3 + Изм1 + Изм2.

Таким образом, в вашем случае, для регистра создано 20 индексов: основной и 19 дополнительных. Каждый из индексов содержит 20 полей.

Подробнее обо всех основных и дополнительных индексах написано на ИТС:
1С:Предприятие. Работаем с программами  
  1C. Методическая поддержка 1С:Предприятия 8.1
     Администрирование
       Индексы таблиц базы данных

Судя по вашему сообщению, все измерения строкового типа, значит, на каждое измерение может максимально приходиться 1920/20 = 96 байт.
Исходя из приведенной выше формулы можно заключить, что длина каждого строкового измерения не может быть больше (96-2)/3 = 31 символа.

Таким образом, в порядке возрастания полезности, можно посоветовать следующее:
— снять свойство Индексировать у всех измерений, это удалит 19 ненужных индексов. 
— проанализировать длину измерений и уменьшить ее исходя из максимум 31 символа на одно измерение.
— перепроектировать регистр.

По поводу проектирования:
1. Регистр сведений с 20 измерениями уже вызывает сомнения. Каждое измерение – это разрез, в котором может быть получена информация, хранящаяся в регистре. Сложно представить информацию, которую нужно получать в 20 разных разрезах.
2. Все измерения имеют тип Строка. Очень вероятно, что в данном случае вместо регистра сведений следует использовать справочник.

В процессе обновления информационной базы произошла критическая что это?

Я
   Cerera

21.08.13 — 17:03

Это когда я из рабочей базы выгрузил CF файл потом создал чистую базу и сделал «загрузить конфигурацию».

В процессе обновления информационной базы произошла критическая ошибка.

по причине:

Ошибка СУБД:

Длина ключа индекса превышает максимально допустимую ‘_InfoR12141_ByDims_SSSSSSRSST (_Fld12142, _Fld12143, _Fld12144, _Fld12145, _Fld12146, _Fld12147, _Fld12148_TYPE, _Fld12148_RTRef, _Fld12148_RRRef, _Fld12149, _Fld12150, _Fld12151)’

по причине:

Длина ключа индекса превышает максимально допустимую ‘_InfoR12141_ByDims_SSSSSSRSST (_Fld12142, _Fld12143, _Fld12144, _Fld12145, _Fld12146, _Fld12147, _Fld12148_TYPE, _Fld12148_RTRef, _Fld12148_RRRef, _Fld12149, _Fld12150, _Fld12151)’

   shuhard

1 — 21.08.13 — 17:03

(0)[Длина ключа индекса превышает максимально допустимую]

какая буква не понятна ?

   Cerera

2 — 22.08.13 — 08:00

(1)Мне не понятно какая такая длина индекса и по какой причине это происходит вообще?

   skunk

3 — 22.08.13 — 08:01

у регистра сведений — InfoR12141 … слишком докуя полей

   Cerera

4 — 22.08.13 — 08:05

(3)а как определить чтоэто за регистр?

   Olmer

5 — 22.08.13 — 08:07

ПолучитьСтруктуруХраненияБазыДанных()

   shuhard

6 — 22.08.13 — 08:09

(3) всё проще

ТС выгрузил cf с сиквела и сует в файловую, а там в Рг сведений текстовое измерение

   Cerera

7 — 22.08.13 — 08:10

(6)да. есть такое. а как же быть?

   shuhard

8 — 22.08.13 — 08:12

(7) включить мозг

   Cerera

9 — 22.08.13 — 08:15

(8)А что в файловой версии нельзя индексированные текстовые поля делать?

   Olmer

10 — 22.08.13 — 08:17

(9) Насколько помню, ограничение на размер индекса есть в файловой.

   Defender aka LINN

11 — 22.08.13 — 08:19

(9) Я бы вообще задумался — нахрена такое поле впилось?

   shuhard

12 — 22.08.13 — 08:25

(9) ну 2-3 символа можно, ну не твои 128

   Cerera

13 — 22.08.13 — 08:37

(5)благодаря тебе родился этот гениальный код:

Процедура КнопкаВыполнитьНажатие(Кнопка)

    МассивИменМетаданных = Новый Массив();

    Для Каждого Эл Из Метаданные.РегистрыСведений Цикл

        МассивИменМетаданных.Добавить(Эл)

    КонецЦикла;

    ЭлементыФормы.ТаблицаСтруктуры.Значение=ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных);

    ЭлементыФормы.ТаблицаСтруктуры.СоздатьКолонки();

КонецПроцедуры

   Cerera

14 — 22.08.13 — 08:48

там нет в базе такого

InfoR12141  — этой таблицы.

   shuhard

15 — 22.08.13 — 08:57

(14) а кто тебе сказал, что в сиквельной и файловой базах имена таблиц совпадают ?

   Cerera

16 — 22.08.13 — 09:01

(15)А где мне искать лучше? на SQL ?

   Cerera

17 — 22.08.13 — 09:01

(15)мне надо узнать что это за регистр. как это сделать?

   shuhard

18 — 22.08.13 — 09:04

(17) ну это же типовая конфа, сравни с конфигурацией поставщика и найди Рг сведений с херовыми измерениями

   Serg_1960

19 — 22.08.13 — 09:05

(15) Эээ…вообще-то — совпадают. Даже в различных базах они, как правило, совпадают — конфигурация поставщика определяющий фактор. Если, конечно, изменения были не настолько глубоки, что от конфигурации поставщика осталось рожки да ножки.

   Cerera

20 — 22.08.13 — 09:07

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

   Serg_1960

21 — 22.08.13 — 09:08

Короткое замечание: не исключено, что это новый регистр — из обновления. Тогда, пока тс обновление не накатит, — ФигВам его найдёт в своей конфе :)

   shuhard

22 — 22.08.13 — 09:09

(21) то, что это самопальный регистр, очевидно

   Cerera

23 — 22.08.13 — 09:09

(21)ну а мне что делать? запустить конфу из которой я выгрузил CF ?

   Cerera

24 — 22.08.13 — 09:13

нашел регистр сведений у которого одно измерение имеет тип «Строка 500»

   Starhan

25 — 22.08.13 — 09:14

(24) сними индесирование

   Cerera

26 — 22.08.13 — 09:14

(25)индексирования там нет. но есть полнотекстовый поиск

   Starhan

27 — 22.08.13 — 09:17

ну тож убирай :)

   Cerera

28 — 22.08.13 — 09:18

Но это не решение проблемы. Мне нужно реально определить что за регистр это на который ругается программа.

   Serg_1960

29 — 22.08.13 — 09:25

Попробуй вот это:

СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных(,Истина);

Для Каждого Таблица Из СтруктураХранения Цикл

    Для Каждого Индекс Из Таблица.Индексы Цикл

        Если Найти(Индекс.ИмяИндексаХранения, «_InfoR12141_ByDims_SSSSSSRSST») > 0 Тогда

            Сообщить(Таблица.Метаданные + » » + Таблица.Назначение);

            Сообщить(»   » + Индекс.ИмяИндексаХранения);

            Для Каждого Поле Из Индекс.Поля Цикл

                Сообщить(»      » + Поле.ИмяПоля + » » + Поле.ИмяПоляХранения + » » + Поле.Метаданные);

            КонецЦикла;

        КонецЕсли;

    КонецЦикла;    

КонецЦикла;

   MSII

30 — 22.08.13 — 09:26

Радченко:

«В файловом варианте 1С:Предприятия длина индекса ограничена 1920 байт.

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

Для различных типов данных 1С:Предприятия длина поля в байтах может быть вычислена по следующим формулам:

    Число: (Длина + 1) / 2 + (Длина + 1) % 2

    Строка: Длина * 3 + 2

    Дата: 8

    Булево: 1

    Ссылка: 16

Кроме этого, существует ограничение на количество полей, входящих в составной индекс. Для СУБД, отличных от файловой, максимальное количество полей в составном индексе – 16. Для файловой СУБД – 256. Если индекс содержит большее количество полей – они автоматически отбрасываются. Так работает модель информационной базы 1С:Предприятия.»

   Cerera

31 — 22.08.13 — 09:45

(29)в рабочей базе нет ничего что содержит «12141»

   Cerera

32 — 22.08.13 — 09:55

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

   arsik

33 — 22.08.13 — 11:04

(32) Ты сортировки-выборки не учил что ли? Сначала грохни половину, потом половину половины.

   ptiz

34 — 22.08.13 — 11:11

(32) У вас много регистров со строковыми измерениями или с большим числом измерений????

   shuhard

35 — 22.08.13 — 11:15

(32) ну если слабо перебрать через метаданные измерения Рг сведений, то удаляй по одному

   Cerera

36 — 22.08.13 — 11:23

(35)не находит по ID измерение

(34)как выяснилось что немало ))

(33)знаю я это.

   shuhard

37 — 22.08.13 — 11:55

(36)[)не находит по ID измерение ]

чё ?

   Cerera

38 — 22.08.13 — 12:08

(37)ну код из (29) не помог мне найти интересующее поле регистра. методом удаления приходится решать.

   shuhard

39 — 22.08.13 — 12:11

(38)  ну если слабо перебрать через метаданные измерения Рг сведений, то удаляй по одному

   Cerera

40 — 22.08.13 — 13:49

(39)вы бы хоть пояснили что значит перебрать. перебирал я их. но нет там с таким ID

   shuhard

41 — 22.08.13 — 14:43

(40) какой нах ID,

нужно искать измерения с типом строка

   Cerera

42 — 22.08.13 — 14:48

(41)ну так я нашел их всех. они по 500-750 символов длиной. сейчас несчадно меняем базу.

   NcSteel

43 — 22.08.13 — 14:51

(42) Одного измерения с длинной в 500 символов достаточно…. а их у тебя много.

Руки следует оторвать тому кто их создавал.

   Cerera

44 — 22.08.13 — 14:56

(43)ну молодой программист не знал как правильно делать. он из армии только пришел и сразу на боевую площадку его выпустили с нулём знаний по 1с он уже через месяц научился писать обработки и документы. ну а регистры проектировал не совсем правильно но теперь зато знает что к чему.

   Starhan

45 — 22.08.13 — 15:03

все таки уникальная профессия у нас :).

  

shuhard

46 — 22.08.13 — 15:13

(42) топик закрыт



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

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

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

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

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

  • Ошибка длины значения снилс что значит
  • Ошибка длины dors 750
  • Ошибка длина не может быть меньше нуля имя параметра length
  • Ошибка дк1 ваз 2110
  • Ошибка дифференциального реле давления при розжиге бош 4000