Но, готов забить, что план выполнения будет один и тот же :)

Shocker.Pro,

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

По сути одно и то же. И там и там просто крайняя запись в индексе выбирается.

Ну, я имел в виду обычный целый автоинк для искуственного ключа. В фокспро identity() просто не было от слова не было вообще и решение со спецтаблицей-счетчиком оно как раз и считалось самым правильным (и, по сути identtity примерно так и работает, только там этот счетчик запрятан). А с выборкой максимального значения это вот как раз и есть кривизна полная. Я выбрал значение 167, а пока я его увеличивал на 1 и заполнял остальные поля, то ты за это время тоже выбрал 167 (поскольку я свою запись еще не сохранил), и привет рейс кондишен.

Ну, при всем уважении к 1с, подозреваю, что то, как она работает это, по крайней мере, не всегда, образец для подражания :) Я, например, позвонил уже своему Боссу и "Иван ван Ваныч", у документа номер вот такой-то, а тут выясняется, что я его сохранить под этим номером не могу, потому что какой-то выскочка меня опередил. И, потом еще, у меня такое подозрение, что если сохранение с проверкой проводить под read committed, то все-таки могут возникать "пропуски" из-за "фантомных записей", а если выставить уровень "repeatable read" то может быть дедлок.