Cannot insert duplicate key. Кто виноват и что делать

Публикация № 1010017

Администрирование - Распределенная БД (УРИБ, УРБД)

SQLServer ошибка исправление тестирование CANNOT INSERT DUPLICATE KEY

78
Ошибка "CANNOT INSERT DUPLICATE KEY" в базах 1С и связанная с ней "магия".

О чем речь

Одним прекрасным днем, приходя на работу, Вы обнаруживаете странные ошибки в системе "Cannot insert duplicate key row in object 'dbo.<имя таблицы>' with unique index '<имя индекса>'". Ошибки могут появляться и на русском языке, если установлена соответствующая локализация: "Не удается вставить повторяющуюся строку в объект "dbo.<имя таблицы>" с уникальным индексом "<имя индекса>".

Появление ошибки может происходить при различных действиях, но единственное что их объединяет - это попытка изменения данных в базе данных (ну? а как иначе, ошибка то на уровне СУБД). Причем характерно это как для файлового режима работы, так и для клиент-серверных баз. В рамках статьи мы будет делать упор на работу через SQL Server, но все актуально и для PostgreSQL.

Чаще всего подобные ошибки появляются при следующих действия:

  • Проведение документа, когда он изменяет данные в регистрах.
  • Во время обменов данных между базами или другими информационными системами.
  • При попытке изменить какой-либо документ в старом периоде, хотя много лет назад он мог проводиться без проблем.

Обычно в таких случаях администраторы или разработчики запускают стандартный инструмент "Тестирование и исправление", пересчитывают итоги и др. Но давайте разберемся почему так происходит и что стоит делать в тех или иных случаях.

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

Суть проблемы

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

Кластерный индекс документа

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

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

 
 Уникальность уникальных идентификаторов

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

 
 Какие индексы у таблиц бывают

Далее разберем несколько примеров таких случаев и возможные решения.

Не могу создать документ

Иногда встречаются интеграции между системами, которые создают элементы в базе приемнике с такими же GUID'ами, как и в источнике. Это очень удобно, синхронизация по уникальным идентификаторам (ссылкам) самая надежная и простая. Но в этом случае есть бомба замедленного действия - что если в один прекрасный день уникальные идентификаторы для одного и того же объекта метаданных совпадут в разных базах?А если не уникальный?

Конечно, Вы будете говорить что это маловероятно, что нет смысла думать об этом. Ну совпадет и ладно. Просто пересоздадим объект и все, зато код работает хорошо и выглядит просто. Самое плохое тут в том, что ошибка может появится в самый неподходящий момент, например, в закрытие месяца. Окажется что из-за совпадения идентификатора не создался документ партии и все полетело к %I$#@(^. Интеграция ошибку не показала, а просто ее пропустила, никто не заметил и месяц уже закрыли. Все.

В типовых конфигурациях синхронизация объектов тоже выполняется по уникальным идентификаторам (ссылка), но через промежуточный объект - регистр сведений "СоответствияОбъектовИнформационныхБаз", который решает описанную выше проблему. Регистр хранит соответствие объектов в разных системах и уже становится не важно, что идентификаторы между ними могут совпасть. Обмен все это решит, а соответствие запишется в эту таблицу. Хотя и тут бывают сложности, но это уже другая история.

Вы можете воспроизвести подобную ошибку вставки просто выполнив подобный код.

	GUID = Новый УникальныйИдентификатор();
	
	НовЭлемент = Документы.ТестовыйДокумент.СоздатьДокумент();
	СсылкаНовогоЭлемента = Документы.ТестовыйДокумент.ПолучитьСсылку(GUID);
	НовЭлемент.УстановитьСсылкуНового(СсылкаНовогоЭлемента);
	НовЭлемент.Дата = ТекущаяДата();
	НовЭлемент.Записать();
	
	НовЭлемент = Документы.ТестовыйДокумент.СоздатьДокумент();
	СсылкаНовогоЭлемента = Документы.ТестовыйДокумент.ПолучитьСсылку(GUID);
	НовЭлемент.УстановитьСсылкуНового(СсылкаНовогоЭлемента);
	НовЭлемент.Дата = ТекущаяДата();
	// При попытке записи объекта с тем же идентификатором
	// получим ошибку
	НовЭлемент.Записать();

