Долго я маялся со своими процедурами и триггерами непонимая в чём дело пока не обнаружил, что работает всё далеко не так как я себе представлял. чтобы долго не обясянять просто приведу пример как есть, а как хотелось бы.

1-вый процесс

2-вый процесс (запускает транзакцию после того как проделано вставку первой транзакции (процесса))


1-вый процесс
delete LockTest
where pk = 1 --висит (ждёт коммита второй транзакции)
--илиже
rollback --тоже висит (ждёт коммита второй транзакции)

можно также удачно сделать коммит первой транзакции
но удалить запись посде этого также нельзя будет пока не будет коммита воторй

Читал я в докумментации я про эти блокировки там это дело как-то с индексами связано, вроде как хорошо если они есть... но и уменя он есть на PK. Отчасти моё непонимание связано с неидеальным пониманием английского языка на котором у меня документация. Толи написано размыто и не доконца... вообщем немогу охватить я это дело своим пониманием.
Конечно-же я не прошу чтобы меня тут кто-то стал учить, почитаю ещё несколько раз может больше пойму, но если можно то коротко напишите ктото почему в данном случае всё происходит так,
и второе - что можно попробовать сделать чтобы такого небыло.
Я так понимаю заставить аса для некоторий таблицы использовать построчную блокировку нельзя а только можно создать предусловия для чтобы получалась такая схема блокировки, поскольку АСА старается, как где-то написано, вибрать самый слабый тип блокировки (тоесть по возможности на строку а не таблицу)

Dim2000
В ASA нет других видов блокировки, кроме позаписной (LOCK TABLE -
отдельная история).

но зато он может судя по всему легко может наложить по одну блокировку на каждую строчку таблицы :-)...
Ну всётаки это у меня праильно всё происходит в примере. Я как вчера начал читать про всякие там антиинсертные, фантомные и ещё какието там блокировки у меня голова разболелась, планирую почитать ещё сегодня только не перед едой, ато опять апетит испортится.

засада с не тем типом и просмотры планов мне известны по АСЕ. Даже топик есть гдето там старый мною начатый , попробую я и тут посмотреть.. просто переживаю, что разница есть в этих субд потому и забыл.. слабое подозрение на то что может в таблице слишком мало записей, может если бы их было побошльше и строки находились бы в разных частях таблицы то такого.
Кроме того Вы можете тожесамое проделать у себя за 1 минуту. достаточно двух окон dbisql и скрипта на создание и вставку по таблицам которые описаны выше.
Судя по Вашим вопросами я догадываюсь что Вы согласны с тем что ситуация ненормальная если пока неговроить про причины...

Я тоже проделывал несколько часов тому на АСЕ и всё работает нормалёк.
А на АСА таки "выяснил"(покрайней мере так думаю, експриментировал..)
брал уже нормальную таблицу. Такое происходило только в тех случаях когда удалялись
строчки наохдящиеся в непосредственной близости (конечно же и это гарантировать не могу т.к. и спешил к тому же успокоить публику да у немного другим был занят. ).
Кроме того "заблокированную" (которую нельзя удалить) строчку можно редактировать, просто удалять нельзя. Если быть более менее уверенным в том что я сам только что написал можно было бы думать как это обойти.. но нет веры..
Ябы не поднимал конечно-же этот вопрос если бы убедилься в этом раньше.
Теперь просто оказывается, что нельзя быть уверенным в том что запись взятая с помощю readpast действительно незаблокированная,
со всеми последствиями относящимися к некоторому числу процедур.

Непривычным, я бы сказал, есть поведение АСА когда ложатся разделяемые блокировки на главную запись, в то время когда не то-что вставляется/редактируется, а даже только удаляется подчинённая ей запись из другой таблицы. Приходится надеятся что чем-то оправданы такие предосторожности или "побочные ефекты" чего-то другого, но очень хрошего :-)