|
03.04.2011, 11:10 | #1 |
Участник
|
Если в итоге все доходит до того что глюк так легко воспроизводится, то может попробовать воспроизвести ошибку руками, посмотрев при этом кто когда редактировал табличку и какие сессии её на текущий момент держат ?
Судя по симптомам - у вас как-то перепутались соединения к БД. Ну то есть работало соединение к базе, в нем осталась незакрытая транзакция. Потом его хватает из пула соединений аоса другая сессия и пытается работать. А транзакция не закрыта, блокировки вешаются и вешаются, в том числе и на системные объекты и в итоге это все принимает совсем некрасивый вид. Но почему такое могло случиться - ума не приложу. Вы не кастомизировали работу с номерными сериями или другие места, где явно из кода используется отдельное соединение к базе ? |
|
03.04.2011, 12:53 | #2 |
Боец
|
Цитата:
С номерными сериями - нет, а вот прямой вызов SQL используется часто, правда, натравлен на другие БД. Т.е. БД аксапты напрямую не используется. Но на самом деле - хз, я не могу это на 100% исключить, т.к. систему насиловали долго и упорно. Как проверить эту версию? |
|
03.04.2011, 13:23 | #3 |
Участник
|
Цитата:
Прямо барабашка. А не может быть так что эта табличка уже открыта в обозревателе таблиц или в формочке из под вас же и в силу каких-то причин запись на форме сохраняется (бред конечно, но все же) Еще вариант - попробовать на этой табличке отключить оптимистическую конкуренцию. Если реально идет обновление кем-то, то скорее всего ваш джоб зависнет. Можно тогда посмотреть на ком и кто его держит. Еще вариант - может сиквел глючит в режиме Snapshot isolation - вы посмотрите там все порядке - места в темпах достаточно ? Не переполнились ? |
|
Теги |
ax2009, ax2012, ax2012r2, occ, sysclientsessions, ошибка, хранимые процедуры |
|
|