Первый раз столкнулся с тем что надо посмотреть че там в логах творится и не нашел инфы где и как...
Прошу направить на путь истинный, поиск результатов не дал.

а чей лог смореть то? 1с или же Sql?

При проведении базы вылетела ошибка sql, видимо его логи и нужны...

Блин, хоть бы послал кто... в нужном направлении...
Меняю правильный ответ на вкладышъ от "Дональда"!

(3) послать - это мы можем... lleo.aha.ru/na/ :-)

Текст ошибки в студию.

(5) в логахъ я его и мечтаю найти, говорят что то типа "потеря связи с базой" если с аглицкого переводить... фигня в том что сам я этого увидеть не успел :(

Мне б только знать как прочитать то что нарисовано в baselog.ldf, быть может счастье совсем близко...

(7) счастье даже на горизонте не маячит, потому как не там логи те, что ты ищещ.
То, что тебе хочеться лежать в "Program Files\Microsoft SQL Server\MSSQL$SERVER_TEST\LOG" - но они тебе ничем не помогут..

вот ведь, замкнутый круг получается... как жеж мне победить то что возникает глубокой ночью, повторяется не по законам а по собственному разумению да к тому же еще и не оставляет следов... мистика прям...
Спасиб и на этом, вот только вразумите тогда что там в этом baselog.ldf на стольго гигов напихано (под 30 гиг)?  или эт так предательски назвали саму базу, что я её с логом спутал...
Если есть немного полезных сцыл по теме (где что искать в этом sql-е), был бы признателен, и выслал бы вкладышь на указанный вами адрес :)

у тебя 30 гиг файл ldf ? интересненько...

лдф - файл транзакций, он не должен быть такого размера.

Мой совет: базу через конфигуратор выгрузить в зип, потом создать новую, с неограниченным ростом лдф'а, загрузить, бэкапнуть, шринкануть, списать размер лдф"а, ограничить рост бэкапа этим размером, прописать еженощный бекап и хотя бы еженедельный шринк.

Возможные грабли: если база долбанутая, при выгрузке может упасть. Т.е. лучше сделать бекап, из него поднять копию, ей сделать тестирование и исправление, потом ее выгружать и дальше по плану; но может не хватить места на сервере.

+10 >ограничить рост бэкапа
то есть ограничить рост файла транзакций=лдф.

(10)Спасиб за инфу, нечто подобное делал не так давно, по подсказке бывшего смотрящего, видимо толку не много случилось.
Вообщет база страшна, нечто полностью самописное, огромное, с хранением вместо ссылок на объекты их текстовых идентификаторов, и прочими радостями доставляющими не мало гемора, избыток инфы в ней коллосальный, я даж опасаюсь её сильно чем нить напрягать, масса уж фантастических замутов в ней бродит...
Есть что-нить из литературы, что бы не на ощупь делать, ненавижу пытаться исправить то чего не понимаю...

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

у тебя совершенно случайно не прием заявок?

почему превосходит?, нет ограничений я пока не делал, вот только понять бы как это влияет на "потерю связи с базой" во время проведения, я кажется "0" в sql администрировании и походу без литер-ры мало чего пойму...
не хочетца вас напрягать боле... мнебы книгу умную или сцылу...
Спасиб...
не думал что все так запутано...
Я попобую еще раз все это проделать но только обдуманно а не нажимая то что на листочке написали... :)))

у лога ограничения нету, соответсвенно, он начинает прирост, допустим, на 10% от размера ночью. Значит, пока лог будет расти, 1С будет ждать ответа от SQL а потом вывалится по таймауту, что у тебя и наблюдается.
Отсюда вывод - сократить этот самый лог, например, так
backuplog baselog with truncate_only и быть счастливым..
счастье будет продолжительным, если это делать не оставлять на самотек..

Спасиб, постараюсь разрулить...