Очень надеюсь на вашу помощь, хочу разобраться в следующей ситуации. Итак, имелось 1С 7.7 (25), ТиС, SQL Server 2000 - 8.00.679(SP2), практически год безупречной работы. Сегодня при попытке проведения счета-фактуры появилась ошмбка SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Время ожидания истекло, попытка повторить транзакцию к успеху не привела. Соответственно на всех машинах в сети, то же самое. Работа остановилась. Перезапустил SQL сервер - то же самое, перезагрузил сервер - эффекта 0. Отключив сервер от сети, попробовал зайти с него в 1С и создать новую реализацию, при попытке записать - SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Timeout expired. Почитал всякие посты на всевозможных форумах. Отключил named pipes, оставив только TCP/IP, попробовал зайти с рабочей станции - без named pipes соединяться с SQL почему-то отказался. Опять же отключив сервер от сети, зашел с него в 1С. Реализация не записывалась с указанной выше ошибкой. Минут 15 пробовал всевозможные варианты, затем в конфигураторе прописал в параметрах соединения с базой, вместо имени сервера sqlserver IP'шник - 127.0.0.1, запустил Profiler, открыл базу и попробовал записать реализацию. На этот раз ошибка не появилась, но судя по профайлеру он "думал" над каким-то select'ом из таблицы DH1611 (судя по 1Cv7.DDS - как раз документ реализация) добрых 5 минут, при этом это было достаточно заметно по активности винтов в RAID'е. После чего реализация все-таки записалась и все вернулось к нормальной работе. Вернул named pipes, сейчас все работает. Вопрос, который мне не дает покоя. ЧТО ЭТО БЫЛО? Почему до того как я прописал вместо имени sql сервера его 127.0.0.1 документ не записывался, совпадение? Может быть дадите какие-то рекомендации, в плане - как исключить в дальнейшем подобную ситуацию, порядок действий при ее возникновении, выяснение причины произошедшего? Стоит ли обновить SQL Server до SP3? Может быть проблема именно в этом? Возможно ли возникновение такой ситуации (может быть сейчас глупо прозвучит, но все же) из-за какой-то внутренней блокировки таблиц в SQL? Как вы понимаете после перезагрузки сервера отключенного от сети, пользователи не работали, никакие ресурсоемкие отчеты и т.п. не выполнялись ... вообщем я не знаю на что и думать. Надеюсь на вашу помощь.

+0: http://www.mista.ru/kb/topic4990.htm - это читал. Если все дело, по вашему мнению, в версии SQL, то какой на данный момент последний SP к нему, и последняя версия драйверов ODBC?

ну в (2) не совсем то. что нужно. Почитай логи скуля, системы... просто так ничего не бывает.

(3) у меня была похожая проблема. База самописка, достаточно легкая - локально на моем компьютере при записи база висла и могла висеть несколько минут - потом ошибка, почти как в (0). Пробовал даже переставить sql и выгрузку/загрузку - не помогало. В результате я взял рабочий МД из каталога БД и у клиента новый архив базы. После восстановления из архива - все заработало. Что это было так и не понял. Уже прошло полгода - на рабочей таких багов не замечается.

P.S. В базе много прямых запросов.

(0) Кто-то заблокировал проведение документов, и пошел обедать (например, в модуле проведения есть модальное окно). Даже если его нет, в движке 1С есть ошибка, когда окно "Недостаточно прав доступа" открывается именно внутри транзакции проведения.

Кто именно всех блокирует, можно посмотреть в Enterprise Manager.

Как вариант, можно всех выгнать и попросить заново войти
(я использую выгонялку Книга знаний: Альтернативное стартовое окно для 1С:Предприятие 7.7 ).

(5) а почему после перезагрузки сервера ошибка не пропала? Врядли в этом дело.

(6) Даже не знаю как это могло получиться, ск. всего внутренняя ошибка MS-SQL.
Имеет смысл обновить движок, почистить папку временных файлов, сделать стоп-старт серверу, выгрузить-загрузить...
Также возможно имеет смысл поставить последний сервис-пак MS-SQL (там же наверняка исправляются всякие ошибки).

