1C: доступ к базе данных на сервере возможен только из одного каталога информационной базы.

 На днях столкнулся с проблемой, что пользователи 1С не могут зайти в базу данных. При попытке загрузки у всех появлялась одна и та же ошибка "Доступ к базе данных на сервере возможен только из одного каталога информационной базы". Небольшой поиск по интернету помог мне решить эту задачу, но особенно понравилась публикация пользователя Opiy, которую я выкладываю здесь (вдруг еще пригодится)....

«Такая ошибка возникает при попытке загрузить версию 1С для SQL после того, как один из пользователей некорректно вышел из системы. В редких случаях эта ошибка может быть результатом некорректной установки конфигурации.»

 Простой случай:

 а) Принудительно остановить SQL-процесс можно с помощью SQL Enterprise Manager. В нем все активные процессы перечисленны в ветке “Management\Current Activity\Process Info”. Надо найти в списке справа процесс, который мешает жить, выделить его и в меню “Action” выбрать пункт “Kill Process”

б) Если пользователи работают по протоколу Named pipes, то можно просто закрыть файлы на SQL-сервере, открытые повисшим пользователем. Такие файлы имеют вид \PIPE\MSSQL$NAMEDSERVER\SQL\query. (смотреть в открытых файлах, управления компьютером)

в) Можно поступить жестче и выполнить скрипт:

USE [master]
 ALTER DATABASE [наша база] SET OFFLINE WITH ROLLBACK IMMEDIATE

после выполнения скрипта рестарт службы SQL и выполнить скрипт:

USE [master]
 ALTER DATABASE [наша база] SET ONLINE

Тяжелый случай:

 косяк с самой базой. это печально.
 Делаем бекап базы!!! (mdf и ldf файлики)

открываем query analizer
для начала переводим базу в сингл моде:

sp_dboption ‘ВАША БАЗА‘,’single user’, true

Чекаем базу:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

Если на этом все заканчивается, то поздравляю — вам повезло! Переводите в мультиюзер и вперед.

Если нет и говорит чтото подобное:

Server: Msg 602, Level 21, State 16, Line 1
Could not find row in sysindexes for database ID 7, object ID СТРАШНАЯЦЫФРА, index ID -1. Run DBCC CHECKTABLE on sysindexes.

Это очень печально
Узнаем что за таблица накрылась:

select object_name(СТРАШНАЯЦЫФРА)

Если это _1SCONNECT — поздравляю — это лечится.

if exists (select * from dbo.sysobjects where id = object_id(N’[dbo].[_1SCONNECT]‘) and OBJECTPROPERTY(id, N’IsUserTable’) = 1)

 drop table [dbo].[_1SCONNECT]

 GO

CREATE TABLE [dbo].[_1SCONNECT] (

 [CONNECTUUID] [char] (36) NOT NULL

 ) ON [PRIMARY]

 GO

затем:

EXEC sp_configure ‘allow updates’, ’1′

 RECONFIGURE WITH OVERRIDE

 GO

 delete from sysobjects where name=’dummy’

 GO

 EXEC sp_configure ‘allow updates’, ’0′

 RECONFIGURE WITH OVERRIDE

 GO

потом снова:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

может выдать ошибки, но уже в других таблицах, если так — то все идет по плану.
Еще раз чекаем:

DBCC CHECKDB (‘ВАША БАЗА‘, REPAIR_ALLOW_DATA_LOSS)

Ошибок нет? Переводим в мульти-режим:

sp_dboption ‘ВАША БАЗА‘,’single user’, false

Наслаждаемся.

 Сработало это по той причине что без данных из _1SCONNECT вполне можно жить и мы ее тупо грохнули и пересоздали. Если же такой косяк вызывает таблица с ценной информацией…