А в чем проблема?
Базу данных проблемы использующих ее приложений не волнуют. Она в порядке очереди будет обрабатывать поступающие запросы и выполнять их. При выполнении операций модификаций будет блокировать таблицу на изменение. Если будут параллельные запросы к данному ресурсу - положит их в очередь до завершение блокирующих операций, если параллельный запрос к незаблокированному ресурсу - запустит его выполнение не дожидаясь результатов предыдущих.
У вас таблица с identity. И одновременно поступило пятьсот insert-ов. Все они встанут в очередь. И будут отработаны (будут выполнены или нет из-за некорректности данных). Единственное но, если одно приложение послало подряд не в транзакции два insert-а, никто не гарантирует что у них idenitity поля после вставки будут отличаться на единицу.
И не стоит реализовывать в клиентской программе логику, например:
вы вставили значение в таблицу c identity ключом, получили его на клиенте и по привычке однопользовательской БД решили получить количество записей в таблице как значение idenity поля (при условии что данные из нее вы не удаляете) для дальнейших действий. Вот тут может не прокатить, так как между последней ВАШЕЙ операцией Insert может кто-то еще вставить данные и вы не учтете их в логике приложения.
P.S.
Также помните, если вам надо выполнить в базе данных подряд несколько логически связанных операций , то оформите их как транзакцию - логический неделимый блок операций. При этом операции будут выполнены подряд последовательно, результат будет:
-отражен в БД данных при условии , что все операции выполнены корректно
-полностью отменен и БД восстановит состояние, в котором она была до выполнения первой операции в транзакции при условии, что какое либо действие в транзакции не исполнилось.
Простой
Средний
