DRod....'TLK_O_demands' locked
No changes made to database.
....
У тебя же написано - таблица залокирова. Почему - надо смотреть. Возможно в момент вставки строки триггером запускается какой-либо процесс ( или проверки, или записи, или ... ), который и локирует таблицу. Надо разбираться, а решение проблемы - скорее всего запись в таблицу имеет смысл сделать через процедуру, которая будет ждать, когда таблица освободится и локирование будет снято ( при условии, что локирование необходимо и прекращается после завершения процесса вставки строки ).

Good Luck !

Dmitry.или просто не сделали коммит
Точно,
хотя смущает :
DRod... Ошибка появляется не регулярно....
Good Luck !

Anatoly Moskovsky ChV Dmitry.или просто не сделали коммит
Точно,
хотя смущает :
DRod... Ошибка появляется не регулярно....
Ну допустим есть два окна. В одном при сохранении есть коммит, в другом нет.
Да ради бога. Пусть будет. Это же всё наши предположения, а что у него там, только он и сможет разобраться. Вообще понятно, что, если ошибка фиксируется, то это легкий случай и копать не трудно. Хуже, если ошибка проявляется только "в динамике", в реальной работе, при большой загрузке.

Good Luck !

Если нет обработок по триггеру, через процедуру вставлять строки не хочется, а проблема не решается, то может все таки попробовать сделать то, что советовали в самом начале ?

SQLCA.autocommit=True
, ну и немного изменить обработку :
DRodСоединение в приложении:
SQLCA.autocommit=false;
....
В DW под событие dberror стоит ROLLBACK; и сообщение "Повторите попытку...".
Под кнопкой "Сохранить":
ll_ret = dw.Update()
if ll_ret <> 1 then
MessageBox("Ошибка","Нельзя записать ЗАГОЛОВОК документа!)
return
end if
COMMIT;
....
Блокировка таблицы продолжается пока заблокировавший пользователь не выйдет из приложения, т.е. разорвёт соедиенение.
Конечно не мое собачье дело, но если произошло событие "DBERROR", то есть необходимость в ROLLBACK ? Или необходимо обеспечивать запись только блока строк ?
Во вторых, даже если autocommit=false, почему бы после этих операций не "разорвать соедиенение" самому, без выхода из приложения ?
Да и воспользоваться, не SQLCA, а своей транзакцией, которую потом можно и уничтожить ( для гарантии :-) ) ?

Transaction tran
tran = CREATE Transaction
...
tran.autocommit=false
...
COMMIT USING tran;
DISCONNECT USING tran;
DESTROY tran

И в третьих - у нас похожая проблема добавления связанных записей в нескольких таблиц, при которой происходить куча проверок, добавление вычисляемых значений, работа триггеров, при одновременной работе большого количества пользователей - успешно решается при использовании процедуры ( Microsoft SQL ).

CREATE PROCEDURE ....
.....
select @lock=1
while (@lock=1)
select @lock=lock from aaaaaaa
BEGIN TRANSACTION
update aaaaaaa set lock=1
.....
if @@error<>0
begin
Rollback transaction
return
end
.......
update aaaaaaa set lock=0
......
COMMIT TRANSACTION
......
GO


Good Luck !

Anatoly Moskovsky ChVесли произошло событие "DBERROR", то есть необходимость в ROLLBACK ? Или необходимо обеспечивать запись только блока строк ?

Rollback всегда нужно делать после неуспешного dw.Update() (и не в dberror, а после Update() )
Это связано с тем, что в этом случае статусы измененных строк в DW не сбрасываются и если не сделать rollback, то при последующих Update() произойдет повторное проведение операций DML, что в случае Insert вызовет ошибку из-за дубля Primary key, а в случае Delete/Update - Row changed between retrieve and update (в DW с настройками update по умолчанию).
Неуспешные dw.Update() я отрабатываю, но спасибо, буду иметь ввиду. "Век живи - век учись, а ..."

Good Luck !