Попытка вставки неуникального значения в уникальный индекс:

Пытаюсь найти дубли запросом
sel ect * from [_DocumentJournal28036] Acc (NOLOCK)
inner join
(
select
[_DocumentTRef]
[_DocumentRRef]
[_Fld1570]
fr om [_DocumentJournal28036] (NOLOCK)
group by
[_DocumentTRef]
[_DocumentRRef]
[_Fld1570]
having count(*) > 1
) doubles

ON doubles._DocumentTRef = Acc._DocumentTRef
doubles._DocumentRRef = Acc._DocumentRRef
doubles._Fld1570 = Acc._Fld1570

но получаю ошибку Сообщение 102, уровень 15, состояние 1, строка 7
Неправильный синтаксис около конструкции "_Fld1570".

Это не ваш случай?

Код ошибки: 10235932

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

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

Нарушено условие уникальности данных.
Попытка вставки неуникального значения в уникальный индекс:
23505: ERROR: could not create unique index "_documentjournalXXXXX_Xng"

(3) Знаете ли Вы как решить проблему моего случая?

1. Попробуйте вот так, информации, думаю, хватит


2. Что это за поле _Fld1570 и почему именно оно, в ключ что-ли _DocumentJournal28036_1NG входит?

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

4. Тут уже написали - это что-то 1С начудила. Ждите исправления обновления, или разберитесь насколько вам нужно в расширении уродовать журнал документов. Если, конечно, расширение не патч от 1с.

(6) до этого не знал, что это связано с расширением, перегружаю копию БД(чтобы убрать все свои эксперименты), и проверю расширения. просто пытаясь понять, оно меня не интересует, судя по всему. а как это посмотреть?

(6)
Увы ждать никак. Можно ли узнать какое именно расширение сбоит? или только методом проб искать?

(6) Да и ждать не понятно сколько) Судя по (5) ошибка с 21 года существует. А на другой версии имеется ввиду попробовать сделать обновление на другой платформе? сейчас у меня 8.3.24.1467

У вас же обновление элементарно не прошло, если я верно понял.

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

Гляньте, что творится в dbo._DocumentJournal28036NG - может там и записей-то нет, тогда просто уберите из расширения свой журнал.
Вообще - журнал вторичные данные.

P.S.
Есть такая вещь как ИР, там можно посмотреть структуру хранения базы данных и дальше уже писать запросы в терминах 1С. Вариант с прямым sql, конечно, проще и мощней, но надо им в какой-то степени владеть.

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

Отбор = Новый Структура("ИмяТаблицыХранения");
Отбор.ИмяТаблицыХранения = "_DocumentJournal28036NG";
ТЗ.НайтиСтроки(Отбор);

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

Отбор = Новый Структура("ИмяТаблицыХранения");
Отбор.ИмяТаблицыХранения = "_DocumentJournal28036";
ТЗ.НайтиСтроки(Отбор);
Пробовал так, журнал определяется, но не смог найти его в расширениях

(11) попробую удалить все расширения, ради теста

(15) помогло, но увы это не решение, в боевой БД так не получится(

Теперь при удалении(попытке) одного из раширений выходит ошибка

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

Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Не удается вставить повторяющуюся строку ключа в объект "dbo._Reference509" с уникальным индексом "_Reference509_S_HPK". Повторяющееся значение ключа: (0, 0x817fc8d3a384789d11eac1207f80b33d).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2601, line=1

_Reference<n> - это справочник как я понял. Но при каждой попытке удаления выходит разный номер(справоник). Проверяю их в SQL, а данных в них нет - пустые

(18) Но для этого нужно гонять платформу на сервере, что мне не позволят, десятки баз)

(18) и это, вроде как, другая проблема. Но все же попробую понять себе новый сервер и попробовать разные платформы. Так как уже не знаю как это решать

Добрый день.
1) Определите сначала, что за тип документа дает дублирование.
SEL ECT * FR OM _DocumentJournal28036 WHERE _DocumentRRef = 0x818fc8d3a384789d11eb6239840abf1b
Для старой таблицы - если до обновления багованый тип документов уже был в журнале - он выдаст строку, если не был то прямо во время реструктуризации запускайте запрос на новой таблице:
SEL ECT * FR OM _DocumentJournal28036NG WHERE _DocumentRRef = 0x818fc8d3a384789d11eb6239840abf1b.
По косвенным данным можно будет понять что это за тип доументов - нумерация, комментарий, строковые реквизиты.
Если указанные типы запросов не привели к успеху - есть альтернативный вариант - исключать из Журнала документов по одному типу за раз и ждать в какой момент реструктуризация завершится успешно.
2) После того как вы смогли определить тип документа который выдает ошибку реструктуризации Журнала документов, надо определить какие таблицы в базе SQL отвечают за данный тип документа - это можно сделать через Инфостарттулкит или через ИнструментыРазработчика - и там и там есть возможность посмотреть какой документ в каких таблицах хранится.
3) Допустим вы определили, что за ваш косячный тип документа отвечает таблица _Document332. Ищем есть ли таблица _Document332X1 - если есть - значит надо проверить сколько записей в каждой из них
SEL ECT COUNT(*) FROM _Document332
SELECT COUNT(*) FR OM _Document332X1
4) Если в обоих случаях число больше 0 - это и есть причина ошибки - при создании таблицы _Document332X1 - все записи должны были быть скопированы из _Document332 и таблица _Document332 должна быть очищена. Достаточно очистить таблицу _Document332 и ошибка уйдет.
TRUNCATE TABLE _Document332.
5) Если таблицы _Document332X1 в базе нет или из двух команд запроса количества записей одна выдала количество 0 - значит дублирование внутри одной таблицы - и тут то вы можете это просто определить запросом
SELECT * FR OM _Document332 WH ERE _IDRRef = 0x818fc8d3a384789d11eb6239840abf1b.
Дальше одну из этих записей очевидно надо будет удалить.