OlegROAМного лет работал (и работаю) с десктопными СУБДТам тоже НИКОГДА нельзя полагаться на max(id). Всё делается через вспомогательную таблицу счётчиков, запись которой сначала блокируется, затем увеличивается значение соотв. поля в ней и только после этого зхапись высвобождается, а полученное новое значение возвращается "потребителю".
Если у вас много лет получение нового Id идёт через max(...) и не случалось "странных дубликатов", то... всем бы так везло!

OlegROAТаблоидпропущено...Там тоже НИКОГДА нельзя полагаться на max(id).Можно, можно! Естественно, только в режиме полной блокировки рабочей таблицы.1) Залочивание всей таблицы, даже на короткое время, будет заклинивать ваш "перформанс", юзера непременно будут видеть это - и те, кто пытается её залочить, но должен ждать высвобождения, и те, кто ждут, пока её высвободит тот, кто определяет новый ИДшник.
В dBase-приложениях это проявляется уже на 20...30 юзерах, если они действительно что-то делают
2) вы, конечно же, будете определять max(id) по индексу (не делать же переход на последнюю запись! там ведь может - в результате всяких перетряхиваний таблицы - оказаться далеко не самый последний по значению Id) - ? И что будете делать при сломанном индексе (а это вполне обычная для десктопов вещь) ?

Гаджимурадов РустамРассуждать с т.з. сломанного индекса - это что-то новое в современной проктологии.Да тут не проктология, тут хуже: когда в xBase ломаются индексы, то происходит это очень тихо. Никаких сообщений в "логе" (которого вообще нет :)). И только через некоторое время будет вываливаться сообщение 'index corrupted', когда в таблицу уже натолкано энное кол-во некорректных данных (дублей, например).