Ошибка, например, может быть такой. Все зависит от названия таблиц для метаданных.

Ошибка вставки повторяющегося значенияВ этом случае решением будет - делать соответствие объектов между обмениваемыми системами и не идти по правилу "один GUID для элемента во всех базах".

Это был самый простой случай, но он уже должен был Вас привести к мысли, что синхронизация по идентификаторам в обменах иногда может быть опасной. Вы можете не верить в это до последнего момента, но потом может быть уже поздно!

Проблема при записи регистров

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

Простой пример

Есть независимый непериодический регистр сведений "ДанныеДоговоровКонтрагентов" с такой структурой.

Пример регистра сведений

Если попытаться записать в него данные с повторяющимися значениями контрагента и договора, то мы поймаем такую ошибку.

Ошибка при записи в регистр сведений

То есть платформа контролирует уникальность самостоятельно, в отличии от записи объектов (документов, справочников и т.д.) с одинаковой ссылкой. Это можно определить просто взглянув на сообщение об ошибке, там нет никаких признаков, что исключение появилось на уровне СУБД. Но рано радоваться, возьмем сложный пример - регистр бухгалтерии.

Что же с данными моими стало

Думаю, с этим многие могли сталкиваться - при попытке провести документ прошлого периода возникает ошибка на таблицах регистра бухгалтерии примерно такого вида.

Ошибка при записи набора бухгалтерского регистраИстория возникновения у каждого своя, но типичные случаи все же:

  • Нужно изменить записи бухгалтерского регистра в прошлом периоде
  • Нужно дозагрузить данные в текущий или прошлый период
  • Нет никакой предыстории, просто при вводе новой операции вот такая ошибка :).

Прежде чем говорить о решении отметим, что регистр состоит из следующих таблиц.

Метаданные Назначение Имя таблицы SQL
РегистрБухгалтерии.Хозрасчетный Основная _AccRg786
РегистрБухгалтерии.Хозрасчетный ИтогиПоСчетам _AccRgAT0800
РегистрБухгалтерии.Хозрасчетный ИтогиПоСчетамССубконто1 _AccRgAT1819
РегистрБухгалтерии.Хозрасчетный ИтогиПоСчетамССубконто2 _AccRgAT2820
РегистрБухгалтерии.Хозрасчетный ИтогиПоСчетамССубконто3 _AccRgAT3821
РегистрБухгалтерии.Хозрасчетный ИтогиМеждуСчетами _AccRgCT822
РегистрБухгалтерии.Хозрасчетный ЗначенияСубконто _AccRgED823
РегистрБухгалтерии.Хозрасчетный НастройкиХраненияИтоговРегистраБухгалтерии _AccRgOpt825

Ошибка вставки не уникального значения была на таблице "_AccRgAT1819", а эта таблица итогов по счетам с субконто 1. Пока это ничего не дает, рассмотрим варианты решения.

 
 ВНИМАНИЕ! Для отчаянных администраторов и разработчиков!

Вариант №1: Просто отключи итоги

Поистине, самый простой вариант, даже инструкцию можно не писать. Шаги простые:

  1. Полностью отключаем итоги по регистру (вот некоторая информация на ИТС).
  2. Перепроводим / создаем / удаляем нужный документ.
  3. Включаем итоги обратно.

Вот и все!

Для ускорения пересчета итогов можно очистить таблицы (не для файловых баз) с помощью операции "TRUNCATE TABLE <ИмяТаблицы>, тогда платформа не будет долго удалять старые записи итогов, а сразу перейдет к расчету новых. Не забудьте перед этим сделать бэкап! В нашем случае, удаление предыдущих итогов будет таким:

