Уважаемые,
подскажите пожалуйста, что может быть причиной того (и как лечить), что
при копировании SQL базы 1С в копии при выписке некоторых документов и и создании элементов справочников выдаются какие-то старые номера. В результате получаю "номер не уникальный". В тестовой базе просто проставляю "правильный" номер руками и дальше все идет нормально.
Но не хотелось бы получить неожиданно подобную проблему в рабочей базе. Куда смотреть?
Спасибо.

пожалуйста.
у вас нетиповая конфа, где нумерацию втихаря делаете..
так, какая у вас конфа, и какие изменения?

После копирования рабочей базы в тестовую выполните в ней (в тестовой) метод ОбновитьНумерациюОбъектов().

(2) эээ... стотыщ раз копировал.. не выполнял.. что за на метод??

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

Возможно при обновлении конфы в какой-то момент слетел нумератор. Было год назад, когда добавили префикс РИБ принудительно в номер  в 1с, даже если РИБ не было и номера обрезались по последнему символу.

(2) Спасибо, попробую.
Но хотелось бы понять суть проблемы, почему так происходит.

(5) Проблема проявляется только на скопированной базе, в рабочей базе такого не замечено.

(7) Если база файловая - там еще и висячих строк можно огрести. Копировал просто файлом, выгрузкой через бэк или через dt?

(7) База sql. Копирую не я, а админ. Насколько я знаю, поднимает из ночного бэкапа. Но точно процедуру сейчас не скажу.

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

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

(9) Ясн загрузи его бэк .  И сделай там тестирование целостности БЕЗ исправления. Просто ошибки посмотреть. Такое бывает при бэкэпе через SQL.

(11) Сбоят транзакции ИМХО. Надо смотреть конкретный случай, в конкретной конфигурации.

(10) Кстати да может из-за очистки кэша сработать событие на установку нового номера, которое раньше не работало из-за залипшего кэша.

(13) Есть такой момент: "кривые" номера берутся откуда-то отдаленно от текущих номеров. Сейчас подумалось, что тестовая база не обновлялась пару месяцев, и возможно проблема в том, что остаются косяки именно от старой тестовой копии...

(3) СП: "Выполняет обновление номеров в соответствии с номерами, записанными в базе данных. После вызова данного метода все выданные, но незаписанные номера, становятся невалидными т.к. не гарантируется их уникальность. Данный метод разрешено вызывать только администратору системы."

У нас штук 200 всяких тестовых баз. Минимум 10 раз в день выполняется копирование из продуктива в тестовые базы средствами СУБД.
Примерно раз в месяц кто-то ловит такую ошибку.

тоже есть такая ошибка. Лечится перенумерацией базы

(9) скорее всего "поднимает" бэкап в подключенную базу скуля, которая, в свою очередь, подключена к серверу1С,
на сервере1С есть серверный кэш, в том числе и по нумерации, вот он может подкидывать подлянки при таком восстановлении