Предполагая, что форум - всё же программистский или около того :-)
Возникла проблема.
1С 7.7.027 SQL-версия. MS SQL Server 2005. Всё прекрасно, всё работает. Но в один прекрасный момент выяснилось, что некоторые элементы справочников - не записываются интерактивно. Пользователь на форме может менять реквизиты хоть до посинения. Потом - "ОК". Открывает элемент снова (или смотрит в форме списка) - и, как говорили древние шумеры, авотхервам, значения реквизитов - старые.
Причём программно (спр = СоздатьОбъект("Справочник.Номенклатура"); спр.НайтиЭлемент(КтоНужен);спр.Наименование="ййй!";спр.Записать();) - прекрасно работает.
И интерактивно-то - работает! То есть, если в ПриЗакрытии (а там - значение уже записано, видно при просмотре SQL-таблиц) посмотреть значения ТекущийЭлемент().ИзмененныйРеквизит - всё просто замечательно. Но как форма закроется - бдымц! Значения возвращаются на круги своя.
Хорошо. Лезем в SQL profiler, смотрим, что там выполняется.
Запись элемента производится в неявной транзакции. И вот эта неявная транзакция при интерактивном закрытии - откатывается. А при программном - коммитится.
Разница состоит лишь в том, что при интерактивной записи выполняется _1sp_SC84_ByID - которая ничему навредить не может, ибо это просто select ... where.
Понятно, что дело - не в 1С. И не в её "хранимках" - поскольку та же самая интерактивная запись у всех прекрасно работает.

Вопрос: куда копать?

как сдружили скуль2005 с 7.7?

(1) "Как обычно" (но не "секретным релизом"). Сауроновский патч.

(2) Крутится уже лет 5 как минимум.
Раньше всё прекрасно работало, проблема была обнаружена в предновогоднюю неделю (в связи с "перелопачиванием" справочника).

я бы всё-таки посоветовал секретный релиз http://infostart.ru/public/82018/
причём последнюю версию Solution7
с ним, по статистике, траблов намного меньше

(4) Я бы тоже посоветовал "секретный релиз" (и уже даже его посоветовал). Но у этой конторы есть некие административные проблемы (я там появляюсь как приглашённый консультант, и сам ничего менять не могу).

(5) Стоит.

(в порядке бреда) collation какой стоит?

(7) Кириллица общая CI_AS

Нет, тут место ошибки выявлено - при записи начинается неявная транзакция, в ней - select'ы и update (через sp_executesql), в конце - проверка: если @@TRANCOUNT>0, то коммит. В противном случае неявная транзакция завершается - и происходит откат. Так вот этот TRANCOUNT оказывается почему-то 0.

(9) Да.

Причём программная запись - проходит на "ура!". Отличие программной от интерактивной записи - в вызове _1sp_SC84_ByID (при интерактивной записи). Который - просто select.

а проблема, я так понимаю, со всеми справочниками, не только с номенклатурой?

(14) Пока что обнаружена _только_ на Номенклатура. Да и то - _не на всех_ элементах.
Индексы в порядке. IDы и коды - в порядке.

Rie IDы и коды - в порядке.

именно в скуле проверял?

На копии базы - проблема воспроизводится.

(17) копия выгрузкой-загрузкой в конфигураторе создавалась, или средствами скуля переливалось?

(18) копирование - средствами SQL: backup + restore с изменёнными путями/именами (я как-то выкладывал обработку, которая это проделывает, могу выслать, чтобы было ясно, что делается).

вообще, конечно, локализация проблемы на одном справочнике наводит на мысль о проблеме с данными

Ну, о том, что ТИИ ничего не даёт - и говорить уж не буду.

(19) а если выгрузкой попробовать? или слишком большая база?

(22) База слишком уж велика, чтобы выгрузкой.

Rie Да и то - _не на всех_ элементах.

а на этих проблемных элементах воспроизводится в 100% случаях?

(25) Да.

в сторону триггеров рыл?

(28) Рыл. Где они там, в 1С-ке? Нету их.

(29) Сделал. Я уже писал: отличие в том, что при интерактивной записи выполняется _1sp_SC84_ByID, а при программной - _внутри неявной транзакции_ создаётся курсор для обновления формы списка. То есть, вывод - транзакция рушится в _1sp_SC84_ByID. Но там ей просто негде рушиться!

И, ёрштвоюмедь, попытки воспроизвести эту хрень на других базах - потерпели неудачу. На других базах - всё работает.

Была мысля, что переполнен журнал транзакций. Взял другую базу. И начал пихать туда элементы и их изменения. Random'ом. Log разросся до посинения. Но - работал.

Rie Где они там, в 1С-ке? Нету их.

ну, мало ли. может, какая-нибудь жёсткая самописка

(31) Модифицированная ТиС. Но не настолько модифицированная :-)

(32) На ней, родимой (пустая база, загружается изменённая конфигурация, обработка создаёт кучу всего, потом резвимся).

DBCC DBREINDEX?

(34) _1sp_DBReindex
Делает то же самое по сути. Но - потаблично.

(35) ну, на всякий случай. вдруг поможет.

ещё идейка:
перелить средствами скуля в пустую базу на основе той же конфиги только справочник номенклатуры и необходимые подчинённые (единицы, и т.п.; цены можно не переливать - необязательно)

и посмотреть, воспроизведётся ли

(35) Идея интересная. Но - невоспроизводима ("на основе той же конфиги" - первым делом сама 1С обнаружит, что важные ей справочники не заполнены, и займётся этим грязным делом). И, на мой взгляд, бесполезна (см. ниже).

Тут мне вообще непонятно - за счёт чего рушится транзакция при интерактивной записи? И не рушится при программной. Отличия - минимальны: интерактивно - перезапрос данных элемента, программно - создание курсора для обновления списка.

Хотя... Есть другая мысль. Программно открыть форму для проблемного элемента - не открывая список. К сожалению, проверить смогу не сейчас.

Rie Программно открыть форму для проблемного элемента - не открывая список.

это не должно что-либо изменить

Rie первым делом сама 1С обнаружит, что важные ей справочники не заполнены, и займётся этим грязным делом)

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

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

(38) Последний мой совет им был - добавить реквизит в справочник Номенклатура.
При этом 1С реструктуризует таблицы и хранимки. И если были какие "косяки" - они, по идее, должны быть прибиты.

(40) это шож, глючила не одинэска, а скуля? странно

(41) Выходит так...