-- ИтогиПоСчетам
TRUNCATE TABLE _AccRgAT0800;
-- ИтогиПоСчетамССубконто1
TRUNCATE TABLE _AccRgAT1819;
-- ИтогиПоСчетамССубконто2
TRUNCATE TABLE _AccRgAT2820;
-- ИтогиПоСчетамССубконто3
TRUNCATE TABLE _AccRgAT3821;
-- ИтогиМеждуСчетами
TRUNCATE TABLE _AccRgCT822;

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

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

Применять его или нет - решать Вам, но если есть риск нестабильной работы системы после этого, то я бы не стал. Если же за "качеством" итогов Вы следите и пересчет для Вас обычное дело, то почему бы и нет? Дальше уже рассмотрим хардкорные варианты.

Вариант №2: Удаление дублей записей

Можно попытаться найти дубли записей и что-то с ними сделать. В нашем случае для поиска дублей записей в таблице "_AccRgAT1819" можно воспользоваться таким скриптом:

SELECT 
    COUNT(*) [RowCount],
	-- Список измерений, которые содержатся в основном кластером индексе
    [_Fld774],
	[_AccountRRef],
	[_Period],
	[_Fld787RRef],
	[_Value1_TYPE],
	[_Value1_RTRef],
	[_Value1_RRRef],
	[_Fld788RRef],
	[_Fld789RRef],
	-- Разделитель записей в режиме разделения итогов
	[_Splitter]
FROM [dbo].[_AccRgAT1819]
GROUP BY
	-- Список измерений, которые содержатся в основном кластером индексе
	[_Fld774],
	[_AccountRRef],
	[_Period],
	[_Fld787RRef],
	[_Value1_TYPE],
	[_Value1_RTRef],
	[_Value1_RRRef],
	[_Fld788RRef],
	[_Fld789RRef],
	-- Разделитель записей в режиме разделения итогов
	[_Splitter]
HAVING COUNT(*) > 1

В каждом случае скрипт выглядит по своему, но общий шаблон такой.

SELECT 
    COUNT(*) [RowCount],
	-- Список измерений, которые содержатся в основном кластером индексе
    'Список измерений. Можно посмотреть в основном кластерном индексе' AS [Измерения]
FROM [dbo].[_AccRgAT1819]
GROUP BY
	-- Список измерений, которые содержатся в основном кластером индексе
	'Список измерений. Можно посмотреть в основном кластерном индексе'
HAVING COUNT(*) > 1

После того как дубли записей будут найдены можно выполнить одно из следующих действий над ними:

  1. Удалить из базы, если они действительно не нужны. Стоит учесть, что нужно будет удалить не только из одной таблицы, но и из всех связанных таблиц регистра (таблиц итогов несколько, нужно это понимать).
  2. Исправить данные как нужно с учетом также нескольких таблиц итогов.
  3. "Схлопнуть" данные по измерениям (полям кластерного индекса), тем самым убрав дубли.

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

Зато этим подходом можно найти случаи, когда дублей по полям индекса нет, но есть много дублей без учета поля-разделителя "_Splitter", который используется при включенном разделении итогов. Платформа 1С иногда может вставить в таблицу итогов повторяющуюся запись с таким же значением разделителя. Ниже расскажу о возможных причинах такого поведения и как это обходить.

Вариант №3: Отключаем уникальность индекса

Это 100% рабочий вариант, но только в качестве временного решения. Просто берем о перестраиваем индекс с отключением уникальности.

Отключение уникальности индекса

После этого никаких проблем не будет при записи проблемного документа. Почему это временное решение?

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

Но как временное решение способ идеальный. Можно отключить уникальность, а потом с помощью способов 1 или 2 исправить итоги. Или поискать причину дублей, просто проанализировав записи в итогах.

Вариант №4: Ручная корректировка данных

