Была 1С БП 3.0.167.32 в SQL, при обновлении получил ошибку:
"Microsoft SQL Server Native Client 11.0: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._DocumentJournal6982" и индекса с именем "_DocumentJournal6982_1"

Возможность выгрузки в файловую - есть.

Стал разбираться, оказывается что в журнале документов - "Журнал операций" задублировались строки документов "Регламентная операция".

То есть запрос:

ВЫБРАТЬ
	Подзапрос.Дата КАК Дата,
	Подзапрос.Ссылка КАК Ссылка,
	СУММА(Подзапрос.КоличествоЗаписей) КАК КоличествоЗаписей
ИЗ
	(ВЫБРАТЬ
		ЖурналОпераций.Дата КАК Дата,
		ЖурналОпераций.Ссылка КАК Ссылка,
		1 КАК КоличествоЗаписей
	ИЗ
		ЖурналДокументов.ЖурналОпераций КАК ЖурналОпераций) КАК Подзапрос

СГРУППИРОВАТЬ ПО
	Подзапрос.Дата,
	Подзапрос.Ссылка

ИМЕЮЩИЕ
	СУММА(Подзапрос.КоличествоЗаписей) > 1

Выдаёт мне кучу записей с документам регламентная операция.

Подскажите пожалуйста, как это можно поправить?

Конфигуратор / Администрирование / Тестирование и исправление / Реиндексация таблиц ИБ

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

(2) Удалите журнал, потом сделайте сравнение-объединение, журнал будет пересоздан

(3) +1

(2) Тогда реструктуризация

а чо, прямого доступа к скулю нет?

(6) Провокатор. Это ж запрещено лицензионным соглашением

(3)Делал так, думал обмануть систему. Я журнал не удалял, я просто убирал документ "Регламентная операция" из состава журнала. Сделал, запустил базу, всё четко дублей нет.
Вернул документ в состав журнала как в типовой поставке, и снова дубли появились после запуска.

(6)А что это даст, при условии что база сама создаёт дубли записей?

Чудес не бывает. Дважды никто регламент не запускает... некому. А вот задвоение проводок при ОДНОЙ регламентной операции - запросто. Например, если неопытная в программе ГБ указала активный счёт вместо расходного:
1. 02 вместо 44 и тогда получим 02-02 в закрытии месяца...
2. или 97 вместо 44 и тогда получим 97-97 в закрытии месяца...
А программа воспримет это у себя унутре как дублирование.

Я к чему. Вроде как в таблицах нет двойной записи, поправьте, если ошибаюсь - вроде как двойная запись собирается стыковкой отдельных записей по дебету и отдельно по кредиту?

Тогда, к примеру, один поезд идёт по дебету 02, а навстречу второй - по кредиту 02, а рельсы одни...

Не настаиваю - вполне могу ошибаться и всё дело в каком-то баге.

(10)Тут дело не в проводках, а в отражении документов Регламентная операция в журнале документов - "Журнал операций".

Подумалось мне сейчас проанализировать изменения в обновлении что ставилось первым поверх 3.0.167.32
Может быть там меняется что в этом журнале.

(12) Потом отпишИтесь. Не знаю как другим, но мне интересно )

(11) >> Вроде как в таблицах нет двойной записи, поправьте, если ошибаюсь...

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

>> ... - вроде как двойная запись собирается стыковкой отдельных записей по дебету и отдельно по кредиту?

Утверждение верно для регистра бухгалтерии без поддержки корреспонденции (в типовых ни разу не встречал использование). Там в таблицу движений добавляется поле "ВидДвижения" (соответственно - Дт или Кт). И двойная запись разваливается на две строчки - отдельно с видом движения Дт и отдельно с видом движения Кт. Закупка, например, в таком случае имеет вид:

1. Дт 41 - 100₽
2. Дт 19 - 20₽
3. Кт 60 - 120₽

