При загрузке из SQL не получается программно создавать справочники и документы. Пишет "номер не уникален". При этом в базе, с которой только что делалась копия нет такого. Что с этим делать?

(0) [Что с этим делать?]
- перезапустить рпхост
или
- обновить нумерацию глобальным методом

проблема решилась выгрузкой и загрузкой  dt

ОбновитьНумерациюОбъектов

(2) Это если база небольшая, а так да, ОбновитьНумерациюОбъектов самое лучшее решение.

(2) садись - кол (с)

(2) > проблема решилась выгрузкой и загрузкой  dt

Не лучшее решение. Возможно, что при загрузке через dt синхронизируется или обнуляется информация сервиса нумерации в кластере.

Проблема связана с тем, что сервис нумерации объектов предоставляется кластером серверов. Он хранит у себя последний выданный номер для каждого объекта (документа, справочника) в разрезе каждого префикса и владельца (для иерархических справочников с уникальностью в пределах владельца). То есть эта информация храниться не в базе, а в кластере. И при загрузке новой базы эта информация не синхронизируется - в базе выданы одни номера, а кластер хранит информацию о других последних номерах.
Например для документа Х для префикса "РОБП" храниться номер 0002. Ты загружаешь базу, где последний документ Х имеет номер РОБП-0003. Ты пытаешься создать новый документ Х. Сервис нумерации (который думает, что последний выданный номер 0002) выдаёт для него очередной номер - РОБП-0003. Возникает конфликт - документ с таким номером в базе есть.
Так же может возникнуть "дыра" в нумерации, если сервис содержит последний номер 0004, а в базе последний выданный - 0001. Сервис выдаст новому документу номер 0005 и образуется "дырка" - с 0002 по 0004.
В таком случае решение описано в (3) - метод ОбновитьНумерациюОбъектов. Но его надо применить к каждому объекту метаданных, где проблема возникла.

(6)
Вот попробуй угадай все объекты, где такое возникло. А тут раз и все.

(6)(7) Да можно и для всех разом, без указания параметра: ОбновитьНумерациюОбъектов()

(6) Бага, однако.

ОбновитьНумерациюОбъектов() - куда это вставить чтобы сработало?

(9) Какая бага?... Всё логично и правильно. Кто же продуктивные базы перезаливает в реальной жизни?

(8) > можно и для всех разом

Я этого не знал. Всегда делал по мере возникновения проблемы для конкретного объекта.

(10) Сделай внешнюю обработку. Там выполни этот метод.

(11) Бага в том, что обновление нумерации не делается автоматом.

(14) > обновление нумерации не делается автоматом

Как ты себе это представляешь? Откуда сервер 1С узнает что на сервере СУБД базу перезалили и надо что-то там обновлять?

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

(15) Сервер должен надеяться и обновлять каждые 5 минут на всякий случай))

(16) > если бы он проверял уникальный отпечаток файла базы

Как часто он должен это делать?
Как изменяется отпечаток (я просто не владею темой)? Он меняется только при перезаливке базы или подмене файла? А при обычной записи данных в базу отпечаток не меняется?

(17) Обновлять каждый 5 минут что? Все хранящиеся в сервисе нумерации номера?
Боюсь, что это может сказаться на производительности. В высоко нагруженных системах уж точно.

ИМХО, в этом вопросе единственная претензия к 1С, что они не сделали какой-то стандартной обработки. По аналогии с "Управление итогами", "Активные пользователи" и пр. из раздела "Стандартные" меню "Все функции", которые на самом деле являются обычными обработками, написанными на встроенном языке, зашитыми в платформу, и которые можно выгрузить в файл обработки.

То есть загрузил я базу на СУБД, открыл её в предприятии и через "Все функции" - "Стандартные" вызвал обработку обновления нумерации, где можно было бы обновить нумерацию для всех объектов или выборочно.

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

(21) > и менять его, например, раз в минуту

Опять та же проблема - с какой частотой это делать? За одну минуту можно записать несколько тысяч объектов одного вида. Хотя для рассинхронизации номеров достаточно всего одного документа.
Делать это после каждой операции - сомнительное решение.
Неминуемо возникнут блокировки на ожидании. Огромное количество операций выполняется параллельно и в разные таблицы БД, не мешая друг другу, каждый в своей транзакции. Один документ записывается мгновенно, а другой проводится может несколько минут. А тут единый для всех идентификатор и все будут ждать когда долго проводящийся документ запишется. Выносить же обновление идентификатора за рамки транзакции рано или поздно приведёт к рассинхронизации.

