Я понимаю, что тема изъезжена вдоль и поперек, но, думаю здесь нечто другое.

Ситуация. Звонок от оператора: не сохраняется документ, номер не уникальный. Зная точно, что префикс не сбит, рабочие даты выставлены, лезу в журнал регистрации. Вижу:

16:54:18 Оператор1 Создан док. № пн-61313
...
16:55:04 Оператор2 Создан док. № пн-61314
16:55:07 Оператор3 Создан док. № пн-61313 (идет сразу за предыдущей, прим. автора)

Что может быть? Почему "слетел" контроль за последним номером? 1sdnlock.dbf ? Кодировка ? Системные проблемы?

База дбф, ос 2008R2 sp1 64, rdp.

(0) слёт индексов

*.cdx удали и зайди монопольно
и будет тебе счастье (с)

(1) за все время ни разу такого не было. База переиндексируется ночью. А тут такая ошибка. Предположительно, второй день подряд.

+(3) ну, индексы-то конечно слетали...

(3) В смысле - два раза за два дня?!
Что-то тут не то. Слишком часто для такого редкого сбоя. А там никакого кэширования, случайно, нет?

это ОНИ....

А каковы размеры самых больших dbf-cdx ?
И у Оператор1 по каким-либо причинам случайно не вылетела 1С-ина сразу после создания док. № пн-61313 ?

Хитросракий юзер подменил префикс

(6)Лунтик с Пу?

(5) ага, два раза за два дня. У меня тоже первая мысль была про кэш: админ говорит, только на уровне рейда.
(7) Размеры далеки от критических, свежая база. Вылеты проверю. По идее, тут оба должны были вылететь: и первый и второй.
(8) см. (0), ж.р. (префикс не меняли), а во-вторых, номер документа для редактирования закрыт.

Про хитросракого юзера уже писали.

Можно подумать в другом направлении: Если ошибка="номер не уникальный" Тогда НомерДок+1 както так...