А правило двойной записи контролируется по сумме всех записей в операции. Чтобы сумма всех дебетов (100+20=120₽) равнялась сумме всех кредитов (120₽).

(0) А если попробовать сделать обновление на файловой версии базы (выгрузить в dt, развернуть, обновить, выгрузить результат в dt, загрузить в клиент-серверную)?

(8) >> я просто убирал документ "Регламентная операция" из состава журнала.

Когда это делали, проверяли, что документа точно нет в журнале? Может он каким-то образом там дважды оказался (теоретически такое возможно, если когда-то обновлялись не через поддержку, а обычным сравнением-объединением конфигураций), а вы своим действием как раз дубль и убрали, оставив только одну версию?

Я бы всё таки попробовал метод из (3) с полным удалением журнала....

(15)Сделал. Не помогло. После возврата к конфигурации поставщика дубли возвращаются.

(16) А в файловой дубли появились?

(17)Да, именно в файловой это всё и делаю, так как она на индексы не ругается. В SQL сразу при обновлении ошибку выдаёт и всё.

(18) Может попробовать удалить на скуле, создать новую пустую, зарегить на сервере 1С и туда залить dt после ТиИ?
Ну бэкап скульный ессно сначала сделать...

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

(20) А если сделать новый журнал только из этого одного типа документов (Регламентная операция) - будут дубли в этом новом журнале?

(21)Хорошая идея, спасибо. Сейчас попробуемс.

(20) Аа.. не понял в (18), что дубли уже и в файловой...
Я бы попробовал в копии откатить регламенты и их грохнуть штатно, ну и далее пробовать перезакрыть с начала ведения учета и мониторить результат

(23)Мне кажется, что проблема не в документах, с ними всё ок. Проблема в журнале документов. Хотя как знать, может быть и наоборот.

(22)Не помогло, так-же дубли сразу. Даже ни одной графы не добавил в журнал.

(24) "...Хотя как знать, может быть и наоборот." = "Попытка - не пытка. Да, товарищ Берия?" :)))

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

(0) А в более ранних архивах базы такая же проблема? Не удалось понять, после чего такое вылезло?

(27)При обновлении с 3.0.167.32 на 3.0.170.19

(28) Точно на 3.0.167.32 не было этой проблемы? Рекомендую сделать реиндексацию 3.0.167.32 и попробовать снова обновиться на 3.0.170.19

(29)Запрос из (0) не выводит мне дубли на 3.0.167.32
После обновления на 3.0.170.19 этот же запрос выводит кучу дублей.

(29) Поддерживаю. Кто о чём, а... а я всё о счетах )
167.32 интересна тем, что именно в ней мощно перестроился план счетов по НДФЛ: убрали третьи субсчета, а ранешние группы счетов 68.01 и 68.21 превратили в одиночные счета. Более того на версии КОРП убрали субконто регистрации в НО.

Короче, многие крайне тяжело и с многочисленными ошибками обновлялись до 167.32 именно из-за НДФЛ.

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

(30) Тогда, действительно, почему бы не открыть архив 3.0.167.32, сделать, на всякий случай, реиндексацию и обновить до 3.0.170.19, а потом перенесете в эту базу актуальные документы с проблемной БП.

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

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

БП 3.0.173.23. Дублей нет, обновление прошло без проблем.

А не оно ли?
https://bugboard.v8.1c.ru/error/000150413

И, собственно, очень хочется уточнить - что там с расширениями?

(34)Расширения есть, но они не затрагивают документ Регламентная операция.

Я пробовал обновляться предварительно удалив все расширения, не помогло.

(32)При обновлении через промежуточные, споткнулось снова на  3.0.169.18

Вообще есть такие мысли, что если и на 3.0.167.32 вызвать реструктуризацию журнала операций, то будут дубли. Сейчас попробую.

(34)Да, это было оно, спасибо!

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

Странно конечно, расширения были по сути пустыми, там только роли были добавлены новые.

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