В логах "C:\Program Files\Microsoft SQL Server\MSSQL\LOG\" есть только упоминание о:

2007-05-08 17:27:42.65 spid8     The header for file 'C:\Program Files\Microsoft SQL Server\MSSQL\data\msdblog.ldf' is not a valid database file header. The PageAudit property is incorrect.
2007-05-08 17:27:42.65 spid8     Device activation error. The physical file name 'C:\Program Files\Microsoft SQL Server\MSSQL\data\msdblog.ldf' may be incorrect.

В Enterprise Manager'е она значится, как msdb (Suspect) ... Может ли это иметь отношение к моей проблеме, что это за DB такая, и как ее вывести из состояния suspect?

а лог файл каких размеров?..

В смысле? errorlog от MSSQL или msdblog.ldf? Первый 3 килобайта, второй около двух метров. За что отвечает база msdb и насколько опасно то, что она находится в состоянии suspect?

А база как называется в MS-SQL?

Вообщем начитался я тут всякого:

http://www.klerk.ru/soft/1c/?15077 - тут рассказывается про восстановление пользовательских баз данных, мне не помогло конечно, ибо msdb системная, но зато узнал что такое sp_attach_db и sp_attach_single_file_db. Думал воспользоваться вторым (аттач одного mdf'f) для восстановления msdb, не тут то было. Потом стал читать:

http://support.microsoft.com/kb/224071/ru - Перемещение баз данных SQL Server в новое местоположение с помощью операций Detach и Attach. Как раз про перемещение системных баз данных. В моем случае можно было (в теории) сделать detach msdb, а потом attach_single_file_db, но почему-то, несмотря на прописанные ключи -c -m -T3608, он на любых операциях аттача / детача с системными таблицами говорил:

Server: Msg 7940, Level 16, State 1, Line 1
System databases master, model, msdb, and tempdb cannot be detached.

Хотя по идее должен был разрешить.

В итоге взял два файла из дистрибутива MSSQL - \x86\DATA\msdblog.ldf и \x86\DATA\msdbdata.mdf и подсунул их SQL Server'у.

Может кто-нибудь прокомментирует, почему он не давал сделать detach. Я грешу на то, что msdb находилась в suspect'е, но ведь он ясно сказал что именно системные таблицы не могут быть отключены, почему-то он ключи проигнорировал, интересно почему? Сейчас вроде бы все работает, но что-то меня беспокоит ... не чревата ли такая подмена msdb?

(12) Детач не дает сделать для системных таблиц.
Но можно остановить сервер и подсовывать таблицы.

По идее не чревата, только вот почему оно вот так все накернилось?
Может, заряженная частица пролетела, и все испортила? :-)

>>Вернул named pipes
Чего не айпи?
>>Стоит ли обновить SQL Server до SP3?
Можно и до 4-го :)

в мире мелкософта есть много чудес  :)
вот одно из них:
однажды после переезда MSSQL с 1-процессорного сервера на на 2х процевый
с некоторых(!!!) машин невозможно было запустить 1С...
не буду описывать пляски с бубном... но все решилось установкой нового, на тот момент, MDAC на "проблемные" машины.  :)
зы. естественно ОС и SQL на другом сервере ставились с того же самого дистрибутива, с какого ставилось и на первый.

(13) Как раз в статье http://support.microsoft.com/kb/224071/ru описан способ с помощью которого можно сделать detach для системных таблиц (статья по ссылке как раз о перемещении системных таблиц в другое месторасположение), только вот у меня этот способ почему-то не сработал.

Ну вообщем ладно, главное что все работает. Спасибо всем принимавшим участие в обсуждении.

Такая же ошибка у меня начала неожиданно возникать на некоторых машинах при попытке вообще войти в 1С. Причем на одной через день ошибка перестала появлятся сама. А еще через 2 месяца вдруг другие 2 машины уперлись  - и ни в какую к SQL серверу не подключались. Как тут посоветовали, поставил в конфигураторе вместо имени сервера IP-адрес - всё заработало. Чудеса...