| 
	 | 
| 
			
			 | 
		#1 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			
			Проблема с транзакциями
			 
			
			При выполнении следующего кода транзакция вешается намертво.  
		
		
		
		
		
		
		
	static void Job1(Args _args) { numberSequenceTable numberSequenceTable; ; ttsbegin; select forUpdate firstOnly numberSequenceTable index hint SeriesIdx where numberSequenceTable.numberSequence == "КЛ_СчФакт"; info("!!!"); ttscommit; } Как решать подобные проблемы?  | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 MCT 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Что то не встречал прямого соотсетвия полю- значения. Может попробовать через объявление 
		
		
		
		
		
		
		
	переменой str a= КЛ_СчФакт;  | 
| 
	
 | 
| 
			
			 | 
		#3 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Дело не в том, что нет такой записи или SELECT не работает. SELECT без ttsbegin/ttscommit/forupdate выполняется. Суть вопроса в том, как отлавливать клинч транзакции.
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#4 | 
| 
			
			 MCT 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Наверное надо лазить по классам  и поставить метку типа info("Прошло нормально") 
		
		
		
		
		
		
		
	Ну и смотреть где глючит.  | 
| 
	
 | 
| 
			
			 | 
		#5 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Самое интересное, что проходит для любой другой номерной серии. Дубликатов нет, но вешается намертво.
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#6 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Вопрос решился заменой номерной серией. Хотя сам факт ошибки очень интересен, так как в SQL создавалось 2 процесса, которые блокировали друг друга...
		 
		
		
		
		
		
		
		
	 | 
| 
	
 | 
| 
			
			 | 
		#7 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			 
			
			У меня, наверное, не точно такая проблема, но уж очень похожая. 
		
		
		
		
		
		
		
		
			Тоже транзакция вешается при выполнении ttscommit. Ctrl-Break не срабатывает. Stack Trace после ttscommit (вторая строчка снизу) показывает следующее. Код: [s] \Classes\NumberSeqCleanUp\cleanUpTrans 40 [s] \Classes\NumberSeqDataArea\runCleanup 75 [s] \Classes\NumberSeqDataArea\run 4 [s] \Classes\NumberSeqGlobal\runAutoClean 30 [s] \Classes\NumberSeqGlobal\ttsNotifyBegin 3 [s] \Classes\Application\ttsNotifyBegin 3 [s] \Classes\Application\createEventCUD 22 [s] \Classes\Application\eventUpdate 5 [s] \Classes\xRecord\update [s] \Data Dictionary\Tables\NumberSequenceList\Methods\update 12 [s] \Classes\NumberSeqCleanUp\cleanUpAborted 19 [s] \Classes\NumberSeqGlobal\ttsNotifyCommit 3 [s] \Classes\Application\ttsNotifyCommit 3 [s] \Classes\OurClass\ourMethod 72 [c] \Classes\FormButtonControl\Clicked 26 Аксапта 4.0.2163.0 Последний раз редактировалось Hyper; 11.02.2008 в 19:44.  | 
| 
	
 | 
| 
			
			 | 
		#8 | 
| 
			
			 Member 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Аксапта работает с номерными сериями через отдельное подключение к БД. Номер при этом извлекается в отдельной конкурентной транзакции. 
		
		
		
		
		
		
			Сделано это для того, чтобы таблица номерных серий не блокировалась надолго или даже намертво. Отдельная транзакция маленькая и открывается буквально на время, необходимое для извлечения номера. Скорее всего, ваш код еще где-то генерирует номер из номерной серии, и в результате сам себя блокирует. 
				__________________ 
		
		
		
		
	С уважением, glibs®  | 
| 
	
 | 
| 
			
			 | 
		#9 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Да, что-то явно блокируется. Примечательно, что попытка обычного удаления одной записи из таблицы NumberSequenceList с NumberSequence == конкретной номерной серии вешает систему. Для остальных номерных серий удаление записей происходит без проблем. 
		
		
		
		
		
		
		
	Неясно каким образом продолжать анализировать эту проблему без рестарта AOS, т.к. любое действие приводит к зависанию клиента... А постоянно рестартовать AOS то еще развлечение.  | 
| 
	
 |