Добрый день.
Имеется 1с 77 + mssql 2005, пользователи в основной массе терминальные. База сугубо самописная, работало все нормально до открытия периода 1 августа. Далее начались полтергейсты -1с виснет рандомно на ровном месте.
К примеру подбор в справочнике на БЕ (БУ,БЮ короче все) работает, на БИ - виснет наглухо. Документы с 14 строками - виснет наглухо(если из дока убрать строку или добавить начинает открываться). В логах пусто, в procmon - пусто, в профилере sql видно что прилетает запрос (правильный) который в статусе выполнен и на этом просто все останавливается (т.е. либо от sql не уходят данные, либо 1С не может их переварить) при этом сами запросы в студии выполняются.
Самый смак - пользователи которые с локальных машин работают - все нормально. И еще интереснее - развернули копию на стороннем сервере и подключились с терминала в котором глюки - тоже все хорошо.
Если запрос, на котором 1С встает, попробовать выполнить из 1С прямым запросом - тоже вешается. Этот же запрос в тестовой программе работающей через ODBC - работает.
Голова уже кругом, помогите добрым советом.

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

1 Пробовали...Сейчас выяснил, что те запросы которые не отрабатывают в MSV секунд через 20 валит ошибку 24000  не допустимое состояние курсора...При этом вот этот:

select * from SC17170 (NOLOCK) where row_id=(Select min(row_id) from SC17170 sc_2(NOLOCK) where sc_2.DESCR=(select
min(DESCR) from SC17170 sc_3(NOLOCK) where   sc_3.DESCR>='БИ' and sc_3.DESCR<='БИяяя'  ))

не работает, а вот этот:

select * from SC17170 (NOLOCK) where row_id=(Select min(row_id) from SC17170 sc_2(NOLOCK) where sc_2.DESCR=(select
min(DESCR) from SC17170 sc_3(NOLOCK) where   sc_3.DESCR>='БУ' and sc_3.DESCR<='БУяяя'  ))

Очень даже.

(2) Где то, у справочников с наименованием БИ и БИяяя есть нечепятаемые символы.
Я бы индексы перетроил, для начала.

(0)  развернули копию на стороннем сервере и подключились с терминала в котором глюки - тоже все хорошо.

а копию небось делали "выгрузить-загрузить данные"? вот эта выгрузка-загрузка и полечила. вот тебе и способ лечения.

Пихают в базу в реквизиты содержимое из экселя и прочих непотребств копипастом - вот и мусор в базу и лезет.

(0) Обновить индексы и статистики. Например вот этим: https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

Те кто использует 7.7 на любых версиях mssql, кроме sql2000 - сами себе буратины. Ибо даже 1с не заявляла никогда о совместимости.

(7) ммм... я бы сказал, что техническую литературу читать гораздо полезнее, чем маркетинговые словесные интервенции.

(6) У топикСтартера mssql2005

(9) Забавно. 3 января 2020 была последняя версия скрипта, в которой заявлена поддержка MSSQL 2005.
Я бы, честно говоря, тоже на что-то более позднее переехал.  Но есть репозитарий, в котором можно взять старую версию скрипта.
Ну и кроме Олы есть другие товарищи, которые такого рода скрипты выкладывали.

Господа, давайте оставим версии программ, а так же состояние самой БД. Проблема явно не там, а в прокладке ODBC -> MSSQL. Ключевой вопрос что с этим делать....А есть у ODBC какой-либо кэш/мета-данные что можно было бы подчистить?

(11) Вы же пробовали напрямую запрос запускать, без всяких там адо и одбц. Проблема наблюдается также. Следовательно, проблема не там.

(12) Как раз таки запросы мимо ODBC прекрасно работают. Более того, если в выше указанных запросах вместо * перечислить поля - тоже работает. Так же работает, если перед запросом поставить set nocount on
Так что проблема явно в ODBC

Отвечу сам: KB948963 + force encryption в настройках MSSQL именно для ODBC соединений давало такие эффекты. Удаление KB948963 либо отключение force encryption сразу все приходит в норму.
Вопрос закрыт.

(14) спасибо что отписался решение проблемы!

(9) А зачем такая древняя БД? Надо использовать хотя бы 2019ую версию в режиме in-memory с native compiled stored procedures. Всё летает просто моментально и не нужно строить покрывающие индексы и всё такое.

(16) клюшки умеют (точнее есть костыли для) 2019?

(16) Вот взял бы и рассказал как клюшки подружить с 2019! Но, имхо, там возни много - хранимки написывать, тригера на каждый чих... не считая колдунства для того, чтобы их хотя бы соединить.

