Забавно, но попытавшись перейти на поддерживающую SMP архитектуру Classic Server, ни один клиент не мог подключиться к серверу, а в лог Firebird сыпались ошибки:
INET/inet_error: select in packet_receive errno = 10038

Виной оказался NOD32 IMON. И его мало просто отключить, нужно обязательно добавить исключение для fb_inet_server.exe из проверки. Это решает проблему.

Есть и другие причины такой проблемы:
http://www.firebirdfaq.org/faq4/

Жесть это, а не СУБД. Значительно стала строже к синтаксису. Но хотя-бы честно говорит, в чем ошибка. В общем, много-много запросов, которые работали на 1.5.0, теперь не работают только потому что были написаны не очень точно. Теперь оно спрашивает, а из какой именно таблицы надо выбирать поле, и тыкает, что ты юзаешь имя таблицы вместо псевдонима. Ищу еще приколы. Весело.

Судя по всему, в этом посте я столкнулся с уже исправленным багом СУБД Firebird. Поэтому скорее всего обновлюсь. Такой вывод я сделал из вот этого вот ответа на пост и вот этого вот багрепорта

UPD: Так и не обновился. В последний момент обнаружилась странная несовместимость клиентских приложений с новым сервером. Видимо, дело где-то в кривых компонентах доступа к данным..

Так как выпадает случай снова потрахаться с этой СУБД, задался вопросом, в очередной раз глядя на "attempt to store duplicate value (visible to active transactions) in unique index" (попытка записать повторяющееся значение (видимое для активных транзакций)).

Есть две ситуации:
1. У нас есть одна транзакция и мы в ней делаем INSERT INTO (просто вставку записи) в некоторую таблицу и пишем NULL (пусто) в некоторое поле, по которому у нас есть UNIQUE INDEX (уникальный индекс). У нас все получается, потому что Firebird версии 1.5 и выше разрешает записывать много-много NULL в такие поля. (конечно, если нет других ограничений).
2. У нас есть две параллельных транзакции и мы в них делаем INSERT INTO в некоторую таблицу и пишем NULL в некоторое поле, по которому у нас есть UNIQUE INDEX. И у нас ну нихрена не получается. Потому что "attempt to store duplicate value (visible to active transactions) in unique index". А вот баг это или нет - я тут уже ХЗ и подумываю написать "куда надо" чтобы выяснить.

http://firebirdsql.org/manual/ru/generatorguide-basics-ru.html

Ну вот не понимаю я, как работающий вне механизма транзакций генератор может вызывать lock conflict on no wait transaction... =(

UPD: Дело, конечно же, не в генераторе. А в другом месте и уже в другом дедлоке...