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

25.02.19

Задачи пользователя - Корректировка данных

Ошибка "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С может быть более внимательной к данным, а разработчики прикладных решений дальновидней в плане архитектуры и инструментов сопровождения.

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

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

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

См. также

SALE! 20%

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки

Обмен между базами 1C Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) в продаже с 2015 года, постоянно работаем над их развитием | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

45650 36520 руб.

04.08.2015    159679    363    267    

345

SALE! 15%

[ED3] Обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 22572 руб.

12.06.2017    134931    722    291    

388

SALE! 20%

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | В продаже с 2019г. | Воспользовались более 176 предприятий! | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой, обращайтесь!

34650 27720 руб.

15.04.2019    68416    178    138    

111

SALE! 20%

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Воспользовались более 79 предприятий! | Предлагаем приобрести готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | В продаже с 2020г. | Оперативно обновляем правила до актуальных релизов 1С | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

43450 34760 руб.

03.12.2020    34168    80    58    

78

SALE! 10%

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.87.x) и УТ 11.5 (11.5.16.x).

28000 25200 руб.

23.07.2020    46288    196    64    

158

SALE! 10%

Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники

Обмен между базами 1C Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

В продаже с 2014г. | Воспользовались более 122 предприятий! | Перенос данных из БП 3.0 в УТ 11 | из БП 3.0 в КА 2 | из БП 3.0 в ERP | Сэкономьте свое время - используйте готовое решение для перехода! | Постоянно работаем над развитием переноса данных | Обновляем на новые релизы 1С | Есть фильтр выгрузки по организациям | Переносятся начальные остатки на выбранную дату, документы за период времени и вся возможная справочная информация | Перенос сделан на технологии КД 2 (правила конвертации данных)

50722 45650 руб.

31.10.2014    231398    124    327    

296

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9207    9    8    

10

SALE! 10%

Перенос данных из УПП 1.3 в БП 3.0. Переносятся документы (обороты за период), справочная информация и остатки

Обмен между базами 1C Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.223.x) и БП 3.0 (3.0.149.x). Правила подходят для версии ПРОФ и КОРП.

28000 25200 руб.

15.12.2021    20244    132    38    

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

I am sorry!
19. nvv1970 25.02.20 09:18 Сейчас в теме
Отвечая на вопрос "что делать" - я бы для начала собрал статистику.
Моя статистика по неуникальности на "объектах" говорит, что ошибка возникает только на совместимостях до 8.3. При чем это не только справочники, документы, но и служебные таблицы типа Files.
Впервые массово столкнувшись на автоблокировках с такой ошибкой я проанализировал трассу в скуле. Платформа выполняет select по id, а потом или insert или update. Вроде нет проблем. Однако изменение данных в транзакции, а проверка - вне. На лицо логическая ошибка установки блокировок. При отсутствии id две сессии попытаются выполнить insert. Т.е. я думал, что все дело в параллельности. На партнерке поднимал тему.
Однако, наблюдались на старых УПП такие ошибки в совместимости 8.2.13 на упрблокировках, да еще и в однопользовательском режиме. При чем картина была примерно такая: пишем объект в режиме загрузки из xml, получаем ошибку уникальности, а повтор записи проходит без проблем. Ошибка частая. Платформа может быть в т.ч. свежей. Например, на 8.3.15 ошибка все еще присутствует.
А вот при повышении совместимости до 8.3 ошибки не встречал. Трудно сказать что повлияло. Раньше бы я подумал, что rcsi. Однако при однопользовательских ошибках больше похоже на ошибки платформы в старых совместимостях.