Самый хардкорный способ, доступный только постигшим дзен платформы 1С и принципы ее работы. Заключается в следующем - пишем SQL-запросы для ручной корректировки данных как в таблице движений и таблице субконто, так и в таблицах итогов.

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

Примеров к нему нет смысла давать. Кому нужно, тот сам поймет и выстрадает :).

А что все таки было

В нашем случае могли бы помочь 1, 2 и 4 способ, но что же все таки было? Почему создавались дубли записей? И почему дублей не было до попытки записать проблемный документ?

Ситуация для меня была очень интересной. Итоги пересчитывать было нельзя, дублей записей в таблице тоже не было. Отключил уникальность индекса и провел документ. Вот что появилось в таблице итогов (показана часть таблицы).

Счет Период Вид субконто Тип субконто Значение субконто Остаток Оборот Дт Оборот Кт Оборот 
<ссылка> 01.12.4014 0:00 NULL NULL NULL 0.00 1000 0.00 1000
<ссылка> 01.12.4014 0:00 NULL NULL NULL 0.00 -1000 0.00 -1000
<ссылка> 01.01.4015 0:00 NULL NULL NULL 1000 0.00 0.00 0.00
<ссылка> 01.01.4015 0:00 NULL NULL NULL -1000 0.00 0.00 0.00
<ссылка> 01.02.4015 0:00 NULL NULL NULL 1000 0.00 0.00 0.00
<ссылка> 01.02.4015 0:00 NULL NULL NULL -1000 0.00 0.00 0.00
<ссылка> 01.03.4015 0:00 NULL NULL NULL 1000 0.00 0.00 0.00
<ссылка> 01.03.4015 0:00 NULL NULL NULL -1000 0.00 0.00 0.00
<ссылка> 01.04.4015 0:00 NULL NULL NULL 1000 0.00 0.00 0.00
<ссылка> 01.04.4015 0:00 NULL NULL NULL -1000 0.00 0.00 0.00
<ссылка> 01.05.4015 0:00 NULL NULL NULL 1000 0.00 0.00 0.00
<ссылка> 01.05.4015 0:00 NULL NULL NULL -1000 0.00 0.00 0.00
<ссылка> 01.06.4015 0:00 NULL NULL NULL 1000 0.00 0.00 0.00
<ссылка> 01.06.4015 0:00 NULL NULL NULL -1000 0.00 0.00 0.00

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

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

Но почему в одних случаях  изменение данных прошлых периодов проходит без ошибки, а в других мы наступаем на грабли и разбиваем себе лицо? И тут тоже все просто! Виновата некорректная аналитика по субконто. У счета в проводке должна стоять аналитика по 1 субконто. В таблице выше заметно, что тип, вид и значение субконто - все NULL! При подготовке данных для записи в таблицы регистра, платформа выполняет различные запросы, в которых можно заметить такие соединения как:

-- Примеры соединения двух таблиц, где 
--  Т1 - временная таблица с подготовленными данными
--  Т2 - таблица итогов "_AccRgAT1819"
T1._Value1_TYPE = T2._Value1_TYPE AND T1._Value1_RTRef = T2._Value1_RTRef

Но т.к. значение у этих полей NULL, то запрос возвращает не те данные, что ожидается, т.к. сравниваются значения NULL. SQL Server использует трехзначную логику, при сравнении значения с NULL всегда будет NULL. В этом случае один из запросов не обновляет текущие записи в таблице итогов как положено, т.к. просто не видит их. Пример запроса, в котором выполняется обновление существующих записей итогов, Вы можете увидеть под спойлером. Там же комментариями выделено проблемное место, из-за которого этот запрос не отрабатывает как нужно - не обновляет существующую запись итогов.

 
 Проблемный запрос обновления итогов

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

 
 Запрос, который вызывает исключение при вставке записи

Но, поскольку запись итогов все же уже есть в таблице, то происходит ошибка "Cannot insert duplicate key".

 
 NULL не равно NULL

