Кто-то до меня криво обновлял базу БП каз. Конфа поставщика 1.5.хх или 2.5.хх уже не помню.
А база в релизе 3.0.25.2.

Решил вернуть базу к типовой. Загрузил конфу. И при обновлении ошибка.

РС запись не уникальна. там 2 измерения 2 ресурса.
Реально не уникальности не нашел. РС сам по себе не изменился.

Как быть???

(0) Это в режиме конфигуратора происходит или предприятия?

(1) В режиме конфы. Когда пытаюсь обновить новую конфу.

Вот такой запрос ничего не выдал.

ВЫБРАТЬ
    ВложенныйЗапрос.ЭСФ КАК ЭСФ,
    ВложенныйЗапрос.НомерЗаписи КАК НомерЗаписи,
    ВложенныйЗапрос.Дата КАК Дата,
    ВложенныйЗапрос.Состояние КАК Состояние,
    ВложенныйЗапрос.записей КАК записей
ИЗ
    (ВЫБРАТЬ
        ИсторияЭСФ.ЭСФ КАК ЭСФ,
        ИсторияЭСФ.НомерЗаписи КАК НомерЗаписи,
        ИсторияЭСФ.Дата КАК Дата,
        ИсторияЭСФ.Состояние КАК Состояние,
        СУММА(1) КАК записей
    ИЗ
        РегистрСведений.ИсторияЭСФ КАК ИсторияЭСФ
    
    СГРУППИРОВАТЬ ПО
        ИсторияЭСФ.ЭСФ,
        ИсторияЭСФ.НомерЗаписи,
        ИсторияЭСФ.Дата,
        ИсторияЭСФ.Состояние) КАК ВложенныйЗапрос
ГДЕ
    ВложенныйЗапрос.записей > 1

СГРУППИРОВАТЬ ПО
    ВложенныйЗапрос.ЭСФ,
    ВложенныйЗапрос.НомерЗаписи,
    ВложенныйЗапрос.Дата,
    ВложенныйЗапрос.Состояние,
    ВложенныйЗапрос.записей

(3) Ресурсы убери

Пытался перезаписать записи чтоб избавиться от дублей. Тоже пока нет результатов.

(3) наверно удаляете одно из измерений. Это обычная ситуация.

Этот РС заполняется чем? Не совсем понятно по тексту

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

Конечно же, бакапы никто не отменял

Непериодический и независимый РС может ведь иметь разные значения ресурсов при одинаковых измерениях???

(8) у вас измерения неодинаковые. Просто имя совпадает. А на самом деле они разные.

(8) до изменения структуры записи были уникальны. Уникальность портится изменения структуры регистра. Например, добавляем новое ключевое поле и оно в текущем состоянии пока еще просто пустое, т.к. перепроведения не было, а записи в этом регистре уже есть.

(8) У тебя после обновления они появились. Перенесли измерение в ресурс, а флажок удалять объекты снял. Вот и осталось и там и там.

(11) Так вижу ведь до того я трогал базу все идентично.
И записи есть и в Предприяии вижу записи и они разные

вот такие записи есть

https://ibb.co/hfrFyBj

(13) скрин ошибки лучше скинь

https://savepice.ru/full/2019/8/18/453bce6599abf704845a4f31c14f69d2-full.jpg.html

От отчет дает такую картину

https://savepice.ru/full/2019/8/18/790b23599e206c53e064ac6372a17684-full.jpg.html

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

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

кто мешает на копии убить все эти записи и после завершения обновления перепровести все эти упомянутые в регистре до обновления СФ ?

(18) основная конфа и конфа поставщика текущего релиза под номером основной (3.0.25.2) почти иентична. Я все сравнил и проверил!

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

(0) "Загрузить конфигурацию из файла" делал? Это плохая идея при косяках в обновлении - при этом у тебя существующее измерение могло удалиться, а новое, с таким же именем, могло добавиться. Так что при реструктуризации измерение очищается - вот тебе и неуникальные записи.

(22) Вооот о чем речь. Да точно возможно такое. Встречалось ведь мне ранее такая фигня.

И как быть. Мне же поставщика надо вернуть надо?

Вот думаю отдельно сначлаа обединить РС потом уже загружать.

и ты уже знаешь смысл этих всех записей? может они носят совершенно вспомогательный характер, который нужен в качестве протокола обменов с сервером ЭДО, например

(24) У нас в Казахстане замутили обмен счетов фактур через портал. Портал это государственный под налоговой службой. Бух с 1С отправяет свои СФ и получает статусы этих СФ. Они спокойны если ЭСФ принял сервер.
Кстати ЭСФ заменяет бумажный ДО.
Боюсь что я не могу спокойно удалить записи.

(23) Вариантов 2:
1. Через сравнение и объединение делать, потом ставить на поддержку (более безопасный для данных, но часть косяков обновления может остаться)
2. Выгрузить этот регистр в XML, очистить, принять изменения, загрузить регистр обратно (опасно для данных, т.к. подобная фигня могла произойти не только в регистре сведений, где это "выстрелило", но и в других данных, что может остаться незамеченным, зато вероятность дальнейших косяков с обновлением минимум)

(26) Все перепробовал.
Осталось только:
1. Удалить записи
2. Обновить конфу.
3. С копии перенести записи РС черезуниверсальную обраотку переноса данных в идентичной конфе.

(27) В таком случае надо будет сравнить данные во всех объектах, которые реструктуризировались до и после, чтобы убедиться, что не произошло очищения еще каких-то полей.

Удалил записи
При обновлении вышла ошибка уже по другому РС.
Там все удалил
ОПтом уже ошибка про третью РС.

Короче понятно что так я не победю..

(29) Тогда, наверное, стоит вернуться к конфигурации базы данных и начать сначала.

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

Вся трабла возникает потому что как я понял те объект которые при обновлении были сняты с поддержки.
Ну конеччно их не было в релизе 1.5.ххх

(31) Стоп. Сначала надо обновить, и только после обновления и обработки данных устранять косяки с конфигурацией поставщика. Не стоит эти 2 операции совмещать. Так непонятно, где лезут косяки, а где при обновлении должна быть реструктуризация.

(32) Сейчас проще полностью снять конфигурацию с поддержки и поставить на поддержку уже с текущим релизом конфигурации поставщика. Но сама проблема, скорее всего, в том, что было сравнение и объединение не с конфигурацией поставщика, а с конфигурацией из копии базы, в которой осуществлялась подготовка обновления.

а если я просто выгружу данные и залью в конфу  нормальную тиоповую.
Сработает ведь?

(25) // Боюсь что я не могу спокойно удалить записи.

Это нужно проверить наверняка, но у меня есть большие подозрения, что данный регистр служит для локального протокола обмена, чтоб сами процедуры конфига видели, что уже получено, в каком статусе и т.д. и не дергали ничего лишнего с сервера ЭДО.
Например, если база рухнет, то все эти СФ можно получить заново из обмена.