Всем привет. Есть база 7.7 сильно переписанная ТиС, используются прямые запросы, FormEx и т.д., имеется УРБД. Суть проблемы следующая: есть прямой запрос, который вставляет в таблицу регистрации изменений УРБД записи для отправки справочников в нужные периферийки по условию. Периодически при попытке выполнения такого запроса вылетает критическая ошибка "Недопустимое состояние курсора" и 1С тупо закрывается. Перед этим обычно происходит deadlock. Помогите решить проблему, хотя бы с какой стороны подойти к решению.

(0) Перед вставкой наверно нужно блокировку наложить. Не?

		ТекстЗапроса = "
		|DECLARE @SelectedId char(9)
		|DECLARE @SelectedDef int
		|DECLARE @SelectedSign char(3)
		|DECLARE @count int
		|SET @SelectedId=?
		|SET @SelectedDef=?
		|SET @SelectedSign=?
		|UPDATE _1sjourn SET verstamp=(SELECT verstamp FROM _1sjourn WHERE iddocdef=@SelectedDef AND iddoc=@SelectedId)+1
		|WHERE iddocdef=@SelectedDef AND iddoc=@SelectedId
		|SET @count=(SELECT count(*) FROM _1supdts WHERE typeid=@SelectedDef AND objid=@SelectedId AND dbsign=@SelectedSign)
		|IF @Count=0
		|BEGIN INSERT INTO _1supdts VALUES (@SelectedSign,@SelectedDef,@SelectedId,' ',' ')
		|END
		|ELSE
		|BEGIN
		|UPDATE _1supdts SET dwnldid='' WHERE Typeid=@SelectedDef AND Objid=@SelectedId AND DBSign=@SelectedSign
		|END";
		
		Если Элемент.Выбран() = 1 Тогда
			ИдЭлемента = глMDW.ЗначениеВСтрокуБД(Элемент);
			ДефЭлемента = глMDW.ИДСправочника(Элемент.Вид());
			
			глRecordSet1CPP.ДобПараметр(1,14,9,0);
			глRecordSet1CPP.ДобПараметр(1,4,4,0);
			глRecordSet1CPP.ДобПараметр(1,14,3,0);
			глRecordSet1CPP.УстПараметр(1, ИдЭлемента);
			глRecordSet1CPP.УстПараметр(2, ДефЭлемента);
			глRecordSet1CPP.УстПараметр(3, ИдБазы);
			глRecordSet1CPP.ВыполнитьСкалярный(ТекстЗапроса);
			
			глRecordSet1CPP.УдалитьПараметры(); // Удалить параметры
		КонецЕсли;

Вот такой запрос выполняется для вставки.

(1) А разве она сама не накладывается автоматически?

set nocount on
в начале запроса

		|UPDATE _1sjourn SET verstamp=(SELECT verstamp FROM _1sjourn WHERE iddocdef=@SelectedDef AND iddoc=@SelectedId)+1
		|WHERE iddocdef=@SelectedDef AND iddoc=@SelectedId

Вот это я так понимаю тоже можно выкинуть, если регистрируются только справочники, без документов?

(5) да

Спасибо за ответы, внес правки, буду наблюдать за поведением 1С.

(5) а зачем вообще verstamp трогать? ты ж не изменяешь док.

(8) принудительная регистрация к обмену

(9) Принудительная регистрация - это как раз запись в updts.
изменять верстамп для этого совршенно не нужно. Верстамп нужен для разрешения коллизий.

В общем добавление set nocount on в начало запроса не помогло. Все равно вылеты с этой ошибкой. Перед вылетом всегда deadlock. Если отключить эту регистрацию прямым запросом, то падения не происходит. Просто вылетает сообщение о deadlock и все.

Есть подозрение, что в момент выполнения этого прямого запроса к таблице _1supdts, она параллельно изменяется УРБД и  при попытке обновления найденной записи в таблице падает, т.к. записи уже нет, например

SELECT verstamp FROM _1sjourn (nolock)

(13) Я уже выкинул из запроса журнал документов, он мне не требуется

Тогда так
FROM _1supdts (nolock).
Возможно ещё нужно объявлять курсор, и делать deallocate.
Добавь глRecordSet1CPP.Закрыть();

(15) Что-то я не уверен, что nolock правильный вариант, точность данных может нарушиться. Получается чтение того, что где-то в параллельном сеансе можем апдейтнуться

(16) тогда только закрывай курсор

(16) в паралельном сеансе может быть либо регистрация для обмена (штатно ли, либо твоим механизмом), либо разрегистрация (подтверждение обмена механизмом УРБД).
В первом случае ты "повторно отправишь" (т.е. ничего не изменишь), во втором - зарегистрируешь еще раз (т.е. элемент сбегает в ПБ еще разок. Если у тебя не "снежинка", то - имхо - ничего страшного ).
Ну и как вариант - ищи запись только неотправленную (с пустым даунлоадидом), если нет - создавай. Будет небольшая избыточность при обмене...

Ну или натравливай на базу-таблицу sql-профайлер, лови ошибку...

(11) "В общем добавление set nocount on в начало запроса не помогло."
но, тем не менее, не убирай, он там нужен

(18) т.е. предлагаешь не апдейтить таблицу, а только инсертить в нее по необходимости?

(20) ну да. искать с пустым идом обмена, и если нету - то добавить. тут может быть коллизия только если запись уже выгружена, но еще не отмечена как выгруженная (но она по идее в этот момент в курсоре, и будет обработана). Я индексы не помню, уж лет 8 в клюшечную урбд не лазил, но вроде должно разрешить...