Вот такие дела. Мы рассмотрели не самый простой пример с ошибкой дублирования записи в таблице. Бывают ошибки проще Теперь ты знаешьна других таблицах и объектах метаданных. Хотя и бывают ситуации еще сложнее, когда ошибка воспроизводится спонтанно, на разных документах. Основные причины ошибки те же самые, просто "интересных" данных в регистре уже намного больше.

Не загружается DT'шник базы

Иногда подобная ошибка встречается при переводе базы из файлового варианта в клиент-серверный через загрузку-выгрузку DT-файла.

На практике относительно мало работал с файловыми базами, но решать проблему удавалось двумя способами:

  1. Удалением или редактированием битых записей перед выгрузкой в DT. Это можно сделать через режим 1С:Предприятие, если проблема в основных таблицах. Или можно воспользоваться утилитой Tool1CD.
  2. В момент загрузки DT на SQL Server сделать триггер при создании и отключить ему уникальность с помощью скрипта. Далее уже анализировать проблему.

Иногда может помочь штатное тестирование и исправление, но этот инструмент не является панацеей от всех болезней. А иногда он может и навредить, используйте с умом!

Способы не универсальные, нужно смотреть по ситуации.

Что имеем в итоге

Какой сделать вывод? Проблемы вставки не уникальной записи - это не баг СУБД! Основные причины таких ошибок:

  1. Некорректные данные в таблицах, появившееся либо в результате некорректной работы программного кода, либо из-за ошибок платформы 1С, либо при изменении учета "на лету", когда, например, изменяют состав субконто.
  2. Ошибки в коде прикладных решений.
  3. Плохое обслуживание итогов в регистрах, отсутствие проактивной сверки данных, при которой такие проблемы решались бы оперативней.

К счастью, все подобные вопросы можно решить и в абсолютном большинстве случаев без жертв.

Платформа 1С может быть более внимательной к данным, а разработчики прикладных решений дальновидней в плане архитектуры и инструментов сопровождения.

Конечно, описать все подобные ситуации нельзя в рамках только одной публикации. Но для этого добро пожаловать в комментарии, опишите свой опыт!

Другие ссылки

78

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. lunjio 60 25.02.19 06:28 Сейчас в теме
Не мешало бы ещё вариант, пересоздание индексов добавить, все таки имеет место быть и такое.
YPermitin; +1 Ответить
3. YPermitin 2623 25.02.19 12:07 Сейчас в теме
(1) а можете привести конкретный кейс, когда пересоздание индекса помогло? На моей практике вообще никогда не давпло результат.
5. lunjio 60 25.02.19 13:20 Сейчас в теме
(3) Конечно )) К примеру свертываешь большую базу, удаление приходится делать напрямую, если индексы не пересоздать, ошибки при вставке, описанные вами.
6. YPermitin 2623 25.02.19 13:49 Сейчас в теме
(5) не исключаю, конечно, что это могло бы помочь, но как?

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

Возможно Вы имеете ввиду не перестроение, что-то другое? Файловая или клиент-серверная база?

Может под перестроением понимается запуск утилиты тестировпния и исправления?
7. lunjio 60 25.02.19 14:17 Сейчас в теме
(6) Нет, понимаю пересоздание индексов через скульное обслуживание, либо да, через тестирование исправление, хотя там по-моему реорганизует, т.е фрагментирует а не создает ,верно ?
В общем ситуация следующая, удалил из таблицы все документы, с движениями и т.п, изредка возникает ошибка описанная вами, при попытке перенести в эту базу документ удаленный раннее, т.е индекс не удалился при удалении строки, из разряда фантастики конечно, но имело место.
YPermitin; +1 Ответить
8. YPermitin 2623 25.02.19 15:25 Сейчас в теме
(7) действительно, фантастика.

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

