Почтение, коллеги!

Замечено странное. Имею БД 8.2.13.219, MS SQL

Открываю БД, создаю доки, они "автонумеруются". Условно, начинаю с
97,98... последняя позиция номера - 100.
Затме...удаляю БД НА СЕРВЕРЕ MS SQL. Делаю восстановление до состояния
нумератора 96. Создаю док. запись, и ...получаю автономер = 101.
Иллюзион, блин!

(0) а если удалить базу на сервере 1С и создать заново с другим именем ?

ну проверь.
удали кэш - какой номер выдаст?

Делаю, делаю - терпение :)

(2) чистить кэш на сервере 1С? Сейчас проверю удаление экземпляра ИБ на сервере 1с. почти эквивалентно.

Проверил. В этом случае, удаление через консоль сервера 1С,
нумерация корректная. Грабельки, однако :) И нам они в лоб треснули :) Всё, всё возможное делать только через
консоль-святыню!

ЗЫ: блин.

Что, писать в штаб? Или скажут - сам дурак, чти штатный тулкит? :)

что значит "Делаю восстановление до состояния
нумератора 96"?

(5) а что собственно ты ждёшь,
что отдел разработки экстренно изменит архитектуру и будет хранить всё на сиквеле ?

попробуй
журналу туда(на сиквел) давно пора

(0)это нормально. за нумерацию отвечает сервер 1С, а в языке есть команды для управлением нумерацией, а в типовых есть обработка

(6) восстанавливаю состояние БД на момент до ввода документов и движения нумератора.

(7) ну, вообще, журнал, который лежит в БД, в случае
проблем с доступом к БД будет, очевидно, неработоспособен.
Так что, может быть, есть и свои плюсы логгирования во
внешний мир ФС..

(8) моё мнение - это не слишком нормально, это потенциальные проблемы, хотя вероятно в документации и есть замечание болдом: невер удалять ё датабейз на SQL-сервер!!!
Юз онли admin console!!!
Тогда ещё можно... проглотить. Впрочем, все мы в желто-красной подводной лодке...

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

(9)[моё мнение - это не слишком нормально]
мы не согласны