(17) (18)
Сама по себе 77 точно не умеет.
Но это решается сервером приложений middleware, который перехватывает запросы, идущие от 77 к СУБД и переделывает их на лету.
Это так называемый ad hoc.
Причём это не костыль, а как раз штатный механизм работы сервера приложений. Это 77 явный костыль. Давно пора уже использовать хотя бы версию 8.3.

(7) ну попробуй на 2000 поработай. ПРичем тут заявленое?

(19) <Это 77 явный костыль. Давно пора уже использовать хотя бы версию 8.3.>

это звучит как "в ядерном реакторе используется комп на базе 486 и древним юниксом, это явно костыль, надо давно перейти на Intel на 16 ядер и хотябы GeForce GTX и под управлением Windows 11"

7.7 это энтерпрайзный софт, если клюшки юзают с SQL то видимо с хорошей нагрузкой, проект миграции на "хотябы 8.3" в одном толко железе в пару лямов выльется, а если затраты на перевнедрение и миграцию посчитать то пи..ц
А это на секундочку только с вводной "глючит один запрос в базу"
Вам не кажется что совет довольно безумный?

===
middleware, который перехватывает запросы --- его надо писать или есть решение готовое? если писать то всё опять сводится к огромным затратам

(21) :) хомячки автоматически повторяют за Нуралиевым "переходите на 8 там все реализовано" since 2003
может им за это кибер.фин.отдел зао 1с доплачивает биткоинами?

(21) отчасти есть готовое: https://infostart.ru/1c/tools/82018/
для совсем новых версий SQL надо ещё sp-шку sp_dboption со старой версии взять

(20) Какие проблемы работать на 2000?

Как много в мире странных людей...пока был вопрос все чего-то молчали, как только вопрос закрылся - полилась река снобизма. Однако, поясню почему так и не иначе: база самописная практически с нуля, объем на сегодня 320 Гб, работает 24/7 и еженедельно обновляется доработками по требованию руководства. Попытка мигрировать на 8.3 была в 2015 году - команда столичных разрабов пыхтела более 2-х лет,на выходе получили скелет конфы которую допиливать и допиливать, не говоря о том как в нее выгрузиться и не говоря о том что за это время в рабочую базу было внесено не мало изменений. На том пока и заглохло. Помимо всего прочего тестовые прогоны того, что в 8-ке все же завелось показали что работает оно хоть и не сильно, но медленнее, а силу особенностей интерфейса производительность конкретных пользователей падала вдвое.
Теперь по поводу sql 2005. Ну во-первых 77 с более свежими не работает, а даже если б работала, то использовать его новые фичи, в силу свой древности, явно не смогла бы. Во-вторых он есть и есть к нему порядка 100 cal лицензии, которыми тупо можно подтереться с случае апгрейда сервера. Т.е.  потратить самосвал денег на лицензии для ПО, функционал которого будет востребован лишь на уровне того, что уже есть. Это как-то странно, вы не находите?

(23) У данного решения есть серьезные проблемы, которые автор сам признает и пока ищет пути решения. А именно часть прямых запросов либо не работает, либо работает со странностями, а у нас база почти вся на прямых запросах и странности в этом деле не приветствуются

(25) 77 прекрасно работает на SQL 2008, проверено годами и не одним клиентом/базой.

(25) :) "в 8-ке все же завелось показали что работает оно хоть и не сильно, но медленнее"
забавно
год назад был в конторе которая не могла перейти на 1с83 по скорости из-за объема НО те пытались на типовую
а ваши внедрюны с нуля писали? максимально оптимизированно используя платформу или как?

(27) :) ... в режиме совместимости с 2000?

(29) Нет, с секретным релизом :)

(30) :) т.е. форс мажор из (26) не мешал? и даже стандартный оператор **ОтключитьSQL*** не использовалась?

(31) Нет, на одной базе было несоколько прямых запросов, все работало.

(28) Честно не вникал, т.к. 1С не занимаюсь. Но вроде на базе типовой торговли

(33) :))) те еще внедрюны ... у нас на моей второй работы уже которая шайка сменилась - все внедряють 8 ... прошли курсы по типовой рознице и с криком ваша 77 уг впаривают типовые мне сказали в самом начале внедрения да мы за пол-года все салоны на розницу 2.2 ... я говорю - неа - 3 года минимум .. уже год как на фронтол перескакиваем а в офисе ваще чума ... лет  7 уже