этот регистр «слепой» — непонятно действительно ли данные содержат дубли и что такое в данном случае дубли
в этом регистре значительное количество записей — более 7000
Кроме того, нет возможности пометить на удаление или удалить такие записи непосредственно из регистра
Для прояснения ситуации направила разработчику запрос:
Что программа понимает как дубли? Если сочетание Тип владельца + Наименование, показанное в поле Владелец данных, то почему позволяется записывать такие данные?
Пользовался ранее https://infostart.ru/1c/articles/1120161/#, но она устарела, т.к. службы запускаются через systemctl, да и сами службы слегка изменились.
Возможно, где-то на ИТС уже есть нужная инструкция, но мне не попалась.
Мы исследуем проблему долгого выполнения запросов PostgreSQL при использовании конструкции VALUES: когда она возникает, как на нее можно повлиять, а главное, почему ее продуманная отработка важна для более быстрого функционирования решений на базе 1С
В данной статье мы рассмотрим, как работает механизм временных таблиц на postgres на платформе 8.3.23 и что изменилось в нем при добавлении новых возможностей в платформе 8.3.25.
А также на примере покажу, как понимание работы платформы позволяет оптимизировать СУБД для работы с 1С.
CDC - очень мощный механизм, который можно использовать во многих сценариях, возможность развернуть его в Docker показывает простоту и лёгкость данной технологии.
Анализ и решение ошибок СУБД.
Во время реиндексации базы
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Не удалось найти объект "ИмяБазы.dbo._RefSInf21806", так как он не существует, или отсутствуют разрешения.
Во время проверки целостности
Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта "dbo._RefSInf21806".
Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще, как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей-то лабораторной работы? Статья адресована прежде всего специалистам 1С, избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.
Система обеспечивает контроль уникальности записей, хранящихся в регистре сведений. Таким образом, в регистре сведений не может находиться двух одинаковых записей. Одинаковыми считаются записи, у которых совпадает ключ записи. Ключ записи формируется системой автоматически, на основании значений, содержащихся в полях записи, и зависит от вида регистра сведений.
В общем случае в формировании ключа записи будут участвовать значения регистратора, периода и значения измерений. Таким образом, например, в непериодическом регистре сведений Цены товаров с независимым режимом записи не может существовать двух записей о розничной цене конфет ассорти. Точно так же, как в периодическом регистре сведений Цены товаров, подчиненном регистратору, не может существовать двух записей о розничной цене конфет ассорти, внесенных одной и той же датой, одним и тем же документом Изменение цен товаров.
Для файловой базы одна из причин, например - это "битые" записи во внутренней таблице. Буквально вчера столкнулся с такой же ситуацией при обновлении 1С:Розница в отношении РС "ФискальныеОперации". При тестировании на логическую целостность платформа выдала сообщение, что файл базы данных поврежден. В результате тестирования утилитой chdbfl в регистре было "потеряно" 4 записи, после чего обновление прошло без проблем.
Всем добрый день. в моем случае тестирование и исправление не выявляло ошибок. Поиск дублей не давал результатов. Обращаю внимание, что публикация про регистр сведений ДвоичныеДанныеФайлов. а он весьма специфичен!
(4) Добрый день. Если ошибка по регистру Двоичные данные файлов, то, к сожалению, я не нашла вариантов, кроме изменения конфигурации. С другими регистрами легче. Там можно найти дубли и сделать их НЕ дублями. Может помочь обработка из публикации https://infostart.ru/public/538465/.
(6) Тогда увы..
могу, правда, процитировать ответ разработчиков - см пункт 2:
1С Линия консультации <v8@1c.ru> Тема: Записи регистра сведений стали неуникальными: ДвоичныеДанныеФайлов (#HL-127544)
26 февраля 2020, 15:21
Добрый день,
1. Воспользуйтесь поиском и удалением дублей в меню Администрирование - Обслуживание
или
2.Попробуйте выполнить Архивация электронных документов 1С-Отчетности и хранение в томах
как описано на ИТС
https://its.1c.ru/db/elreps#content:59:hdoc и после этого удалить все записи из этого регистра.
Предварительно сделайте резервную копию.
С уважением,
отдел тех. поддержки фирмы "1С"
Тел. (495) 956-11-81 (линия ИТС)
(495) 688-10-01 (базовые версии)
(7) Мария, огромное вас спасибо, всё получилось!!!
Перенесла файлы на диск (и клиенту надеюсь хорошо - значительно меньше теперь база весит и регистр стал пустым), после этого выполнила сжатие таблиц ИБ и ошибка исчезла.
Добрый день!
Натолкнулся на такую же ошибку, неделю назад, при обновлении (правда совсем "седой" базы релиза 64). Не помог ни один вариант, ни с форумов, ни с вашей статьи :)
Решение получилось "не научным "тыком"" - запустил обновление с платформы 2018 года (8.12....) - обновление прошло абсолютно в штатном режиме (База вскрытая)
Вдруг кому-то тоже поможет)
Добрый день!
Спасибо за идею снять флаг объединения с этого объекта, это действительно помогло. До этого при возникновении такой ошибки я просто очищал весь регистр, что в принципе не совсем красиво.
Но вот что я при этом увидел в подробностях объединения.
Оно фактически Измерение Файл удаляет и одновременно создает новое измерение с тем же именем. Тем самым это измерение у всех записей регистра становится пустое, поэтому после объединения они и оказываются не уникальными. Поэтому поиск дублирующих записей ДО обновления в этой ситуации не имеет смысла.
Почему оно так делает - непонятно, могу только уточнить, что подобная ошибка у меня возникает только при обновлениях очень древних баз, некогда сконвертированных еще из БП 2.0
Судя по всему теперь флаг объединения с этого регистра придется снимать при каждом очередном обновлении.
Чтобы эта проблема не повторялось для двоичных данных нужно перед тем, как изменять ОпределяемыйТип нужно убрать данные этого типа из регистра сведений ДвоичныеДанные, предварительно переместив их в другой регистр.
&НаСервереБезКонтекста
Процедура УстановитьДвоичныеДанныеНаСервере(Файл)
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ДвоичныеДанныеФайлов.Файл КАК Файл,
| ДвоичныеДанныеФайлов.ДвоичныеДанныеФайла КАК ДвоичныеДанныеФайла
|ИЗ
| РегистрСведений.ДвоичныеДанныеФайлов КАК ДвоичныеДанныеФайлов
|ГДЕ
| ДвоичныеДанныеФайлов.Файл = &Файл";
Запрос.УстановитьПараметр("Файл", Файл);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
МенеджерЗаписи = РегистрыСведений.Заказ_ДвоичныеДанныеФайлов.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Файл = Файл;
МенеджерЗаписи.ДвоичныеДанныеФайла = Выборка.ДвоичныеДанныеФайла;
МенеджерЗаписи.Записать();
КонецЦикла;
КонецПроцедуры
Показать
Где Файл это элемент справочника удаляемого типа.
Потом удалить:
&НаСервереБезКонтекста
Процедура УдалитьДвоичныеДанныеНаСервере()
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ДвоичныеДанныеФайлов.Файл КАК Файл,
| ДвоичныеДанныеФайлов.ДвоичныеДанныеФайла КАК ДвоичныеДанныеФайла
|ИЗ
| РегистрСведений.ДвоичныеДанныеФайлов КАК ДвоичныеДанныеФайлов
|ГДЕ
| ТИПЗНАЧЕНИЯ(ДвоичныеДанныеФайлов.Файл) = ТИП(Справочник.бит_мат_ЗаказНаТехникуПрисоединенныеФайлы)";
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
НаборЗаписей = РегистрыСведений.ДвоичныеДанныеФайлов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Файл.Установить(Выборка.Файл);
НаборЗаписей.Записать();
КонецЦикла;
КонецПроцедуры
Натолкнулся при обновлении УТ до версии УТ 11.4.13.47. Проблема была с регистрами "двоичные данные файлов" и "файлы в рабочем каталоге". Решил по другому. Сделал выгрузку этих регистров в файл с помощью "Универсальной выгрузки загрузки в XML" из комплекта обработок ИТС. Очистил регистры, завершил обновление, загрузил данные обратно с помощью той же обработки.
Оставлю это здесь, может кому поможет. Скорее всего ошибка не в дублях, а в том, что вы добавляли в определяемые типы ПрисоединенныйФайлОбъект и др. свои объекты, проверьте
(16)
Хорошая мысль. Возможно при обновлении в определяемом типе ПрисоединенныйФайл или ВладелецПрисоединенныхФайлов затираются добавленные самостоятельно типы (если делали присоединяемые файлы к справочнику или документу).
Так как регистр сведений ДвоичныеДанныеФайлов (или НаличиеФайлов) имеет измерение Файл (или ОбъектСФайлами) измененного определяемого типа, то содержимое некоторых измерений затрется (например, тех самых самостоятельно добавленных владельцев присоединенных файлов). Соответственно будут образовываться дубли с одинаковыми "пустыми" измерениями в результате обновления, которых не было до.
(20) user708045_vantaqa: (5) Добрый день. Подскажите пожалуйста, а что конкретно вы изменяли в конфигурации?
РЕШЕНИЕ (подробно - см публикацию):
Для регистра сведений ДвоичныеДанныеФайлов установить режим Редактируется с сохранением поддержки
Добавить Ресурс (добавила Ресурс1, строка)
У меня также возникла проблема с этим регистром сведений при обновлении древней конфигурации УТ. Я решил проблему стандартными средствами УТ.
1. В настройках УТ изменил способ хранения файлом на тома диска. Перенес все файлы в том на диске стандартной процедурой УТ.
2. Очистил этот регистр сведений.
3. Обновил конфигурацию.
4. Перенес все файлы из томов обратно в информационную базу и вернул настройки УТ обратно.
подобная ошибка возникла при обновлении Бухгалтерии предприятия на 3.0.127.49
запросом не удалось найти дубли
обработкой //infostart.ru/public/538465/ тоже не нашлось дублей
добавлял измерение, затем ресурс, тоже не помогло
пришлось очистить регистр, обновить, затем восстановить записи
Была похожая проблема.
Обновлял базу. Вроде должна быть типовой, но сразу пошло в сравнение и показало отличие объектов, причем там справки, еще что-то несущественное и если посмотреть в сравнении - то в реальности не отличается. ну и .. с ним думаю, ставлю на поддержку, а мне вот такой же привет про регистр двоичных данных и про записи с измерениями одинаковыми. Ну и понятное дело - не ставит на поддержку.
в общем помогло вот что. включил хранение томов снаружи базы. выгрузил все туда, и осталось две записи. их удалил с помощью ИР, после чего загрузил данные обратно и отключил хранение снаружи, вот после этого прошло нормально. а никакое ТИИ и лечение не давали ничего
Мне помогло лишь манипулирование с типом ОпределяемыйТип. Я обновлял нетиповую конфу, и в этот тип, который у меня уже ранее редактировался, добавлялась ссылка на какой-то новый справочник.
Что я сделал? Снял галку в сопоставлении с обновлений этих типов (кажется четыре разных было, два со словом ПрисоединяемыеФайлы и два со словом ВладелецПрисоединяемыхФайлов).
Нажал бочку после этого. Отлично, кнопка "Применить" появилась. Нажал бочку.
А уже потом вручную добавил те типы ссылок в этот определяемый тип, которые изначально нужно было.
И всё прекрасно работает.