mustliveК сожалению, я не могу ODBC выкинуть, клиент только через него работает :(

Пока насовал везде COMMITов, вроде, помогло

А на чем сам клиент писан ? Если на РВ, то должно лечиться легко. У объекта класса transaction есть свойство autocommit - False by default.

На заре работы с РВ и ASA на такие граблии натыкались. Но блокировка была только на запись. Чтение проходило нормально. Если включить autocommit , то после каждого обращения в базу автоматически будет делаться Commit.

Будет только проблема, если требуется сбросить изменения из клиента в виде транзакции (ну, там форма с окнами master - detail и при ошибке оба нужно откатить). Тут транзакцию придется прописывать ручками. Или сесть на PFC. У window_master в событии pfc_save все приготовлено - нужно только 2 события пустышки доопределить (begin_tran и end_tran, точно не помню, потому как почти 5 лет назад сделано и забыто :).

Кстати, autocommit РВ не висит в воздухе, а транслируется в параметры вызовов ODBC. Там есть соответствующее свойство. На память его не помню, а хелпов на этом компьютере нету :(. Скорее всего копать нужно именно в этом направлении.

Как я понимаю, без autocommit ODBC элементарно не закрывают внутренний, скрытый от глаз клиента, курсор, через который и читаются данные.

Да, еще проверить нужно какой в БД прописан isolation level, при нормальном проектировании он должен стоять 0 и подниматься только при выполнении критичных обработок на время обработки.

ASCRUS авторДа, еще проверить нужно какой в БД прописан isolation level, при нормальном проектировании он должен стоять 0 и подниматься только при выполнении критичных обработок на время обработки.
Лучше все таки 1 (READ COMMITED), так надежнее будет, тем более ASA на нем блокирует только текущую обрабатываемую запись курсора и этот уровень изоляции не несет в себе в отличие от следующих уровней изоляций каких то ограничений.

А мне по душе больше 0. а 1 и выше там где нужно. Яже не делаю закрытие месяца с изоляцией 0. А вообще, от стиля работы клиента сильно зависит. В РВ datawindow позволяют иметь клиенту очень короткие транзакции. Несколько проектов живут уже по 4-5 лет с изоляцией 0 и нареканий от пользователей пока не было. А вот когда стоит сериализация, а бухгалтерия вдруг решает обновременно закрыть 2 разных месяца, то deadlock пару раз за все время случался. Но ASA корретненько все откатила откатила, а пользователи повторили операцию :).

А еще с уровнем 0 очень удобно тестить заливку данных в БД. Я через isql заливаю порцию и не комичу ее. А из клиента смотрю отчеты и сравниваю итоговые цифры. Если что не туда поехало - rollback и все дела.