Quan писал(а) 26. Мая 2006 :: 07:02:Итак, предложения (независимые, кстати, от 1Сплюсплюсности)
1. Без описанных выше революционных преобразований - тоже есть вариант, но корявый:
А нафига считать итоги в модуле проведения?
ДО начала проведения считаем итоги. Передаем их в модуль проведения в качестве параметра. При отсутствии параметра модуль проведения работать отказывается.
В скорости не выиграешь, но от блокировок уходишь.
Только системный флажок придумай: установил флаг, посчитал итоги, сбросил флаг. А если кто-то втыкается в уже поднятый флаг, то "сделай паузу, скушай sleep(1000)" - в цикле, пока флаг не освободится. Правда, придется тогда все доки, двигающие 41й счет, с этим флажком знакомить.
Не пойдет. Что будет если А снял итоги и Б снял итоги в один момент времени. Потом начал проводить А, следом за ним проводит Б. Получается что уйдем в минуса. Надо вешать блокировки перед расчетом итогов, но вешать блокировки например на товар а не на всю таблицу
Пока Список.ПолучитьСтроку()=1 Цикл
ТекЭлемент=Список.Товар;
Состояние("Ожидание разблокировки: "+ТекЭлемент);
УникальныйРесурс=""+глИдБазы+"_"+ТекЭлемент.Код+"_"+Склад.IDD;
ТекстЗапроса="DECLARE @result int
|EXEC @result = sp_getapplock @Resource = '"+УникальныйРесурс+"', @LockMode = 'Exclusive', @LockOwner = 'Transaction', @LockTimeout = 500000";
ODBCRecordset.Выполнить(ТекстЗапроса);
КонецЦикла;
Список - Список с товарами глИдБазы соотвесвтенно ИД нашей базы на сервере. Реквизит IDD - у меня уникальное число, но можно использовать ID например... Тогда допустимо использовать расчет до проведения и это действительно снизит время траназкии на проведение.