Для меня это похоже на условия гонки. Два соединения одновременно проверяют наличие следующего доступного идентификатора, получают один и тот же, а затем происходит сбой вставки второго. Почему вы не используете поле идентификации для создания PK, если это суррогатный ключ?
Если у вас есть PK, который является естественным ключом, то нарушение - это хорошо, у вас есть два пользователя, которые пытаются вставить одну и ту же запись, которая вам не нужна. Я попытался бы изящно провалить это, хотя, с ошибкой, которая говорит, что кто-то еще создал ту же самую запись. А затем спросите, хотят ли они обновить его после загрузки новых значений на их экран. Я не уверен, что хотел бы, чтобы он был настроен так, чтобы данные автоматически обновлялись вторым человеком, и они не видели, что первый человек поместил в базу данных.
Кроме того, это может указывать на то, что ваш естественный ключ не так уникален, как вы думаете. Не знаете, что делает это приложение, но насколько вероятно, что два человека захотят работать с одними и теми же данными одновременно? Поэтому, если ваш естественный ключ был чем-то вроде названия компании, имейте в виду, что они не гарантированно являются уникальными, и у вас могут быть пользователи, которые перезаписывают хорошие данные для одной компании данными уже для другой компании. Я обнаружил, что в жизни действительно очень мало действительно уникальных, никогда не меняющихся естественных ключей. Поэтому, если ваш естественный ключ действительно не уникален, у вас уже могут быть неверные данные, а нарушения PK - это всего лишь признак другой проблемы, а не реальной проблемы.