Ну и проверка этого идентификатора. Как часто её делать? И кто даст гарантию, что в выбранном интервале не изменилось состояние нумераторов?

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

(20) Единственная претензия к 1С, что до определенного релиза платформы при разворачивании бекапа SQL проблемы с нумерацией не возникало...

(22) "опять таки вопрос блокировок этих таблиц при параллельной записи большого количества объектов одного вида" // Так при такой записи и сервис нумерации тоже "блокируется" каждым запросом на выдачу очередного номера

Просто видимо сервис нумерации, сидящий в оперативной памяти, обрабатывает обращения к нему быстрее, нежели обращение к какой-нибудь служебной табличке СУБД

(22) За 1 минуту вы сможете базу подменить так, чтобы незаметно было?

(22) Думаю, достаточно считать все нумераторы в БД не актуальными при входе первого пользователя. Сомневаюсь, что найдётся умник восстанавливающий базу при работающих пользователях.

(15) вообще типовые это умеют определять, и там форма вопроса есть типа - это копия или базу перенесли, если говоришь - копия отключаются обмены...

логично это туда же встроить

(28) Механизм определения перемещения / восстановления БД, реализованный в БСП, конечно же не работает во всех случаях.
Проще говоря, базу средствами СУБД можно восстановить так, что никто ничего не заметит.

(29) механизм запоминает имя базы субд, при переносе имя базы меняется и все отлично распознается,

я этот механизм придумал лет 10 назад, а потом его "придумали" в 1с с небольшими изменениями....

(30) единственное чего не сперли у меня - я в название главного окна добавлял "копия"

(30) Во-первых, это ты описываешь простой случай, который более-менее легко диагностируется.
Во-вторых, "механизм запоминает имя базы субд" - это ты в очередной раз "дикуешь".
В-третьих, ты в (28) пишешь "типовые _это_ умеют определять", отвечая на (15), в котором вроде понятным языком написано "базу перезалили", что вроде однозначно трактуется как "имя базы ни в кластере 1С, ни в СУБД не изменилось".

базу перезалили от куда?

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

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

пошевели моззгом...

Абсолютно не важно, какое имя у базы в СУБД. Как Я уже говорил выше, "базу перезалили" = "у базы не изменилось ни имя в кластере, ни имя в СУБД".
И конечно же вторая часть твоего поста - опять, замечу - неверна. Как тебе не пришел в голову вариант, что в некую тестовую базу залили очередной свежий снимок рабочей базы (с более свежими данными и с заведомо большими номерами, чем нумератор выдавал этой базе до заливки)?

(34) балин....

есть база рабочая, кластер 1 имя базы 1, в этой базе в константе записано 1.1

при загрузке в тестовый кластер 2 в тестовую базу 2 бекапа с рабочей, мы в константе тестовой получим 1.1, при старте пользака идет проверка которая говорит это кластер 2 база 2 а в константе 1.1 - не порядок, надо спросить пользака, наверно это копию перенесли...

1. Зачем ты описал механизм, реализованный в БСП, не ясно.
2. Уже отказываешься от "механизм запоминает имя базы субд" в (30), заменив это на имя базы в кластере, правильно?

(36) де факто и у меня и в бсп хранится урезаная строка подключения...

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

Вроде выше все довольно ясно сказано. Ситуация тоже описана.

(38) не виду ничего конкретного, только общее бла-бла-бла

Могу только рекомендовать перечитать сообщения

(40) понятно, слился...

Эх, не о том вы спорите. Автор залил SQL бэкап в существующую базу 1С. Речь о том, что разработчикам хватило ума реализовать функционал и спросить за копию, но не пришло в голову принудительно обновить нумерацию (да и не только это).

(42) Так у автора про копию ничего и не спрашивалось

Угу. А ещё автор не озвучил ни платформу, ни конфигурацию. А если, вдруг, у него старая конфа и платформа - то ваш спор - "не в тему" :)

Пока хороший вариант решения описан в (27) - он значительно сокращает вероятность возниконвения таких веток, как текущая

(45) Может не стоит придумывать "защиту от дурака" - это бесперспективно? :)

(офф) Мне эти диалоги ветки навеяли анекдот "Группа опытных археологов во время раскопок нашла группу неопытных."(цы)

(34) Прям вот так при работающих пользователях взяли и перезалили?

(46) защиту от дурака ОБЯЗАТЕЛЬНО нужно придумывать

(47) Конечно. Какие проблемы в скуле соединения прибить?