А какая у вас статистика появления подобных ошибок, камрады?
20. Cyberhawk 135 03.03.20 17:32 Сейчас в теме
1.Полностью отключаем итоги по регистру (вот некоторая информация на ИТС).
2. Перепроводим / создаем / удаляем нужный документ.
Документ в 99% типовых не проведется, ибо при отключенных итогах запросы, использующие обращение к виртуальным таблицам регистра, выпадут в ошибку исполнения.
YPermitin; +1 Ответить
21. Cyberhawk 135 03.03.20 17:37 Сейчас в теме
Сразу скажу, что в нашем примере дублей строк не было, то есть этот способ нам не подходит. Опыт показывает, что обычно дубли строк в таблице отсутствуют
Так а откуда взяться дублям? Ошибка-то возникает при попытке вставки дублирующейся записи в таблицу СУБД и не завершается. Как тут поможет чистка каких-то дублей и при тут они вообще?
YPermitin; +1 Ответить
22. пользователь 03.03.20 17:50
(21) Так в статье же есть информация по обоим вопросам.
23. Cyberhawk 135 03.03.20 18:00 Сейчас в теме
(22) В статье ты позиционируешь вариант №2 как, мол, "Удали дубли из БД".
Этим дублям в БД неоткуда взяться, если не отключать неуникальность индекса в СУБД. Т.е. на момент ошибки (на момент попытки вставки дубля) никаких дублей в СУБД быть не может. Поэтому этот "вариант №2" никак не помогает решить проблему.
Этот "вариант №2" может быть применим только если до этого воспользовались вариантом №3 (сами отключили уникальность и тем самым допустили вставку дубля), поэтому позиционировать "вариант №2" как независимый способ лечения некорректно.
24. пользователь 03.03.20 18:13
(23) мне кажется, что есть какое-то недопонимание.
25. пользователь 03.03.20 18:18
(23) я бы описал все что в статье другими словами, но сейчас просто сил нет :)

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

Почти всегда причиной были кривые данные. Даже есть общая версия отчета для проверки регистра, чтобы такие ситуации избегать. Недавно публиковал.

Ну и да, с индексом уникальным конечно не может быть записей дублей.

Извините, если отвечаю не о том) вторник как понедельник:)))
26. Cyberhawk 135 03.03.20 18:32 Сейчас в теме
(25)
Про удаление дублей имеется ввиду исключить записи, которые появляются при вставке данных платформой
Вроде в описании варианта №2 довольно четко предлагается (скриптом-запросом к СУБД) найти и достать записи-дубли из БД. И далее по тексту моего предыдущего комментария.
27. пользователь 03.03.20 18:39
(26) из своей практики SQL-скриптом я не удалял дубли как таковые, а скорее находил потенциальные проблемы. В варианте 2 явно сделан запрос для поиска дублей, но смысла в нем на практике мало. Нужно отталкиваться от ошибки. Например, известно, что ошибка на такой-то записи, т.к. в тексте ошибки обычно пишется из-за каких значений произошел дубль.

Далее с помощью подобных запросов, лишь добавив фильтр или опустив некоторые измерения (например, значения субконто) найти повторяющиеся записи. Тут очень индивидуально. А дальше уже разбираться, что с ними делать.

Был случай, когда таким способом нашел в таблице итогов 3 записи за разные периоды (месяцы), которые мешали записать проводку в текущем периоде. Я посчитал сколько таких записей за все время (сгруппировал без учета периода). Т.к. изменять документ в прошлом периоде было нельзя (бизнес не согласовал изменение данных и пересчет итогов, т.к. это могло повлиять на отчетность), пришлось "скальпелем" при помощи SQL-запросов исправить некоторые данные в таблице итогов.

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

Как-то так. Никого не хотел запутать. А у вас тоже какая-то ошибка возникла с дублями?
28. Cyberhawk 135 03.03.20 18:42 Сейчас в теме
(27) Не особо понял, как описание варианта №4 и практики его применения относится к моему исходному комментарию, относящемуся - напомню - к варианту №2.
29. пользователь 03.03.20 18:43
(28) 2 вариант для поиска причин проблем. 4 для исправления.
31. Cyberhawk 135 03.03.20 18:46 Сейчас в теме
(29)
2 вариант для поиска причин проблем
Как поиск дублей записей может помогать выйти на причину, если в БД никаких дублей быть не может? Идем на второй круг.
32. пользователь 03.03.20 18:47
(31) :D это уже смешно.

Вернитесь к материалу позже.
30. пользователь 03.03.20 18:44
(28) Откланяюсь :) Пора и другими делами заниматься :)
Оставьте свое сообщение