Если сможете как-то на демоданных сделать, то цены этой базе не будет.
2. vano-ekt 1168 25.02.19 11:55 Сейчас в теме
сегодня есть, что плюсануть на ИС)
kuzyara; YPermitin; +2 Ответить
4. YPermitin 2623 25.02.19 12:08 Сейчас в теме
9. acanta 56 26.02.19 14:22 Сейчас в теме
Документ из прошлого периода, 2014 года, поэтому при изменении платформа не удаляет записи из таблицы итого, а сторнирует их!

По какому принципу платформа отличает прошлый период от текущего?
Например при рассчитанных итогах на 2020 год закрывать периоды с перепроведением документов начиная с 2014 в бухгалтерии - записи будут сторнироваться или удаляться и пересоздаваться заново?
Исходя из этого, насколько часто имеет смысл пересчитывать итоги?
10. YPermitin 2623 26.02.19 15:05 Сейчас в теме
(9) главное следить, чтобы NULL не появлялось в аналитике проводок там, где не следует.

Если есть битая аналитика, то пересчет итогов может быть лишь обезбаливающим и проблемы будут пояляться.

В примере платформа сторнирует записи из-за ошибки в запросе,т.к. не нашла уже существующую запись итогов. Сторно быть не должно.

По поводу старого периода - если есть записи итогов в следующих датах, то период прошлый.
11. nytlenc 271 10.06.19 05:06 Сейчас в теме
Платформа 1С автоматически создает множество индексов в зависимости от типа метаданного. Подробнее об индексах можно прочитать на ИТС, там есть подробная информация.


Метаданного???? о_О Вы серьёзно?
Кстати вы в курсе, что ваша статья - это прямое нарушение лицензионного соглашения 1С? (п. 64)
Прикрепленные файлы:
12. YPermitin 2623 10.06.19 06:40 Сейчас в теме
(11) что Вы хотите всем этим сказать и какого ответа ожидаете? :)
13. nytlenc 271 10.06.19 06:54 Сейчас в теме
(12) Юрий, ничего злонамеренного :) Просто. Знаете ли Вы, что это нарушение лицензии (скорее всего знаете) и думаю стоит об этом упомянуть в статье (хотя может и есть, каюсь мог проглядеть).
И второе конечно, что режет глаз, слово "Метаданного", к сожалению такого слова нет, Метаданные всегда пишутся и произносятся во множественном числе, даже если идет речь о какой-то одной сущности конфигурации. То есть правильно будет писать:

Платформа 1С автоматически создает множество индексов в зависимости от типа метаданного метаданных. Подробнее об индексах можно прочитать на ИТС, там есть подробная информация.


Ваша статья довольно обширная и интересная. Но когда встречаешь подобные моменты за которые "цепляется глаз", доверие к источнику слегка падает.
Спасибо :)

Или как вариант так :

Платформа 1С автоматически создает множество индексов в зависимости от типа метаданных объекта конфигурации. Подробнее об индексах можно прочитать на ИТС, там есть подробная информация.
14. YPermitin 2623 10.06.19 07:07 Сейчас в теме
(13) Пусть статья остаенется как есть для истории.

Ваш коммментарий больше похож на троллинг, поэтому просто рекомендую почитать другие подобные статьи.

Удачного вам дня и хорошего настроения! Держитесь там! :)
15. nytlenc 271 10.06.19 08:48 Сейчас в теме
(14) )))))) Статья отличная бесспорно. Спасибо. И Вам хорошего дня.
YPermitin; +1 Ответить
16. YPermitin 2623 10.06.19 12:16 Сейчас в теме
(15) и за минус спасибо :)
17. nytlenc 271 10.06.19 12:39 Сейчас в теме
(16) Пусть останется как есть для истории. (шучу... кнопки спутал спросонья, прошу прощения) :)
YPermitin; +1 Ответить
18. YPermitin 2623 10.06.19 15:46 Сейчас в теме
(17) никого не хотел обидеть...

I am sorry!
Оставьте свое сообщение