(46) Так это не от дурака - разворачивание базы средствами СУБД в уже зарегистрированную в кластере инфобазу - далеко нередкий сценарий

(33) > базу перезалили от куда?

Простейший пример:
База BD1. Вдруг решили восстановить из копии по состоянию "на час назад". Имя этой резервной копии BD1.

Не поменялось ровным счетом ничего. Механизм БСП никак не определит что что-то изменилось. Имя базы прежнее, имя сервера и кластера прежнее.

БСП-шный механизм подходит исключительно для случая развёртывания копии базы с другим именем или на другом сервере (кластере серверов). Собственно говоря для этого он и придумывался.

(26) > За 1 минуту вы сможете базу подменить так, чтобы незаметно было?

Если базюка маленькая, то легко.

(27) > считать все нумераторы в БД не актуальными при входе первого пользователя.

Интересный вариант. Если бы только не глюки кластера, в котором бывают зависшие сеансы пользователей.
На СУБД выводишь базу в офлайн, загружаешь в неё копию, включаешь олайн, и .... первого пользователя нет, т.к. в кластере есть висящий сеанс, который можно прибить только остановив кластер и прибив папку scntx.... в папке реестра кластера серверов 1С.

(42) > не пришло в голову принудительно обновить нумерацию

Так в том и вопрос - как определить момент для "обновить нумерацию". Что должно быть признаком необходимости сделать это?

Все озвученные тут варианты нельзя назвать идеальными и однозначно и гарантированно решающими проблему.
ИМХО, эта проблема относится к разряду тех, которые лучше не решать вовсе (оставив только костыль в виде метода платформы ОбновитьНумерациюОбъектов), чем пытаться придумать какие-то другие костыли, которые будут работать от случая к случаю - то сработало, то нет, то сработало, когда не нужно.

(24) > при такой записи и сервис нумерации тоже "блокируется" каждым запросом на выдачу очередного номера

Время блокировки сервиса значительно меньше. У него своя база, свои транзакции, никак не связанные с транзакциями СУБД. В базе транзакция записи и проведения документа могла висеть несколько минут, а в сервисе транзакция отработала почти мгновенно - запрос на выдачу следующего свободного и запись нового занятого номера.

Хотя для подобных рассуждений надо точнее знать - как устроен сервис нумерации...

(51) если продакт откатили "на час назад" то нумерация от этого не изменится


смотри
в 13часов был номер 120
в 14часов был номер 150

откатились с 14 часовой на 13 часовую, нумерация спокойно пойдет далше с номера 151, никаких проблемм нет...

(56) В данном примере, на первый взгляд,  кроме как "пропуска" номеров, другого негатива не наблюдается. Просто пример не тот. Предлагаю другой пример (на основе твоего):
- в базе удалили документы начиная с 150 по 120 включительно и после этого "откатились". Имхо, возникнет ошибка автора ветки (о дублировании номера 120).

(49) И сервер 1С предприятия этого не заметит? Ну вот и бага - у него соединения прибили, а он ни сном, ни духом. Дело-то житейское...

(52) Ну значит платформа пусть ставит смену каждую секунду на маленькой базе.

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

кстати на основе этой ветки я себе в сервесной базе скрипты сделаю для запуска после копирования,

в скрипте сделаю
1. обновление нумерации
2. изменение заголовка
3. отключение обменов и почты

может еще чего...

в целом ветка для меня полезная

(58) А на что повлияет, заметит он это или не заметит? Допустим, он заметил. Что предлагаешь в этом случае делать?

(56) > если продакт откатили "на час назад"...

Усложним задачу. Откатили на час назад от часа Х, а потом решили откатиться на копию на полчаса от часа Х (то есть более позднюю). В промежутке между этими событиями обновили сервис нумерации.

Короче говоря. Повторюсь. Все предложенные варианты не дают однозначной 100%-ной гарантии решения проблемы. 99% - да, но всегда найдётся 1% каких-нибудь исключений.

(63) Вроде обновление сервиса нумерации после перезаливки БД дает 100% гарантию, что проблем с нумерацией не возникнет

(60) Нет, ну почему "экзотика"? Обычный вариант, один из многих, настройки штатного механизма автонумерации в конфигурации. Судя по всему, автор на него и нарвался.

(63) Вот и я об том же, когда говорил о бесполезности "защиты от дурака" когда речь об специалистах идёт - жизнь подкидывает много вариантов. "Дураков не становится больше - они просто становятся более активные" ;)

PS: и да, "защита от дурака" - это только термин такой, не принимайте близко к сердцу и на свой счет.

(62) Очистить все кешированные данные.