Да нет - не сталкивались. Какая версия SQL, покажи как индексы создаешь (код)

И глюк скорее всего происходит в момент записи двух документов и возникновении взаимной блокировки таблицы журналов или DH*. При этом гибкие блокировки не используются, используется только метод ROMIX-а по обходу цикла в момент ожидания блокировки (odbc33.dll: http://x-romix.narod.ru/vk_TerminalSleep.rar).

pvase писал(а) 31. Августа 2010 :: 06:17:

Если на время отключить vk_TerminalSleep subj возникает или нет.

Тогда получается что при записи документа DH2337
у тебя идет какая то другая запись в документ dh16707
может как раз у тебя в некоторых случаях
документ dh16707 новый именно тогда для него 1с выделяет
iddoc выделяет неправильно вот и получаешь subj
Не в модуле проведения все это ?

также что в определении индекса означает
IGNORE_DUP_KEY = OFF ( я не работал с sql2008)
может все дело в этом.

Цитата:

взято из http://msdn.microsoft.com/ru-ru/library/ms188783(SQL.90).aspx
т.е. просто получается у тебя
primary key не уникалный на этой таблице.
, а совпадение что все работает в монопольном режиме случайность ( не попадал на те данные). на тех же данных свалишься и в монопольном режиме.

PS (0) похоже у тебя серьезные проблемы с базой.
ищи на этом сайте мою обработку "проверьте ваши регистры"
проверяет не только регистры но и документы и проверяй базу как можно скорее.

pvase писал(а) 31. Августа 2010 :: 18:43:


Цитата:

слишком сильное утверждение после subj
Еще одна другая Проверка базы никогда не повредит

Цитата:

- при этом у тебя идет полное перестроение индекса. насколько я знаю при построении(перестроении) индекса не производиться проверка на уникальность.


Цитата:

Делай логирование либо через запись в файл на диск с:\
(если терминал то можно файл назвать используя @@spid) или
пиши логи в ms sql в другую базу чтобы  запись осталась даже при вылете. после того как найдешь где вылетает то можно обсуждать дальше.

насколько я вижу падение возможно в двух случаях
1.Либо  При записи из итерактивной формы существующего документа (у такого документа уже есть iddoc)

2.либо при выполнении команды Док.Записать() ( в этом случае важно документ новый или уже есть в базе).

Наконец то выловил баг, но вот как исправить - не знаю.
Вот что делает 1С-ка при записи документа:

exec sp_executesql N'
	Update DH2337
	set  
		IDDOC=@P1,
		SP17145=@P2,
		SP2311=@P3,
		SP2313=@P4,
		SP2314=@P5,
		SP2315=@P6,
		SP6004=@P7,
		SP2317=@P8,
		SP2318=@P9,
		SP2319=@P10,
		SP2320=@P11,
		SP2321=@P12,
		SP15782=@P13,
		SP15783=@P14,
		SP15784=@P15,
		SP15796=@P16,
		SP15859=@P17,
		SP16323=@P18,
		SP17146=@P19,
		SP18397=@P20,
		SP18910=@P21,
		SP20122=@P22,
		SP20602=@P23,
		SP20807=@P24,
		SP20952=@P25,
		SP21433=@P26,
		SP2330=@P27,
		SP2331=@P28,
		SP2332=@P29,
		SP2333=@P30,
		SP2334=@P31,
		SP17181=@P32,
		SP1853=@P33,
		SP1855=@P34
	where  SP2312=@P35
	',
	N'@P1 varchar(9),
	@P2 varchar(9),
	@P3 varchar(9),
	@P4 varchar(13),
	@P5 varchar(9),
	@P6 numeric(9,5),
	@P7 datetime,
	@P8 varchar(9),
	@P9 varchar(9),
	@P10 varchar(9),
	@P11 varchar(9),
	@P12 varchar(9),
	@P13 varchar(9),
	@P14 numeric(9,5),
	@P15 datetime,
	@P16 varchar(9),
	@P17 varchar(15),
	@P18 varchar(9),
	@P19 numeric(1,0),
	@P20 varchar(9),
	@P21 numeric(1,0),
	@P22 varchar(9),
	@P23 numeric(1,0),
	@P24 numeric(1,0),
	@P25 numeric(6,0),
	@P26 varchar(9),
	@P27 numeric(13,2),
	@P28 numeric(11,3),
	@P29 numeric(14,3),
	@P30 numeric(14,3),
	@P31 numeric(14,3),
	@P32 numeric(3,0),
	@P33 varchar(9),
	@P34 text,
	@P35 varchar(9)',
	'  IZ2C   ',
	'    2Q   ',
	'     7CB ',
	' 1MZ  CXNN   ',
	'     1   ',
	1.00000,
	'2010-07-29 00:00:00',
	'     1ZG ',
	'    VK   ',
	'    2U   ',
	'    V3   ',
	'    XD   ',
	'     8   ',
	1000.00000,
	'2010-09-06 00:00:00',
	'     1CB ',
	'               ',
	'     0   ',
	0,
	'     1   ',
	0,
	'     7   ',
	0,
	0,
	29,
	'     F   ',
	12931.38,
	0,
	12931.380,
	2586.276,
	15517.656,
	0,
	'     1   ',
	'аванс 7800',
	'   1PQ   ' 

Обратите внимание на строку: "where  SP2312=@P35"
т.е. вместо того чтобы использовать IDDOC 1С-ка использует поле дополнительно вручную созданного индекса. И конечно же получается ошибка:
Violation of PRIMARY KEY constraint 'PK_DH2337'. Cannot insert duplicate key in object 'dbo.DH2337'.

pvase писал(а) 09. Сентября 2010 :: 10:47:

как это проходит
когда у тебя @P34 = 'аванс 7800'

pvase писал(а) 09. Сентября 2010 :: 11:23:

да не может такого быть потому что 1с идентефикаторы ( реквизиты документов ) нумерует последовательно.

или вместо SP2312 там тоже нечто другое ?

Выкладывай здесь свой файл dds

Дополнительные индексы ставь после основных а наоборот
т.е вместо

#Доп. индекс Документ.Счет
I=IX_1SSH_CONTR                  |IX_1SSH_CONTR |1     |SP2312,IDDOC                                                |0          
I=IX_1SSH_MANAG                  |IX_1SSH_MANAG |1     |SP17145,IDDOC                                               |0          
#----Indexes------
# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK_DH2337                      |of IDDOC      |1     |IDDOC                                                       |1          



надо

#----Indexes------
# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK_DH2337                      |of IDDOC      |1     |IDDOC                                                       |1          
#Доп. индекс Документ.Счет
I=IX_1SSH_CONTR                  |IX_1SSH_CONTR |1     |SP2312,IDDOC                                                |0          
I=IX_1SSH_MANAG                  |IX_1SSH_MANAG |1     |SP17145,IDDOC                                               |0          


PS  это естественно для всех документов а не только для одного.

пост #22 мне не очень понятен.
ты 21 или подтверди или опровергни.

или поискать готовое решение. например:
http://www.1cpp.ru/forum/YaBB.pl?num=1188387114/11#11

trad писал(а) 09. Сентября 2010 :: 17:42:


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

Z1 писал(а) 16. Сентября 2010 :: 06:04:


Идея хорошая (позволяет SQL 2008), но надо тестировать, насколько это будет производительнее чем стандартный индекс по таблице. К тому же есть еще одно предложение, разделить таблицы, на 1С-кую (оставить только родные реквизиты 1С, ДатаДок, НомерДок) + свою, в ней все остальные реквизиты (правда придеться по-программировать с записью элементов). В такой схеме можно разделить данные, также упростить формы списка элементов (если использовать родные формы списка а не ТабличноеПоле).

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