В клиентском приложении срабатывет исключение DUP_VAL_ON_INDEX из пакитжа, а там всег лишь INSERT ровно одной записи.
Никогда не анализировал индексы. Подскажите, оракл говорит о дубликатах при попытке вставки? Тогда не получается имитировать исключение. К примеру, создаю таблицу и индекс. Поля K и B_ID оба целые и не уникальные:

В реале в таблице несколько индексов, а этот с такими св-вами:
UNIQUE
VALID
index_type= FUNCTION-BASED NORMAL
funcidx_status= ENABLED
column_expression= DECODE("K",1,"K"+"B_ID")

Не получается ловушка на DUP_VAL_ON_INDEX

Elic, это было предположение.

Ах, зараза, забыл написать, что сначала есть строка
insert into MY_TTT (id,k,b_id) VALUES (1,1,355434);

И я подумал, что 1 + 355434 == 0+ 355435.
Потому что в реале это единственный b_id из 4-х, у которого есть соседние b_id, вот на него и подозрение.

[quot exp98]И я подумал, что 1 + 355434 == 0+ 355435 [quot] а оно оказывается ==NULL ? но таких с NULL полно. А что ещё может дать исключение?

constraint k in {0, 1}
b_id - их конкретно 4 шт, сильно разных, и только 355434 ещё имеется, у остальных соседей нет.

MaximaXXL, спасибо за участие в проблеме. Направление поиска переместилось, я не знал, что decode() в индексе по умолчанию даёт NULL, ну и документация по индексам помогла.

Да, Именно так я и понимаю индексное выражение.
Искал я не отсутстввующую запись, а ту, к-рая могла мешать новой, выяснилось, что не совсем "ту" искал, но всё равно не нашёл.

К+Bid - ради бизнес-правила.
Никому это не интересно, но идея индекса была такой, что записей с К=1 не должно быть более одной. А если их нет, то при вставке задавать К=1, иначе NULL.

На деле перед вставкой стоит проверка
select count(*) into cnt from my_ttt where b_id= число,
но я переделал в проце вывод для клиента, и он показывает, что cnt=2, и кажется, что всё логично.

В то же время отдельно стоящий запрос на реальных таблицах
select count(*) /*into cnt*/ from my_ttt where b_id= число
даёт 1, а cnt=2.
Вопрос теперь в этом. Но дело может оказаться и хитрее, т.к. это проца вызывается из другой в цикле по курсору. Но там всего 4 вызова, и все должны нормално отрабатывать, ан нет ... такие дела.

Причина исключения не в наивности, т.к. легко воспроизводится на этих идешниках в монопольке. А вот в чём, до сих пор не понял.
Но кстаи, данная операция весьма ответственная, и её проводят "специально обученные люди". Ну а так, правда Ваша.

И всё равно, если вызываю процу из девелопера, то она исправно добавляет нужные 4 записи.

Рассказал бы, какие щели ты увидел, но если кто захочет поразбираться, то вопрос сейчас у меня звучит так.

Если запрос
select count(*) into cnt from my_ttt where b_id= число
выполняется во время работы клиентского приложения, то
cnt =2.

Когда я выполняю его аналог из девелопера
select count(*) /*into cnt*/ from my_ttt where b_id= число, то
cnt =1.

Это реальный запрос, с той разницей, что есть ещё другие индексы как уник, так и и не уник. Из-за чего может быть различие? Мифических других пользователей нет, это на отдельной БД.

exp98если кто захочет поразбираться xtender , оно само роллбэкнулось ??
Весь фреймоворк устроен так, что приложение само не коммитится (кроме специальных случаев). Это делает юзер в ГУИ, в даном случае я за него, и я отвечаю: нет, не роллбэкнулось и не комитилось.

А базу тоже полную давать?

Уважаемые ораклисты, вот так всегда устраивают "побоище на птичьем дворе".
Кто-то наносит красную метку, а другие курицы начинают заклёвывать, думая, что это кровь.
Не надо побоища, не тратьте времени на писанину либо пишите по делу.

xtender, я в одной сессии.

xtender, ах, ну да, клиент сидит в одной сессии от старта до выхода из программы.

xtender, если бы. В любом случае исходная таблица для клиента и девелопера одна и та же, а результат разный.

Получив на клиенте неприличный результат, я конечно же делаю откат. Наверное этим уже сбиваю с толку? Т.о. для девелопера таблица остаётся такой же, и там всё видно. А могу на клиенте закомитить, а в девелопере лишнее удалить. Всё легко воспроизводится десяток раз и с любого компа, и девелопер с любого компа.